The Non-Technical Founder's Guide to Reviewing a Developer's Work
You hired a developer or an agency. Invoices arrive, demos happen, the app looks like it is coming along. What you cannot tell is whether the thing underneath is solid or whether you are paying for a house with no foundation.
This is the position most non-technical founders are in, and it is structural. The person doing the work knows far more about its quality than the person paying for it. Learning to code will not close that gap in any useful timeframe. What does close it, at least partly, is knowing how to review developer work through the artifacts around the code rather than the code itself.
I do code audits and technical due diligence for founders in exactly this situation, and the same handful of checks come up every time. None of them require you to open a source file.
Ask for deliverables that are hard to fake
The cheapest form of oversight is deciding in advance what you want to see at each stage, and then refusing to move on until you see it.
Before any code is written, ask for an architecture sketch. It does not have to be pretty. A one-page diagram showing the main pieces (the web app, the database, the payment provider, the email service, background jobs) and how they talk to each other is enough. If your developer cannot produce this, they have not thought about the system as a whole yet. If they produce it in ten minutes and it makes sense to you when they walk you through it, that is a good sign.
Before you pay for a milestone, ask for a working demo on a server that is not the developer's laptop. "It works on my machine" is the oldest joke in software for a reason. A staging environment you can open in your own browser, on your own phone, without the developer present, tells you the deployment process exists and that the app runs somewhere real.
Before launch, ask for documented test results. Not a verbal "yes, it's tested." A short written summary: what is covered by automated tests, what was tested by hand, and what is known to be untested. A developer who has tests can produce this in an afternoon. A developer who has none will stall, and the stalling is the answer.
Also ask, at every stage, for access. You should have your own login to the code repository, the hosting account, the domain registrar, and any third-party services the app depends on. Owner-level access, in your name, paid with your card. This sounds like an administrative detail. It is the single most common thing founders wish they had sorted out earlier.
How to review developer work with questions instead of code
You can learn a lot about a codebase by asking questions whose answers are only good if the underlying work is good. Here are the ones I find most useful.
How long does your test suite take to run? A real answer sounds like "about four minutes" or "the unit tests take thirty seconds, the full run is twenty minutes." A worrying answer is any version of "we test manually" or "we're going to add tests once the feature set stabilises." Feature sets never stabilise.
How do you deploy to production? You want to hear something like "we push to the main branch, the pipeline runs the tests, and if they pass it deploys." That means the process is repeatable and does not depend on one person remembering steps. If the answer involves copying files by hand or running commands from memory, every deploy is a small gamble.
What happens if one of your dependencies has a security vulnerability? Modern apps pull in hundreds of open source packages. A good developer can tell you how they find out (automated alerts from GitHub or a similar tool) and roughly how often they update. If the answer is a blank look, nobody is watching.
If you stopped working tomorrow, how long would a new developer need to get productive? An honest developer will give you a number and explain what would make it shorter. Watch for the ones who say "not long" without being able to say why. The real answer depends on documentation, test coverage, and how conventional the code is, and a developer who cares about those things will mention them unprompted.
Where are the secrets stored? API keys, database passwords, payment credentials. The answer should be "in environment variables" or "in a secrets manager," never "in the code." If they are in the code, they are in the repository history forever, and anyone who has ever had access has them.
You do not need to judge the technical merit of the answers in detail. You are listening for whether the developer has a considered answer at all, whether they explain it plainly, and whether it matches what you can observe.
Warning signs you can see without opening a source file
Even without reading code, the artifacts around it tell a story.
Look at the commit history in your repository. GitHub and GitLab show it as a timeline. Steady, small commits with descriptive messages over the course of a week look like professional work. A single enormous commit the night before the deadline, with the message "final changes," tells you the work was either done in a rush or copied from somewhere else at the last minute. Neither is good.
Then check whether there is a folder called tests, spec, or similar. You do not need to read what is in it. If it does not exist, or exists with two files in it, there are no meaningful automated tests, regardless of what you were told.
The README file at the top of the repository is another quick check. Can a stranger follow it to run the app locally? Ask a technical friend to try for fifteen minutes without help. If they cannot, your next developer will not be able to either.
Notice who answers your questions. In an agency engagement, if every question about the backend goes to one person and every question about the frontend goes to another, and neither can cover for the other, you have a codebase where each section lives in one head. That is a risk you carry, not them.
And notice how estimates behave. Everyone misses estimates sometimes. The pattern to watch for is estimates that get worse over time rather than better. In a healthy codebase, adding the tenth feature is about as hard as adding the fifth. In an unhealthy one, each new feature takes longer because it has to work around everything that came before. If "small changes" keep taking weeks, the code has stopped being cheap to change, and that is a code quality problem showing up in your calendar.
Bringing in an outside reviewer without starting a fight
At some point you may want a second opinion. This is normal in every other industry. Nobody buys a house without a survey. Developers can still take it personally, so how you introduce it matters.
Frame it as due diligence for the company, not an audit of the person. "We're raising money and investors will want an independent view of the tech" is a sentence most developers understand and few resent. So is "I want to make sure we're not building up problems I can't see."
Tell the developer in advance, share the reviewer's scope, and let them talk to each other directly. A reviewer who spends an hour with the developer before writing anything produces a fairer report than one who works from the repository alone. Good developers are usually relieved to have someone technical on your side of the table, because it means they no longer have to explain why a refactor matters to someone who cannot see the problem.
What you want from the review is not a verdict of "good" or "bad." You want a short list, in plain language, of what is fine, what should be fixed before launch, and what can wait. That list becomes something you and the developer work through together, rather than a weapon.
And be prepared for the review to say the work is decent. That happens more often than founders expect, and it is worth paying for on its own: it lets you stop worrying and go back to running the business.
Contract clauses that protect a non-technical buyer
Most disputes I see could have been avoided with four paragraphs in the original agreement.
The first is source code ownership. The contract should state that all code, designs, and documentation produced under it belong to you, and that the developer will hand over the complete repository including history on request. Without this, in many jurisdictions the person who wrote the code owns it by default, which surprises a lot of founders the first time a lawyer explains it.
The second is a documentation requirement. Something like: "The deliverable includes a README sufficient for a competent developer to set up, run, and deploy the application without assistance from the original author." It is hard to argue with and easy to check.
The third is an acceptance definition tied to the deliverables from earlier in this post. A milestone is complete when the feature runs on the staging server, the automated tests pass, and the test summary has been delivered. This turns "is it done?" from a matter of opinion into a matter of fact.
The fourth is access. The contract should require that all accounts, domains, hosting, and third-party services are registered in the company's name, with the founder holding owner-level access from day one. A developer who objects to this is telling you something.
Keep the language plain. Long lists of coding standards in an appendix rarely help, because nobody enforces them and everybody argues about them. Short, verifiable conditions do.
What this looks like in practice
None of the above requires you to understand a line of code. Learning how to review developer work this way mostly means asking for specific things at specific times, listening carefully to how questions are answered, and looking at a few artifacts you can already see in your own accounts. Most founders who start doing this are surprised by how much clearer the picture gets within a couple of weeks.
If you would rather have someone technical sit on your side of the table during a build, that is part of what Wolf-Tech does. I act as a technical advisor for non-technical founders: reviewing deliverables, sitting in on developer calls, and reading the code so you do not have to. If you want to talk it through, write to hello@wolf-tech.io or have a look around wolf-tech.io.