Why your MVP developer left you stuck (and how to tell before you hire the next one)
I once inherited a project where the previous developer had shipped something that looked done. It had a UI, it took signups, it "worked" in the sense that a demo would go fine. The business had already started onboarding real users on top of it.
Two things underneath told a different story.
Red flag #1: the basics weren't actually there
Authentication existed — there was a login screen, it took a password, it let people in. But underneath, it wasn't properly enforced everywhere it needed to be. Some endpoints that should have checked who was asking for data simply didn't. To a user, everything looked normal. Underneath, it meant information wasn't as protected as it should have been.
This is the red flag that matters most, and it's also the easiest one for a non-technical founder to miss, because auth is exactly the kind of thing that looks finished from the outside. The login screen works. Nobody's complained. There's no obvious signal that anything's wrong — until there is, and by then it's not a code review conversation anymore.
Red flag #2: hardcoded values everywhere
Smaller, but it compounds. Things that should have been configuration — pricing tiers, feature limits, environment-specific settings — were typed directly into the code instead. Want to change a price? That's a code change and a redeploy, not a settings update. Want to run a staging environment that behaves differently from production? Good luck — the values assuming "this is production" were baked in everywhere.
Individually, each hardcoded value seems harmless. A dozen of them in, every small business decision becomes an engineering task, and every engineering task takes longer than it should because half the work is finding all the places a value got typed in by hand.
Why this happens
Not usually because a developer is careless. Almost always because "make it work by launch" and "make it work correctly" got treated as the same task under time pressure, and the second one lost. Auth enforcement, proper configuration — none of it demos well. A working login screen demos exactly the same whether it's airtight or not. So it's the kind of corner that's invisible right up until it isn't.
How we fixed it
We rebuilt the parts that needed rebuilding rather than patching around them — properly enforcing authentication and access checks across every endpoint that touched user data, and pulling the hardcoded values out into real configuration. It's stable now. But it cost real time and real budget that a closer look, earlier, would have avoided.
What to actually check — whichever side of this you're on
If you're a business owner vetting a developer or agency before hiring: ask directly whether access to data is enforced consistently, not just present. "Is there a login" and "is every piece of data properly protected behind it" are different questions, and only the second one matters.
If you're realizing your current setup might have this problem: the signal usually isn't a demo failing. It's things that should be simple — changing a price, adding a feature flag, spinning up a staging environment — taking far longer than they should. That friction is often the first visible symptom of decisions that were invisible when they were made.
The takeaway
A working demo and a sound foundation are not the same thing, and the gap between them doesn't show up until someone's relying on the product for real. If your gut says something feels fragile under a product that otherwise looks fine, that instinct is usually worth a second opinion before it becomes a bigger problem.
Note: details here are generalized to protect client confidentiality — no specific vulnerability, data, or company is identified. If a review like this sounds useful before you hire, or before you find out the hard way, I'm easy to find.
