Nobody Forces You to Think Before You Build Anymore
TL;DR
- Building software used to be costly enough that teams were inclined to think before they built. Now that building is cheap and fast, teams have to choose that discipline on purpose, because nothing in the process forces it any longer.
- Architecture debt happens when a team builds first and never circles back to think: the gap between what a tool was built to do and what it's quietly being asked to do later tends to widen the faster something gets built.
- Ask one question before shipping anything fast: what does this need to be able to hold up to later, not just what does it need to do this week.
The most dangerous thing about building fast is that nothing stops you from skipping the thinking anymore, and that's quietly getting a lot of teams into trouble.
For most of the last 40 years, custom software cost enough that the expense forced a bunch of thinking to happen upfront. If a build was going to cost six figures and take six months, someone had to answer the hard questions before anyone typed a line of code or spent a single dollar: what does this need to do, who else is going to use it, what happens when the data doubles?
With that forcing function eradicated by AI, a non-technical founder can now stitch together a handful of APIs and ship something that works in a week. That’s undeniably a huge advancement, but it's also the whole problem: building fast doesn't force anyone to ask whether what they just made will still hold up once 10 or 100 or 1000 people depend on it instead of just one.
Most teams don't get around to asking until the tool is already buckling: the CRM structure that made sense at 50 leads and falls apart at 5,000, the onboarding flow that only works because one person remembers all the exceptions by hand, the internal tool nobody dares touch because the person who built it already left.
I talked about this with Josh Webb, who built ourCMO.ai, on a recent episode of Building the Next Web. His take: the first 10-20% of any build deserves the most pre-thought and is the hardest part to change later, because those decisions end up limiting everything else the tool becomes.
When "it works" and "it's built right" are different things
A lot of teams are living that dichotomy right now, without realizing it. Take a team that's historically tracked a set of operational metrics in a spreadsheet. One person spends a week connecting the right APIs and ships a working dashboard. It's a real accomplishment, but it's also the kind of build where nobody in the room was thinking about architecture, because nobody thought there was architecture to think about. There was just a problem and a fast way to solve it.
So, the tool works. Whether it's built to keep working when five departments rely on it instead of one, when the data source changes, or when someone new has to maintain it is a whole separate set of questions, and speed can't answer any of it on its own. And that creates architecture debt.
Architecture debt is what happens when you build first and think later, and nobody circles back to do the thinking. The gap between what a tool was built to do and what it's quietly being asked to do six months later opens wider the faster something gets built without anyone deciding what it needs to survive.
What going back and doing the thinking looks like
Edgar Allan's own Slater Search, built by Jared Malan, is a good example of what purposely paying down architecture debt looks like in practice. Slater Search started the way most useful tools do: as an internal solution built for a specific need. It did what it needed to do, but it was not, in its first iteration, built to be a product a bunch of people could depend on.
Turning it into one meant revisiting early decisions on purpose instead of building on top of them. That meant work on security, on how different users and permissions would be handled, and on the parts of the system that don't matter when one person uses a tool internally but matter enormously when it launches publicly.
None of that work was visible in the original version, but all of it was necessary before the tool could hold weight it wasn't originally built to hold. And that's the difference between a fast build and a durable one: a deliberate return to vet and improve the decisions that were made before anyone was thinking about what they'd need to support later.
The same pattern shows up wherever fast building is happening
Slater Search is a software example, but the instinct behind it isn't specific to code: anyone can practice a little diligence in making early decisions on purpose, before other people start depending on them. Josh ran into the same problem building ourCMO, an AI system meant to reason the way he does as a fractional CMO.
Before he built anything client-facing, he spent three weeks having the system interview him, working through his frameworks, his judgment calls, and the questions he regularly asks clients, so the tool's reasoning was built on purpose instead of assembled on top of whatever the AI defaulted to. That's the same move as hardening Slater Search, just applied to a reasoning layer instead of a codebase.
The same logic holds for a design system built in a rush before a brand has settled its own verbal or visual language, or a content strategy assembled around whatever ranked last quarter instead of what the brand needs to say today. The pattern holds even as the tool changes: whatever felt like a detail at the start ends up deciding what the whole thing can become.
Before your next fast build, ask this instead
Speed isn’t the problem. Building first, then never circling back to do the thinking, is. So don’t let not asking questions early on decide what details are chosen and which ones are left to chance.
Before shipping the next fast version of anything, whether that's an internal tool, a website migration, a design system, or a piece of AI-driven infrastructure, stop and ask what the thing you're building needs to be able to do, handle, or accomplish three years from now, not just what it needs to do this week.
It’s a five-minute question you can ask about whatever you're building right now. Do it before you ship, not after.
This article grew out of a conversation between Edgar Allan founder Mason Poe and Josh Webb, fractional CMO at Webb Advisory Group, for the ongoing series, Building the Next Web. It's the same series that's brought us conversations with our own Witt Langstaff, Webflow's Nathan Huening, and Dave Steer, among others.
FAQs
Why is building fast more risky now than it used to be?
For most of the last 40 years, the cost of custom software forced teams to answer hard questions before writing a single line of code. A six-figure, six-month build meant someone had to work out what the tool needed to do, who else would use it, and what would happen when the data doubled. Now that building is cheap and fast, that discipline has to be chosen on purpose, because nothing about the process forces it anymore.
What is the most important question to ask before shipping something fast?
Ask what the thing you're building needs to be able to handle three years from now, not just what it needs to do this week. That single question surfaces which early decisions are actually going to matter once other people depend on the tool. It's the difference between a fast build and a durable one, and it takes five minutes to ask before you ship.
When do most teams realize they have an architecture problem?
Most teams don't ask until the tool is already buckling. That shows up as a CRM structure that made sense at 50 leads and falls apart at 5,000, an onboarding flow that only works because one person remembers every exception by hand, or an internal tool nobody dares touch because the person who built it already left. By the time the strain is visible, the fix is usually a lot more expensive than the upfront thinking would have been.
What does paying down architecture debt actually look like in practice?
Edgar Allan's Slater Search is a concrete example. Turning an internal tool into a product meant going back through the early decisions on purpose: real work on security, on how different users and permissions would be handled, on the parts of the system that don't matter for one internal user but matter enormously at public launch. None of that work was visible in the original version, and all of it was necessary before the tool could hold weight it wasn't built to hold.
Does this problem only apply to software and code?
No. This pattern shows up anywhere something gets built in a rush, not just in code. A design system built before a brand has settled its visual language, a content strategy assembled around whatever ranked last quarter, or an AI reasoning layer built on top of default assumptions all run into the same problem: whatever feels like a detail at the start usually ends up deciding what the whole thing can become. The fix is the same in every case: go back through the early decisions on purpose instead of building on top of them.
Is speed itself the problem when teams accumulate architecture debt?
Building first and never circling back to do the thinking is what accumulates architecture debt, not speed itself. The fix is treating early decisions as something to return to deliberately, before other people start depending on them. Speed just makes it easier to skip that step without noticing.