You built it, now it's broken. Fix it or start over?

Most founders who contact us don't start from zero. They already paid for an app, from an agency, a freelancer, a friend who codes on weekends, or a no code tool that got them to launch. It worked for a while. Now it works on good days.

The question is almost always the same: can you fix it, or do we have to throw it away?

The honest answer is that it depends, and finding out is quicker and cheaper than most people expect. Here is how we look at it.

What "broken" usually looks like

Founders rarely describe a technical problem. They describe a business one. These are the ones we hear most:

• Every small change breaks something else. You ask for a new field on the checkout page and the login stops working for a week.
• Nobody can deploy it anymore. The person who built it left, and the app runs on a server only they knew the password to.
• It's slow the moment people actually use it. Fine with ten users in the demo, unusable on the Monday after your newsletter goes out.
• The bill keeps growing. Cloud costs double every quarter and nobody can explain which part of the app is spending the money.
• The data doesn't add up. Orders in the app don't match orders in the accounting tool, and someone fixes it by hand every Friday.
• You can't hire for it. Developers look at the code, or the framework it was written in, and politely decline.

None of these automatically means a rebuild. Most of them are symptoms of three or four decisions made early, under time pressure, that nobody went back to.

Fix or rebuild: five questions that decide it

When we open an existing codebase, we're not judging whether it's pretty. We're answering five practical questions.

1. Is the data model sound? If customers, orders and payments are stored in a way that makes sense, almost everything else can be repaired around it. If the data is tangled, every fix is a patch on a patch.
2. Can it be deployed by someone new in one afternoon? If not, that's the first thing to fix, before any feature. It's usually days of work, not months.
3. Is the problem in one place or everywhere? A slow search page is a fix. A slow app on every screen points to a structural choice.
4. Is the technology still alive? Old is fine. Abandoned is not. If the framework has no updates and no developers, you're paying a tax on every change.
5. What does the next year need? A booking app that needs payments, a mobile version and three languages next year is a different question from one that just needs to stay up.

In our experience, most apps land on the fix side. The rebuild cases are real, but they're fewer than agencies selling rebuilds would suggest. And when a rebuild is the right call, it rarely means starting from nothing: the data, the screens your customers already know and the lessons from the first version all carry over.

How we handle it at whereweup

We don't quote a rebuild from a phone call. We start with a short, paid Discovery Sprint: we get access to the code and the hosting, we run the app, we talk to whoever uses it every day, and we come back with a plain answer.

You get three things at the end:

• A verdict: fix, partial rebuild, or rebuild, with the reasons written in words you can forward to an investor or a partner.
• A priority list: what to fix first so the business stops bleeding, usually deployment, backups and the one bug costing you customers.
• A scoped plan: what the next version costs, how long it takes, and what we would deliberately leave out.

If the answer is "your current developer can fix this with a few changes", we'll tell you that too. It happens more often than you'd think.

If you're sitting on an app that half works and you're not sure which side of the line it's on, send us one line about what's going wrong at business@whereweup.com. We'll tell you honestly whether it's worth a closer look.

Originally published on LinkedIn.