Can a non-technical founder tell if their app was built well?

Yes. You cannot judge it from the demo, but the project's history shows the things that decide whether a build is healthy - how much was rework, whether tests exist, whether anyone reviews the work, and whether the code can be handed off - all without reading a line of code yourself.

What is an inherited or handed-off codebase?

It's a codebase you own but did not build - handed over by an agency, an offshore team, a departing developer, or an earlier contractor. You are now responsible for software whose history you weren't part of, which is exactly why reading that history matters: it's the only independent record of how the work was really done.

My developer delivered a working app. Why would anything be wrong?

"Working" only means it runs today. It says nothing about whether there are tests, whether anyone reviewed the code, or whether a single person is the only one who understands it. Those are the things that decide what happens the first time you need a change - and none of them are visible in a demo.

Does hiring a code auditor give me the same thing?

Not quite. A code audit tells you about code quality at a single point in time. Reading the history tells you about the process - how the work was actually done over time, where the risk sits, and whether the build can survive the next person who touches it. They answer different questions, and for an owner the process view is usually the one that was missing.

What is the single biggest risk in an inherited codebase?

A build that only one person understands and that cannot be handed off. It feels fine right up until that person is gone, and then a small change turns into a full rewrite. It has a name - a bus factor of one - and it is the most common and most expensive surprise in software you didn't build yourself.

Do I need access to the source code to check any of this?

You need read access to the repository, which includes its version history. You do not need to be able to read the code itself - the history alone reveals rework, tests, review, and single-person ownership. As the client paying for the work, you are normally entitled to that read access, and it's worth writing into the contract up front.

5 red flags in a handed-off codebase (and how to spot them without reading code)

You paid someone to build your app - an agency, an offshore team, a solo contractor, or lately "we vibe-coded it" - and you judged the work the only way you could: the demo. It opened, it clicked, it looked done. But a quiet worry stays in the back of your mind: was it actually built well, or does it just look finished? You do not need to read code to answer that.

I am a developer, and over the years I have been handed a lot of codebases that non-technical founders paid someone else to build. Almost every time, the story in the history was different from the one the founder had been told. The same handful of things go wrong, again and again - and none of them require you to read a line of code, because they are all sitting in the project's own history.

The short version: you cannot judge a build from the demo, but its history reveals the five failures that matter most - constant rework, no tests, no review, everything written by one person, and a build that cannot be handed off. The demo hides all five. The history hides none of them.

Red flag 1: rework that never shows up in a status update

The same files get rewritten over and over. From the outside it looks like steady progress - something changes every week, the updates keep coming. In the history it looks like someone going in circles and billing you for the laps. A little rework is normal and healthy; every build refines itself. A lot of it, quietly, is where budgets disappear without anyone ever telling you that the last month was spent redoing the month before.

Red flag 2: no tests, ever

Not "few" tests - zero. The app works today because someone clicked through it by hand before the demo. The problem arrives the first time you need a change: with no automated tests, nobody built a safety net, so every small edit becomes a gamble that something invisible elsewhere just broke. Tests are the difference between "we can improve this" and "do not touch it." A build with none is moving fast today and quietly buying you fragility for tomorrow.

Red flag 3: nothing gets reviewed

One person writes the code, the same person approves it, and no other human ever looks. That is fine while they are around and paying attention. It becomes a real problem the day they leave or go quiet, because no second person ever understood why anything is the way it is. Review is not bureaucracy - it is the simplest way knowledge spreads to more than one head as the work happens, instead of all of it walking out the door at once.

Red flag 4: it all lives in one head

Everything meaningful was touched by exactly one person. That is not a moral failure and it does not mean anyone did anything wrong - it is just risk, and it is risk you are carrying without knowing it. If that person walks, you do not have an app, you have a hostage situation. This is the single most expensive problem in inherited software, and it has a name: a bus factor of one. A healthy build has at least two people who understand each critical part.

Red flag 5: it cannot be handed off

No structure, no docs, no consistency. The next developer you hire takes one look and quotes you a rewrite instead of a fix, because picking this up is genuinely harder than starting over. This is usually where the "my old dev scammed me" stories actually come from - not fraud, just a black box nobody else can open. The cruel part is that it is invisible until the moment you need someone new to touch the code, which is exactly the moment you can least afford a surprise.

The demo lies. The invoice lies too.

Here is the uncomfortable part: a founder can be completely happy with a build that has every one of these problems, right up until the day it matters. The finished screens tell you nothing about how they were built, and neither does the bill. This is the core difference between looking at the code and looking at the process: the code shows you what exists right now, while the process shows you how it got there and whether it will survive the next person who touches it. That distinction is worth understanding on its own - it is the subject of code analysis vs process analysis.

What to ask instead of "does the demo work?"

You do not need to become an engineer. You need answers to a handful of process questions, and you can ask them in plain language at your next review:

How much of this was redone, versus built once and left alone?
Are there tests, and do they cover the parts that matter?
Does anyone besides the author ever review the work?
Could a brand-new developer pick this up without a rewrite?

Those answers are sitting in the project history whether or not anyone shows them to you. Most founders never think to look, because they assume you have to read code to understand it. You do not - the history is a record of the process, and the process is exactly what a non-technical owner can read.

A shortcut to reading the history

Reading that history by hand takes a developer you trust and a few hours. That is exactly the gap we built PulseRepo to close: it reads the history for you and turns it into plain-English questions a non-technical owner can raise at the next meeting - how the work is distributed, whether tests and review are keeping up, what looks unusual - each one cited back to the actual commits. Not scores, not a verdict on anyone, not surveillance. You can see a sample report to get a feel for it, and there is a free tier if you want to point it at your own repo.