Post-MVP development & scaling
Your MVP has users. Now every change seems to break something, some screens are slow, and nobody is sure whether to keep building on it or start again. We assess the product and the code, decide per component what to extend, refactor or rebuild, and grow it from how people actually use it.
01What comes after an MVP
Post-MVP means the first question has been answered - people use the product - and the next ones are about growth. These are the usual signs that the product needs different work from the one that launched it.
Small features touch many files, and fixes in one place cause problems in another.
Pages and reports that were fast with pilot data slow down as real customers accumulate history.
Things your team handled by hand for the first users now take a large share of their week.
Single sign-on, integrations, permissions, reporting - the "later" list is now on sales calls.
Knowledge lives in a freelancer's head or an agency's process, and the documentation does not exist.
02Step one
Technical health matters only in relation to what the product needs next, so both sides are reviewed together. The result is written down before any new work is agreed.
Need an independent review without development work? See Comtau's software architecture review.
03MVP to full product development
The rebuild question is usually asked about the whole product, and is usually the wrong question. Different parts of the same MVP often need different answers.
04MVP scaling services
An MVP built well leaves a list of recorded simplifications. Scaling means working through that list in the order usage demands - not rebuilding everything to a standard nobody needs yet.
Measured first: slow queries, heavy pages, missing caching. Fixed where users feel it.
Monitoring, alerts and logs that tell you about a problem before customers do; retries and timeouts on integrations.
Access control reviewed, dependencies updated, data handling documented for customers' security questionnaires.
Model changes made safely, with migrations rehearsed and data reconciled afterwards.
Automated checks, preview and staging environments, and releases that can be paused or rolled back.
Documentation, decision records and handoff notes so your own engineers can take over.
05MVP product enhancement services
Everything left out of the MVP was left out for a reason. After launch, each item is re-evaluated against what users actually do - some become urgent, others turn out to be unnecessary.
06Post-MVP development services
Four stages, each ending with something written. Whether Comtau continues after the assessment, and for how long, is agreed with you.
Product evidence and technical review: what users do, and what the code, data and infrastructure can support.
Fix what puts users or data at risk first: missing tests on critical paths, backups, monitoring, security gaps.
Extend, refactor or rebuild - per component, with the order of work and what each step unlocks.
Foundations and features in small, releasable units, each with its checks and a handoff note.
04 → 01Each increment updates the roadmap from new evidence
07Questions
Still before launch? See how we approach a first release.
An assessment of the product and the code, a written recommendation on what to extend, refactor or rebuild, then incremental delivery: stabilising the parts users depend on, replacing deliberate MVP simplifications as usage justifies them, scaling performance and reliability, and building the next features from the evidence. Handover to your own team can be part of the plan.
Rarely all of it. Most products keep the parts that work and replace specific components - often the data model in one area, a slow integration or code without tests around critical paths. A full rebuild is justified when the foundations block the product's next stage and fixing them would touch most of the code anyway. The assessment makes that case in writing, either way.
Yes. The first step is access to the code, infrastructure and analytics, and a conversation with whoever built it if that is possible. The assessment documents what we find, including what is good, before any new work is agreed.
Written findings on product evidence (what users do, where they struggle) and technical health (code structure, tests, data model, security, infrastructure, delivery process), a risk register, and a recommendation per component - extend, refactor or rebuild - with the order of work. You can use it with any team.
By working in small increments that each leave the product releasable: a share of each cycle goes to the foundations users depend on most, the rest to features. Larger changes run behind feature flags or alongside the old path until they are proven, then the old path is removed.
That is a planned outcome, not an afterthought. Every unit of work ends with a handoff note, decisions are recorded with their reasons, and handover documentation is built throughout - so your team starts from written context rather than from one person's memory.
Tell us what the product does, how many people use it and what is getting harder. We will suggest where an assessment should start.
Prepare a post-MVP brief