The MVP did its job. People are using it, some are paying, and the business case is proven. Now everything you knowingly skipped to get there is arriving at once, and it arrives as a feeling that the team has slowed down for no reason.
The team has not slowed down. The product has outgrown the shortcuts.
What an MVP is allowed to skip, and what that costs later
A good MVP deliberately trades long term quality for speed to learning. That is the correct trade. The bill comes due in a predictable order.
- Manual processes. You approved listings by hand at fifty users. At two thousand it is somebody’s whole job.
- No admin tooling. Support requests were handled by editing the database. That is now both a bottleneck and a risk.
- Thin error handling. Fine when users were friendly early adopters. Not fine when a stranger hits an edge case and leaves.
- No automated tests. Every change now risks breaking something that used to work, so the team gets cautious and slow.
- One environment. Testing in production is survivable at ten users and indefensible at two thousand.
- Whatever the schema got wrong. The shortcuts in the database are now expensive to undo. See database design mistakes.
What to fix, in order
1. Anything that loses money or data
Payment edge cases, refund handling, data that can be lost or corrupted. These are not deferrable. One serious incident costs more than the fix.
2. The manual process eating the most hours
Find the thing a person does twenty times a day and automate that one first. It buys back capacity immediately and the return is easy to measure.
3. Admin and support tooling
A proper back office: find a user, see their history, issue a refund, fix a record, suspend an account. Unglamorous, and it is what lets the business run without a developer on call for routine requests.
4. A test suite around the critical paths
Not full coverage. Signup, login, checkout, payment, the two or three flows where a break is serious. This is what returns the team’s speed. See our automation roadmap for what that involves.
5. Staging, deployment and monitoring
A staging environment, an automated deployment, and alerts that tell you something is wrong before a customer does.
6. Performance, once there is real data
Now is when missing indexes and the N plus one queries start to show. Our guide to scaling a web application covers the order.
What not to do
Do not rewrite from scratch. The instinct is strong and it is almost always wrong. The existing code contains hundreds of small corrections for real world cases nobody documented. A rewrite loses all of them and takes three times the estimate.
Refactor the parts that hurt, in place, while the product keeps running. The one genuine exception is a technology that is truly at a dead end, and that is rarer than teams claim.
Do not stop shipping features. A quarter of pure cleanup with nothing visible destroys momentum and the goodwill you need to keep doing it. Allocate a fixed share of each sprint, twenty to thirty percent, and keep delivering alongside.
Do not fix what is not hurting. Ugly code that works and never changes is not a priority. Ugly code in the part you touch weekly is.
What it costs
For a typical MVP built in three to four months, hardening it into a product that can carry a business:
- Admin and support tooling: 300,000 to 800,000 PKR
- Automating the main manual processes: 200,000 to 700,000
- Test suite on critical paths: 250,000 to 600,000
- Staging, deployment pipeline, monitoring: 200,000 to 500,000
- Performance and schema work: 200,000 to 800,000, heavily dependent on what was skipped
Roughly 1,200,000 to 3,400,000 PKR in total, commonly forty to seventy percent of the original MVP cost. Budget for it at the point you decide the MVP has succeeded, not when the team starts complaining.
For price bands across websites, apps, SaaS products and ERPs, see our software cost guides.
The signal that you have waited too long
When the team’s answer to every request is “that will take a while because of how we built it”, the debt has become the roadmap. At that point you are paying the interest whether you acknowledge it or not.
Related reading: how long an MVP takes and SaaS development cost and timeline.
Frequently asked questions
When should I move from MVP to product?
When you have evidence of real demand and the team is visibly slowing down. Usually somewhere between six and eighteen months after launch.
Should I rewrite the MVP?
Almost never. Refactor in place. Rewrites lose accumulated fixes for real world cases and take far longer than estimated.
How much of the sprint should go to this?
Twenty to thirty percent, continuously. Enough to make progress, not so much that feature delivery stops.
Can I keep the same team?
Usually yes, and it is preferable because they know the decisions. You may need to add infrastructure or QA capability that the MVP team did not have.
Ezitech has taken 650 or more products from first version to production scale across 42 countries. Tell us what is slowing your team down.