The pain point hiding in a log file

How a two-hour build delay became a 15-minute workflow — and what it taught me about the gap between shipping software and shipping developer experience.

It started with a GitHub issue

Not a dramatic one. Just someone saying they gave up after two hours waiting for Python packages to cross-compile for RISC-V. Then another message like it. Then a pattern — half the developers I talked to at ETHGlobal had hit the same wall, shrugged, and moved on to a different project.

At Cartesi, our product ran arbitrary code in a deterministic Linux environment on-chain via RISC-V. That was genuinely novel technology. But to reach that novelty, developers had to survive a build process where every pip install kicked off a from-scratch cross-compilation. Two to three hours per attempt. On a good day.

The mistake I almost made

The obvious fix is to write better documentation. Explain the compile step. Add a warning. I almost did exactly that. A well-crafted paragraph telling developers "this takes a while" would have been true, shipped quickly, and solved nothing.

The actual problem was that we were asking developers to pay a time cost that was entirely ours to eliminate. They weren't doing anything wrong. The toolchain was.

What changed

I brought the pattern to engineering with numbers: how many developers mentioned the build time unprompted in feedback, how many workshop attendees dropped off during the compile step, roughly how many projects we were losing at the environment setup stage. The engineering team built a prebuilt binary directory — a cache of the most common RISC-V Python packages compiled in advance.

Developers who hit the common path stopped hitting the compile wall. Build times dropped from 2–3 hours to under 15 minutes. Developer adoption roughly doubled over the following quarter.

The lesson I keep applying

Developer experience problems look like documentation problems from the outside. "They just need to read the README" is almost always wrong. The question is never why didn't they try harder — it's what made trying harder than it should be.

I think about this whenever I'm designing an AI system for a client. Where is the 2-hour build hiding? Is it in the onboarding? The error message? The moment a user asks the assistant something reasonable and gets a wrong answer with no recovery path? The fix is rarely a warning label. It's almost always a structural change that required someone to first notice the friction was systemic — not incidental.