I overbuilt, and it cost me more than the build

A startup does not reduce uncertainty by polishing its assumptions. It reduces uncertainty by testing them. Everything below follows from that, including a decision I got wrong and would make differently.

Time spent perfecting a product without feedback is time spent extending uncertainty rather than reducing it. Customer evidence is what clarifies which parts work, which fail, and which deserve another iteration. Perfection without exposure produces stagnation that looks like progress.

The build–measure–learn loop converts an idea into evidence, then converts evidence into a better decision. Build the smallest credible test. Measure behaviour and outcomes rather than opinions. Learn enough to pivot or persevere, and say which.

In a previous venture I hired a team of MERN-stack developers to build a state-of-the-art custom website from scratch. The build consumed months and a significant portion of the budget, and it did not move the business forward. The system was neither necessary nor efficient for what we actually needed.

The cost was not only technical. It was strategic — and that is the part worth passing on, because the technical cost is the one everybody budgets for.

The first build is the visible cost. The operating model arrives with it, and it arrives permanently.

• Specialist capacity — custom development needs front-end, back-end, infrastructure, testing, product and security capability, not one developer.
• Continuous maintenance — once software is live, releases, uptime, defects, dependencies, security and support become recurring obligations.
• Lost learning time — every month spent building an unvalidated system is a month not spent learning about customers, pricing or demand.

Buy a proven platform when the capability is common, speed matters, and differentiation sits elsewhere. Compose modular tools when the workflows are distinctive but the individual capabilities are not your product. Build proprietary technology only when the technology itself creates durable customer value or a defensible advantage.

Four questions settle it before you commit. Does this capability create customer value? Is it a source of competitive advantage? Can an existing tool test the hypothesis? Can we own the maintenance burden?

Agentic coding tools can work across a codebase, edit files, run commands, verify changes, and compress the path from concept to a functioning prototype. The build loop is genuinely smaller than it was: specify the customer problem as architecture and acceptance criteria, generate, verify, and turn observed evidence into focused changes.

This changes the method. It does not change the judgement required to define the system, evaluate the trade-offs, or decide whether the result is ready for customers.

And a functional product is still an engineering system. The prototype arrives sooner; production readiness still depends on owning the architecture, engineering the data layer, protecting users, and maintaining whatever reaches production. Founders need enough technical fluency to specify, review, test, deploy, secure and maintain — or the engineering leadership to own those decisions on their behalf.

• Build an MVP that tests the central hypothesis before increasing scope.
• Use platforms deliberately — proven tools for non-core needs, unless the business model demands custom technology.
• Prioritise validated learning: let customer behaviour decide what happens next.
• Preserve optionality. Avoid irreversible commitments until the business has earned the right to scale.