Most early-stage startups don't fall apart because of bad technology or a weak market. They fall apart because two founders who thought they agreed on everything discover, months and thousands of pounds later, that they never really did.
The assumptions hurt you most aren't the obvious ones. They're not about equity splits or salaries. They're the quiet ones:
- What does "done" actually mean?
- When are we ready to launch?
- Who decides?
These questions feel settled until the moment they become arguments.
Here's what we learned the hard way.
"Built" Means Different Things to Different People
Ask two founders whether the platform is ready and you'll often get two completely different answers — even when they've been building the same thing together.
Before significant development begins, get specific. What features must exist before the product is considered operational? Which are essential, and which are nice-to-have? What level of admin automation is required? What third-party integrations are non-negotiable?
Write it down. Something as simple as:
The platform is considered operational when users can register, complete the core workflow, make payments, and administrators can manage activity without developer intervention.
That one sentence can prevent weeks of circular debate.
Launch Readiness Isn't Just a Feeling
"We're not ready yet" is one of the most dangerous phrases in a startup. It's vague, it's subjective, and it can stall a business indefinitely.
Define launch readiness before you start building. Is it tied to feature completion or a date? How many internal reviews are needed? Does user documentation need to exist? Are analytics and monitoring in place? Who has final sign-off?
When the criteria are clear, the conversation moves from "I don't feel ready" to "we have three things left on the list." That's a much more productive place to be.
No Software Ships Bug-Free — So Agree on What's Acceptable
Bugs are inevitable. What matters is agreeing in advance which bugs block launch and which don't.
A simple four-tier framework works well:
P1 — Critical: Users can't log in, payments fail, data is lost, security is compromised. Launch stops here.
P2 — Major: Core functionality works but with significant problems — intermittent failures, broken admin workflows, missing notifications. These should normally be fixed before launch.
P3 — Minor: Inconvenient but not blocking. Layout issues, incorrect labels, non-critical validation errors. Can be addressed post-launch.
P4 — Cosmetic: Spacing, typos, minor visual tweaks. Schedule these for later.
The framework itself matters less than the fact that you've agreed on it. Without it, every bug becomes a negotiation.
Real Users Beat Internal Assumptions Every Time
It's easy to convince yourself that the product works because it works for you. The question is whether it works for the people you're building it for.
Before launch, define your user testing requirements. How many target users need to test the platform? What tasks should they complete? What counts as a successful run-through? Who's responsible for recruiting them?
The goal isn't perfection. The goal is proving that real users can complete the intended workflow — and that you haven't been quietly building something only its creators can navigate.
Technical Delivery Doesn't Build a Business
This one catches a lot of technical co-founders off guard. A working platform is necessary, but it isn't sufficient. Someone has to go and get customers.
Map out the commercial responsibilities early. Who owns customer acquisition? Sales outreach? Partnership development? Marketing? Investor conversations? Customer support?
A simple ownership table — even a rough one — prevents the situation where the CTO thinks the business is ready to grow while the CEO is waiting for one more feature, or vice versa. Both founders need to be pulling in the same direction at the same time.
Define What Success Looks Like at 30, 60, and 90 Days
Without agreed success metrics, every post-launch conversation becomes a matter of opinion. One founder thinks things are going well; the other thinks you're failing. Both could be right depending on their unspoken benchmarks.
Set them in advance. What does success look like in the first 30 days? First paying customer, a handful of registered users, no unresolved critical bugs. At 60 days? A small paying cohort, evidence of repeat usage, a feedback process in place. At 90 days? Consistent acquisition, clear market signal, a roadmap for what comes next.
Measurable outcomes keep the conversation honest.
The One-Page Agreement That Saves Months of Disagreement
None of this requires a lawyer. It requires an hour and a shared document.
Before you start building, write down:
- What "built" means
- What "ready to launch" means
- What level of bugs is acceptable at launch
- How much user testing is required before you go live
- Who owns the commercial activities
- How you'll measure success in the first 90 days
It won't cover everything. But it will cover the things that, in our experience, cause the most damage when left unspoken.
The conversation is uncomfortable to have at the start. It's a lot more uncomfortable to have it six months in.