"I don't understand why every change takes three weeks now. Six months ago, we were shipping in days."
Last month, a founder reached out after burning $90K on an agency build. The app worked. Users were signing up. But it was almost impossible to change — every feature request opened up a chain of cascading dependencies no one had anticipated. She hadn't made any single catastrophically wrong decision. She'd made five small ones, all in the first six weeks.
This happens regularly. And here's the thing: none of the five mistakes are obvious when you make them. They make complete sense at the time. The cost shows up later, when it's expensive to reverse.
I'm going to walk through all five, exactly as I explain them to founders when I come in to assess a build. Then I'll tell you what I do instead.
Mistake 1: Building Before the Core Assumption Is Tested
I've seen dozens of founders spend 3–6 months and $50K–$120K building a product before showing it to the people they built it for. Not because they're careless. Because validation feels slow and building feels like progress.
Here's what I ask every founder before a single line of code gets written: who is your first customer, specifically — not a segment, a person or a named company — and what do they currently do instead of using your product? If those questions can't be answered concretely, the project isn't ready to build.
The real cost of skipping validation: A founder I worked with earlier this year spent four months building a B2B workflow tool before running their first user interview. The interviews revealed the core assumption — that users would want to replace their existing spreadsheet process — was wrong. The product worked. The behaviour change it required didn't. The rebuild cost eight weeks and $40K.
What I do instead: before any development starts, I set up a test that can confirm or disconfirm the core assumption — a prototype, a manually-delivered service, or a structured interview process with 5–10 people who match the target customer profile. This takes 2–4 weeks. It routinely saves 3–6 months of build in the wrong direction.
Already Started Building?
If you're 3+ months into an MVP and something feels off — changes are taking too long, users aren't doing what you expected — I can audit what you've built and tell you what's actually happening.
Get an honest assessment →Mistake 2: Choosing a Tech Stack for the Wrong Reasons
Tech stack decisions are usually made in one of three ways: the developer picks what they know, someone picks what sounds impressive, or the agency defaults to whatever they've used before. None of these are reasons.
The right question isn't "what's the best stack in general?" It's: can your team ship with it, will it be maintainable in 18 months, and can the next hire work with it without a rewrite briefing?
What one founder paid to rebuild a React Native mobile app after discovering their primary use case required camera and Bluetooth features that React Native handled poorly. The developer had chosen it because they wanted to learn it.
When I work with founders on stack selection, I ask: what does this product actually do? What's the hiring pool for people who know this stack? What happens in 18 months when the current developer is replaced? The boring, proven choice is almost always better than the exciting, niche one. Not because it's technically superior — often it isn't — but because it's survivable.
Mistake 3: Architecting for a Scale Problem You Don't Have
This is the mistake that usually comes from a founder who's done their research. They've heard about companies that failed because their infrastructure couldn't handle growth. They want to build it right. So they end up with microservices, message queues, and distributed caching — for a product with 12 users.
I've seen this exact setup across pre-seed builds. The architecture wasn't wrong. It was expensive to build, slow to change, and hard to hire for — at a stage where the most valuable thing the product could do was change direction quickly.
What a sound pre-seed architecture looks like: A single application server. A managed database service. A staging environment that mirrors production. Automated deployment. Error monitoring. Daily database backups. That's it. This supports most products to hundreds of users and takes days to set up — not months.
Here's my rule: the right trigger for adding architectural complexity is an observed constraint, not a projected one. When a query is measurably slow under real load, we optimise it. When a feature genuinely requires background processing, we add a queue. Not before.
Mistake 4: Making the First Technical Hire Too Early
This one is counterintuitive. Founders feel like they're moving faster by hiring. Often, they're not.
Senior developers — the ones worth hiring — are expensive ($150K–$200K+ in the Sydney market), selective, and attracted to problems they can own. When they're brought in before scope is stable, they're underutilised and frustrated. The result is either turnover — expensive — or a developer who starts making product decisions that should still belong to the founder.
Last quarter, a SaaS founder hired a senior backend developer three months into building, before her scope had settled. By month five, the developer had built a technically excellent authentication system, a notification framework, and a billing integration — none of which matched the direction the product had moved in. The developer wasn't doing bad work. He was doing the work that was in scope when he joined, which was no longer the right scope.
Not Sure When to Make the First Hire?
I work with founders to stabilise scope and build the technical foundation before the first full-time developer joins — so that when they arrive, there's something clear for them to own.
Talk about your hiring timeline →30 minutes • No obligation • Honest feedback
Mistake 5: Shipping Without Operational Basics in Place
The rush to ship produces a specific list of omissions. No staging environment (they test locally). No automated deployment (they deploy manually, carefully). No error monitoring (they check logs when something feels wrong). No backup test (they assume the automated backup works). No runbook (it's just two people, they both know how it works).
Every one of these justifications is reasonable. Every one of them stops being reasonable the moment there's a real production incident with a paying customer affected.
Three months ago, a founder called me at 11 PM because their production database was corrupted. They had automated backups. They'd never tested a restore. The restore took four hours and partial data was lost. The follow-up with customers took a week.
Average recovery time when a production incident hits a team with no runbook and no tested restore procedure. With operational basics in place, the same incident typically resolves in under 30 minutes.
When I come in at the start of a build, the first thing I set up isn't a feature. It's the operational baseline: staging environment, CI/CD pipeline, error monitoring, backup with a confirmed restore, uptime alerting. This takes 3–4 days. It prevents the kind of incidents that burn full weeks to recover from.
What Happens When We Catch These Early
The founder I mentioned at the start — the one who'd spent $90K on an agency build that had become difficult to change — came to us six months in. By that point, two of the five mistakes were fully embedded in the codebase and would require significant rework to address.
When I work with founders from the start of a build, the same five mistakes are catchable in the first two weeks — usually before any significant development has begun. The questions I ask in the first session are diagnostic: they're designed to surface which assumptions haven't been tested, which architectural decisions are being driven by the wrong factors, and what's missing from the operational setup.
The cost of catching them early: $5K–$15K for the fractional CTO engagement in the first 6–8 weeks. The cost of catching them late: typically $40K–$120K in rework, plus the 3–6 months it takes to undo decisions that compound on themselves.
Sound familiar? Let's talk.
Ready to Avoid All Five?
Whether you're about to start building or already a few months in, I can tell you which of these patterns are present — and what to do about them.
Start the conversation →30 minutes • No obligation • Honest feedback