Your MVP is breaking under real customers. Here's what to fix and who to hire.

Something changed a few weeks ago. The app that quietly worked all last year now goes down on Tuesday mornings. A customer emails to say their data looks wrong and you can't tell if they're right. Your developer says the fix will take two days, then takes two weeks, then explains that fixing it broke something else. Meanwhile you have real customers paying you, or investors who just wired money, and both groups are expecting things to get better rather than worse.

Here's the thing nobody tells you at this stage: you are not failing. You are experiencing the specific, predictable, extremely common consequence of having succeeded.

Your MVP didn't break. It finished its job.

An MVP exists to answer one question: will anyone actually want this? To answer that question quickly, whoever built it made a series of completely reasonable trade-offs. They skipped the automated tests, because tests take time and the product might not survive the month. They put the logic in whatever file was open. They did slow work while the user waited, because with twelve users nobody noticed. They stored things in a way that made sense for the feature in front of them, not for the ten features that came after.

Every one of those decisions was correct at the time. They are also, every one of them, the reason things hurt now. Shortcuts that are invisible at ten users become expensive at a thousand. That's not a betrayal by your developer and it's not a sign you were sold something bad. It's the bill arriving for speed you genuinely needed.

The reason this matters is that it changes what you should do next. If you think you were scammed, you fire people and start over. If you understand that a prototype reached the edge of what prototypes do, you fix the specific things that are now load-bearing and keep the customers you fought for.

Three completely different problems that all feel identical

This is the part almost nobody explains, and it's the reason so many founders spend money on the wrong fix. "The app is breaking" describes at least three unrelated situations. They have different causes, different urgency, and almost nothing in common when it comes to solving them.

Problem one: it works, but not for this many people

The software is correct. It does the right thing. It just cannot do the right thing fast enough, or often enough, for the number of people now asking.

What this looks like: pages that got slower as you grew rather than after a specific change. Everything fine at 6am and struggling at 10am. Timeouts under load that vanish when traffic drops. Your hosting bill climbing faster than your customer count.

What's usually behind it: a database being asked the same question thousands of times instead of once, work happening while the user waits that should happen in the background, or a server sized for a demo. This category is the most alarming to live through and usually the cheapest to fix. It is often days of work, not months, because the logic is already right.

Problem two: it's quietly doing the wrong thing

The software runs fine. It's just wrong, sometimes, in ways nobody catches immediately.

What this looks like: a customer says their numbers don't match and you have no way to prove who's right. Two parts of the app disagree about the same fact. Reports that don't reconcile. Bugs that you fixed once and that came back. Anything involving money, dates, or time zones behaving strangely.

What's usually behind it: the same rule written in several places so fixing one leaves the others, no tests to notice when behavior changes, or data that was allowed to become inconsistent because nothing enforced the rules. This category feels less urgent than the first and is far more dangerous. Outages are visible and get fixed. Silent wrongness compounds, and you often discover the full extent of it during a funding diligence process or when a large customer audits you.

Problem three: you can't change it safely anymore

The software might be perfectly fine. The problem is what happens when anyone touches it.

What this looks like: every fix breaks something unrelated. Estimates that are wrong by an order of magnitude. Your developer being reluctant to change certain parts of the system. Deploys that happen at night because they're scary. One person who is the only one who understands any of it.

What's usually behind it: no tests, no way to try changes before customers see them, and knowledge that lives in one person's head instead of anywhere you can read it. This is the category that most often gets misdiagnosed as "we need to rewrite," and it's the one where rewriting helps least, because a new codebase with the same practices arrives at the same place in eighteen months.

Most struggling products have some of all three. What matters is which one is actually costing you customers this month, because that's what you fix first.

What normal actually looks like

Founders at this stage have no way to calibrate. You don't know whether you're in a crisis or just uncomfortable, and the internet is full of content designed to make you feel like it's a crisis. So here are some rough markers for a small product with real customers.

Some bugs in production is normal. Every serious software company ships bugs. What's not normal is not knowing about them until a customer calls.

Occasional downtime is normal. Sustained weekly downtime at a predictable time is a signal, and it's usually a solvable one.

Slow features are normal. A feature that gets slower every week is a trajectory problem, and trajectory problems get expensive if ignored.

Not being able to answer "is it up right now?" without opening the app yourself is not normal, and it's the single cheapest thing on this list to fix.

Being unable to deploy a change without holding your breath is common at this stage but should not be permanent.

Worth knowing what the cost side looks like: the 2025 Calyptix and ITIC survey of 715 organizations put hourly downtime cost for businesses with 20 to 100 employees at roughly $8,000 to $25,000. Treat that as an order of magnitude rather than your number. The useful exercise is calculating your own, which is roughly your hourly revenue plus the support hours an outage creates plus whatever a churned customer is worth. Do that math before you decide how urgent any of this is, because it converts an anxious feeling into a budget.

The first two weeks: stabilize before you hire anyone

