You have a part-built app and two voices. One says you are nearly there. The other says this is a mess and you should start again properly.
Whoever you ask will have an incentive. A developer quoting a rewrite gets a bigger job. Someone selling a "rescue" service needs the thing to be rescuable. So here is the framework I would use, including the outcomes that are bad for me.
The question is not code quality
People think this decision is about whether the code is good. It mostly is not. Ugly code that does the right thing is cheap to live with; elegant code built around a wrong idea is expensive forever.
The real question is: is the shape of the thing right?
Specifically — does the app model your business correctly? If it assumes one customer has one order and really they have many, that is a foundation problem and it propagates everywhere. If it just names things badly and has no tests, that is surface, and surface is fixable in place.
Three questions that usually settle it
Does the data model match reality? Sketch how your business actually works on paper, then look at what the app assumes. If those disagree in a structural way — one-to-many where you have many-to-many, a missing concept you talk about daily — you are looking at a rebuild of that part at minimum.
Can you run it? Can you get it started, make a change, and see the change? If nobody including you can get the thing running without the original chat history, that is a genuinely bad sign, and it is often the real reason people reach for a rewrite.
Is anyone using it? This one outranks the other two. Software with real users earns enormous patience. If people are using it and paying, you fix forward almost regardless of how it looks inside.
When is starting over genuinely right?
I will say it plainly, because most people in my position will not.
- The data model is wrong in a way that touches everything, and nobody is using it yet. Rebuild. It is cheaper now than it will ever be again.
- The app is built on a platform you cannot get your code out of, and your plan requires getting your code out.
- It is small. If the whole thing is a few screens, rebuilding properly can genuinely be faster than auditing someone else's work, mine included.
That last one matters. If you show me something tiny, the honest quote is often "this is a week to rebuild and I would not charge you for an audit first".
When starting over is a mistake
- Because it is ugly. Ugly is cheap.
- Because a developer said so without asking what the app is for. A rewrite quote is the easiest thing in the world to produce and the hardest to justify.
- Because it has no tests. That is an afternoon of work on the paths that matter, not a reason to throw away something that functions.
- Because you are embarrassed by it. Everyone is embarrassed by it. The people with revenue are embarrassed by it too; they are just also paid.
The middle option nobody offers
There is another answer, and it is the most common correct one: keep it, fix the specific things that would hurt a real customer, ship it to a small number of people, and decide the rest later.
That usually means access rules, secrets, error alerting and a couple of tests on the money path. Days, not months. Then you have users, and users change every subsequent decision — including making a rewrite much easier to justify, because by then you will know what the thing actually needed to be.
How to get an answer you can trust
Ask whoever you are talking to what would make them say "do not hire me". If they do not have an answer, you have learned something.
Run the free website check — free, no call attached, and if it finds nothing it says so.
If you want a straight read on finish-versus-restart, tell me what you have built. I am one engineer and I would rather turn down work than take on a rebuild that should have been a fortnight of fixes.
