Building, Fast and Slow

Most projects start with a burst of energy. Writing initial code, whether through vibe coding or meticulously setting up a new repository. This is the fast building phase: boilerplates are generated, frameworks are initialized, and thousands of lines of code appear almost magically. It's the era of rapid creation, where progress feels tangible, even exhilarating.

In our influencer-driven tech culture, this is the stage people love to showcase. Screenshots of dense IDE windows, terminal outputs with green success messages, and LinkedIn posts boasting, "Built an entire backend in one weekend!"

But then, something shifts. The initial features are deployed, users start finding edge cases, and production behaves differently than your local environment. The honeymoon phase ends as reality intrudes.

After the initial sprint, after the CRUD endpoints are scaffolded, the utility functions written, and the directory structures laid out, the real work begins. This is slow building. This rhythm mirrors Daniel Kahneman's dichotomy in 'Thinking, Fast and Slow'.

Now, every line of code carries weight. You realize that the utility function you wrote three weeks ago doesn't handle null values. The elegant abstraction you designed now needs three extra parameters to accommodate real-world scenarios. The third-party library you integrated requires careful debugging because it behaves unpredictably under load.

If you were tracking your progress by lines of code, you’d notice something strange: you’re deleting more than you’re adding. Refactoring replaces writing. Debugging replaces deploying. The initial velocity slows to a crawl. Not because you’ve become less productive, but because each change now ripples across the system.

Kahneman distinguishes between two modes of cognition:

• System 1 (Fast): Intuitive, automatic, and prone to biases.
• System 2 (Slow): Deliberate, logical, and effortful.

Similarly, building software has two modes:

• Fast Building: Instinctive, momentum-driven, and optimized for quick wins.
• Slow Building: Thoughtful, iterative, and focused on long-term sustainability.

Fast building gets you off the ground, slow building keeps you in the air. Fast building thrives on excitement; slow building demands patience. Fast building is about creation; slow building is about correction.

---

The challenge is knowing when to shift between these modes. Some teams never make the transition, in fact they weaponize the fast-building process as a deliberate strategy. They sprint from feature to feature, patching bugs with quick fixes, stacking shortcuts on top of shortcuts. The codebase grows bloated, fragile, but nobody slows down to fix it. Why?

Because they aren’t building to last. They’re building to sell.

In startup land, this is an open secret. Many companies optimize for rapid growth over sustainability. Investors want traction, not maintainable code. The game isn't to build something enduring, it's to build something valuable enough for an acquisition or acquihire (when a company is bought primarily for its talent rather than its product).

This creates tension between developers and product teams. A developer discovers that the payment button randomly disables itself, the effect from months of quick fixes stacked on top of each other. But because slow building was never prioritized, fixing the root cause drowns in the backlog. The developer feels the business doesn't care about quality. The product team doesn't see the point when they're juggling two other high-priority launches.

For teams incentivized by short-term wins, slow building seems wasteful. Why refactor when you could ship? Why write tests when the deadline is tomorrow?

The bill always comes due eventually. During an acquisition I was involved in, we inherited a codebase where a critical user authentication flow was used to service multiple unrelated services. Fixing bugs on one system, brought down the others. What was a bug on one service, was a feature on another. The original logic was buried under layers of conditional statements and try-catch blocks. What should have been a straightforward function had become an archaeological dig through undocumented workarounds, patches that handled specific customer scenarios that were never written down or explained.

When tech debt piles up like this, there's a temptation to burn it all down and rebuild from scratch. This feels like starting fresh, but it's really just fast building in disguise. Rebuilding doesn't guarantee you won't face new challenges, and you risk losing those hidden patches that, despite their messiness, were solving real problems.

---

Building software, like thinking, isn't about speed. It's about rhythm. The key is recognizing the signals that tell you when to shift modes:

Shift to slow building when:

• Bug reports start clustering around the same areas
• New features consistently take longer than estimated
• You find yourself saying "I'll fix that later" repeatedly
• Code reviews become exercises in working around existing problems

Stay in fast building when:

• You're validating a new concept or market
• The cost of being wrong is low
• Time-to-market is your primary competitive advantage
• You have a clear exit strategy

Knowing when to go fast and when to go slow is what separates lasting systems from flashy prototypes. Fast building gets you there quickly. Slow building keeps you there.

---