The instinct when things break is to hire someone immediately. Resist it for two weeks, and spend those weeks doing things that are cheap, fast, and make every subsequent decision better. Whoever is currently working on your system can do most of this.

Get visibility first. You need to know when the app is down without a customer telling you, and you need to know when errors happen. Uptime monitoring and error tracking are inexpensive services that take a couple of hours to set up. Nothing else on this list matters as much, because right now you are making decisions blind.

Verify your backups by restoring one. Not "we have backups." Actually restore one somewhere safe and confirm the data is intact. A surprising number of businesses discover at the worst possible moment that their backups have silently failed for months.

Write down the last ten things that went wrong. Date, what broke, who noticed, how long it took to fix. This list is worth more than any consultant's opinion, because it shows you the pattern. Ten incidents will usually cluster into one or two root causes, and it will be obvious which of the three problems above you actually have.

Find out how much of the system only one person understands. Ask your developer directly which parts nobody else could work on. Research on this key-person risk is thin and mostly dated, so treat it as a judgment call rather than a statistic, but the honest answer is usually uncomfortable and always worth knowing before you plan anything.

Confirm you control your own accounts. The code repository, the hosting, the domain, the database. Not through your developer's personal account. Yours. If any of that is unclear, our guide on what to do when a developer disappears covers the recovery steps in order.

Two weeks of this costs almost nothing and changes the conversation entirely. You go from "everything is broken" to "we go down when a specific report runs, our backups work, and two parts of the system only Dave understands." Now you can hire against a real problem instead of a feeling.

Who to actually hire

Here's where most advice becomes useless. You'll be told to consider a fractional CTO or an agency, and then handed no way to choose between them. So let's be specific about what each option is genuinely good at and, more importantly, when each one is the wrong call.

Start by naming your gap honestly, because the four options map to four different gaps.

Option one: nobody yet, buy a diagnosis instead

If you can't clearly describe what's wrong, hiring anyone is premature. You'd be asking a person to define the problem and solve it and grade their own work, which is how founders end up paying for a rewrite they didn't need.

An independent technical assessment typically costs $2,000 to $5,000 and takes a few days to a couple of weeks. You get a written account of what's actually wrong, what it will take to fix, and in what order. That document then lets you hire precisely, or in some cases discover that two weeks of work by your existing developer solves it.

When this is wrong: if the system is actively down and losing customers today, you need someone stopping the bleeding, not writing a report. Assessments are for stable-but-deteriorating, not for on fire.

Option two: your first full-time senior engineer

This is the right call when you have a clear and continuing stream of work, you intend to build a product team eventually, and you can afford to be patient. A good senior engineer who owns your system is the strongest long-term outcome on this list.

It's also the slowest and most expensive path, and the honest numbers matter here. According to Carta's compensation data, the average salary for a new engineering hire at a startup was about $189,000 as of mid-2025, and engineers made up nearly 30% of all new startup hires in the first half of that year. Levels.fyi puts US senior engineer median total compensation higher still, though that source skews upward because large tech employees report more often. Add payroll costs and equity, then add the two to three months it takes to hire and the further months before someone is fully productive in an unfamiliar codebase.

When this is wrong: when you cannot evaluate senior engineers. This is the trap that defines this stage. Hiring your first engineer is the one hire you are least equipped to judge, and a wrong senior hire in a small company is expensive in salary and far more expensive in the months you lose. If you're going this route and you're non-technical, have someone independent sit in on the technical evaluation.

Option three: a fractional CTO

Fractional CTOs work part-time across a few companies, usually for a monthly retainer. Current market rates run roughly $6,000 to $20,000 a month depending on the depth of involvement.

The gap this fills is judgment, not hands. A fractional CTO is right when you can get work done but cannot tell whether the work is the right work. They're valuable for choosing between approaches, evaluating engineers you're about to hire, standing between you and a vendor, and answering technical diligence questions during a raise.

When this is wrong: when what you actually need is someone to fix things. A fractional CTO at ten hours a week is not going to rebuild your data layer. If your problem is a shortage of hands rather than a shortage of direction, you'll pay a senior rate for advice you can't execute on.

Option four: an outside firm

A firm brings a team rather than a person, which matters when the work is bigger than one person can do quickly and you need it done in a defined window. It's the fastest way to get from broken to stable, and you're not committing to a permanent salary.

This is what Norsoft does, so read the next part with that in mind.

When this is wrong: when nobody on your side can evaluate what's being delivered. Handing your system to a firm you can't assess is the same trap as hiring an engineer you can't assess, with more zeros. It's also wrong when the work is genuinely continuous and open-ended, because at some point ongoing work is cheaper as a salary than as a rate. A good firm should tell you when you've reached that point.

How to tell if the diagnosis you're being given is honest

You're going to hear an opinion about your system, possibly from your current developer, possibly from someone selling you something. You need a way to sanity-check it without being technical yourself. These questions work.

