Frantic development

About six months ago, I wrote and deployed ZAR’s first Solana program. It was simple; let users send money to each other without knowing the recipient’s account address, with some discreet logic around transaction sponsorship and a few guardrails.

What has been remarkable is not the feature itself, but the behavior of the system. Since the moment we deployed it, the program has operated with the reliability of the internet itself; it works when there is a connection and is unavailable only when the network is. That is all. No maintenance, no migrations, no patches, no babysitting. It behaves like infrastructure, something permanent, predictable, and stable, rather than another application dependency waiting to break.

This experience stands in sharp contrast to nearly everything else we have built or integrated over the same period. In just six months, our team has upgraded, rewritten, and debugged more internal systems and partner services than I care to count. Some changes were forced by flaky vendors, others came from our instinct to move fast and try new things. The result, however, is always the same; endless churn.

Modern software teams repeat a similar mantra. Ship fast, iterate constantly, buy instead of build, and treat today’s code as tomorrow’s trash. This mindset has become so common that we rarely question it any longer. I have started calling this pattern Frantic Development, a mode of rapid and reactive activity that produces unstable systems while convincing teams that speed is the same as progress.

Picture a team standing on a shoreline, looking toward the horizon, which represents the real destination. The rational approach would be to design something seaworthy; chart the course, build the boat, test it, then launch. Yet in most product teams, this discipline is replaced with a kind of collective myopia.

Someone points a few meters into the waves and says, “Let us just get to there first.” It sounds reasonable, measurable, and like a quick win. So everyone rushes into the surf and celebrates the tiny movement forward as if it represents real progress toward the horizon.

The cycle repeats; a few more meters, a few more splashes, more cheers.

But eventually, the sand slips away beneath their feet. The water deepens, the current strengthens, and the team finds itself far from shore, frantically swimming. They are no longer moving toward the horizon, only away from drowning. At this stage, many companies blame individuals. They say they need better swimmers, faster swimmers, more disciplined swimmers. Yet the problem was never the swimmers.

The problem was the absence of a boat.

The irony is that the team must now spend even more time and energy swimming back to the beach simply to begin the work they should have done from the start.

We justify this chaos with promises of continuous updates, new features, and steady improvements. Although this sounds promising, it has become little more than a convenient story we tell ourselves to defend the monthly-subscription ecosystem of half-baked tools held together by constant refactors. A new Android or iOS release breaks things. A PM reorganizes the interface to justify a roadmap. An engineer rewrites a module because the first version was not built for longevity. Everything is always changing, yet nothing feels meaningfully better.

This is why the on-chain development paradigm feels so refreshing. The idea of an immutable program forces an entirely different mindset, one that reminds me of a pre-internet era where distributing software meant shipping something physical. You did not get a second chance. Engineers, designers, and architects had to build with the expectation that their work might live untouched for years, and that constraint created durability.

In on-chain programs and smart contracts, we can feel hints of that discipline returning. Immutable programs encourage rigor, careful design, and a respect for permanence, qualities the industry lost along the way. Perhaps as on-chain development matures, we will see a return to systems built not for frantic iteration, but for resilience.

Maybe this is the beginning of a shift toward software that lasts.