"What specifically cannot be fixed in place, and why?" A real constraint sounds concrete: the framework stopped receiving security updates, or the way customer data is stored makes the feature you already sold impossible without restructuring. A weak answer sounds like taste: the code is messy, it's not how I'd have done it, it uses old patterns. Messy is normal. Messy is not a reason to spend six figures.

"What happens to my current customers while this work happens?" Anyone who has actually done this will have a real answer involving running things in parallel and migrating gradually. A vague answer means they haven't thought past the fun part.

"What's the smallest version of this that would help?" This question separates people who are solving your problem from people who are scoping a project. There is almost always a smaller first step. If someone insists there isn't, ask why.

"If I do nothing for three months, what actually happens?" An honest answer might be "probably nothing, but the risk goes up," and that's fine. Someone who cannot describe the consequence of waiting is selling urgency rather than diagnosing.

One bias worth knowing about: engineers generally prefer building new things to repairing old ones, and that preference is well documented rather than a character flaw. Chainguard's 2026 Engineering Reality Report, based on 1,200 engineers and technical leaders, found that engineers spend only about 16% of their week building features while 93% say building is the most rewarding part of the job, and 72% said maintenance work makes it hard to find time for anything new. When someone recommends a rewrite, they may be completely right. They're also recommending the more enjoyable option, and it's fair to weigh that.

If AI wrote most of it

A growing number of the products in this situation were built quickly with AI coding tools, and that changes what to look for.

GitClear's 2026 analysis of 623 million code changes found duplicated blocks of code up 81% since 2023, and refactoring, meaning cleanup that consolidates repeated logic, down to 3.8% of changed lines from 21% in 2022. In plain terms: the same rule tends to exist in several places at once. That's why a bug you fixed keeps reappearing. It was never one bug.

Google's 2025 DORA report, based on around 5,000 technology professionals, found AI adoption associated with faster delivery but reduced stability, and framed the underlying finding memorably: AI doesn't fix a team, it amplifies what's already there. Developers report the same friction from the inside. In Stack Overflow's 2025 survey of 48,885 developers, 66% named their top frustration as AI solutions that are "almost right, but not quite," and 45% said debugging AI-generated code takes more time than expected.

None of this means an AI-built product is doomed. It means budget more time for finding duplicated logic and for a security review, and less energy on whether the whole thing needs to be thrown out. We wrote more about the specific patterns in the real problems with vibe coding and what AI-generated code gets wrong on security.

When starting over is actually right

Sometimes it is. The honest test is whether there's a hard constraint, not whether the code is unpleasant. A framework that no longer gets security updates is a constraint. A data model that makes your next twelve months impossible is a constraint. "I don't like how it's written" is not.

Worth noticing that most successful "rewrites" are actually replacements of one component while everything else keeps running. That's a very different project from starting fresh, and it's usually the right shape. We covered the full decision, including what the research says about rewrite success rates, in software project rescue vs starting over.

What to do this week

If you take one thing from this: get visibility before you get advice. Set up uptime and error monitoring, restore a backup to prove it works, and write down the last ten things that went wrong. That's a few hours and a few dollars a month, and it converts a vague sense of dread into a list.

Then figure out which of the three problems is actually costing you customers. Load, correctness, or fragility. They look identical from where you're standing and they are not the same thing.

Then hire against that. Not against the anxiety.

Frequently asked questions

Why did my MVP start breaking only after we got customers?
Because an MVP is built to answer one question: will anyone want this? The shortcuts that make it fast to build, like skipping automated tests and doing slow work while the user waits, are invisible with ten users and painful with a thousand. Nothing broke. The thing you built reached the edge of what it was designed to do, which is what happens when it works.

Should I hire a senior engineer, a fractional CTO, or an agency?
It depends which gap you have. If you can't tell what's wrong, buy a diagnosis first rather than a person. If you know what to build and need hands, that points to an engineer or an outside firm. If you can get work done but can't judge whether the decisions are right, that's a leadership gap and points to a fractional CTO. Hiring a full-time senior engineer when you can't evaluate senior engineers is the most common expensive mistake at this stage.

How much does it cost to fix an MVP that's falling over?
A focused assessment usually runs $2,000 to $5,000 and takes a few days. Stabilization work, meaning monitoring, backups, tests around the critical paths, and fixing the top few failure points, commonly runs $15,000 to $60,000 depending on the size of the system. For comparison, the average new engineering hire at a startup was around $189,000 in salary as of mid-2025, before payroll costs and equity.

Does it matter that our MVP was built with AI coding tools?
It changes what to look for, not the overall approach. Expect the same logic to exist in several places, which is why bugs reappear after you fix them, and budget extra time for security review. It does not mean the product needs to be rebuilt.

How do I know if the developer telling me we need a rewrite is right?
Ask them to name the specific thing that can't be fixed in place, and why. A real answer sounds like a constraint, such as the framework no longer receiving security updates. A weak answer sounds like an aesthetic judgment, such as the code being messy. Messy code is normal and fixable. Then ask what happens to your current customers during the rewrite, because that answer reveals whether they've thought it through.