You can judge a custom software developer without reading code. Judge what you can see: what they shipped, how they explain a decision, and how they handle a small paid job. The code itself is the one part you can't check alone, so have someone independent check it.
Why interviews tell you so little
Most founders pick the candidate who sounds most sure of himself. One recruiter describes the usual result: the founder hires someone confident, and six weeks later the code is a mess, the timeline has slipped and he can't say what he paid for.[1] The same source says a resume review and a friendly interview reveal little about whether a person can build your product.[1]
If you have already been through that once, you know the cost. A second hire means paying again to fix and rebuild what the first one left.[1] So the checks below are worth doing before the contract, not after.
Check what you can see before the first call
Ask for three things before you spend an hour on a call:
- Live products they built, and their own part in them. "I built the backend and the admin panel" is useful. "Our team worked on it" is not.[2]
- The name of the person who will write your code. An agency may sell you with senior people and staff your project with junior ones.[2]
- Two past clients you can phone. Ask what went wrong, how close the final cost came to the quote, and who maintains the product now.[2]
Ask questions where a weak answer is easy to hear
You don't need technical vocabulary to hear a bad answer. You need questions that force specifics. These come from a founding engineer's guide for non-technical founders.[2]
| Ask | A good answer | An answer that should worry you |
|---|---|---|
| Show me something live you built. What would you do differently? | Names a real mistake and what it cost | "Nothing, it went perfectly" |
| Here is my feature list. What would you cut from version one? | Cuts things and says why | Agrees to build everything |
| What would you need to know before quoting? | Asks about users, flows and integrations | Gives a price before asking anything |
| What are the riskiest parts, and how would you find out early? | Names one or two and how to test them first | "No risk, it's straightforward" |
| How will I see progress each week? | A working demo I can click, on a schedule | Status reports and percentages |
| Who owns the code, the repository and the cloud accounts? | "You, from day one, in your accounts" | "We'll transfer it at the end" |
| How do you test before something reaches my users? | Describes a test environment and what they check | "I test it myself" |
| When would you tell me not to hire you? | An honest answer, such as "if you haven't validated demand, try something cheaper first" | "Never" |
The most telling are the questions about cutting scope and about risk. A developer who pushes back on your feature list is protecting your money. One who agrees to everything is either inexperienced or planning to sort it out later, on your budget.[2]
Run a small paid job
A short paid job is the nearest thing to a test you can grade yourself. Pick one to two weeks of work you need anyway, such as sign-up and login or one core screen.[2] Pay a fair rate, because unpaid tests drive off experienced people who have other options.[2]
Set up the code repository yourself, in an account you own, and invite the developer. Ask for a demo you can click on a test link, not a screen recording.[2] Then watch the behavior as much as the result. Did they ask good questions early? Did they tell you about a problem before the deadline?[2]
If the budget is large, pay a senior engineer you trust for an hour or two to review the trial code. The question for him is simple: would you be comfortable inheriting this?[2]
Check that the bills match the work
Two checks take a few minutes each. First, look at the commit history, the log of every change a developer saves to the repository. A consultant quoted by one staffing firm described developers who bill a client full-time while splitting their hours across other projects, and the log shows whether the person you pay for 40 hours a week showed up.[3]
Second, read the contract for who owns the code. The same source tells of a founder two years into a simple app who was stuck with one developer because the code lived in that developer's private repository.[3] Your contract should assign all code to your company, and the repositories and cloud accounts should be in your name from day one.[2]
Plan for the day this developer leaves
Two of the questions matter most if your goal is software that cheaper developers can maintain. Ask how someone else would take over if the developer disappeared tomorrow. A good answer names documentation, setup scripts and your access to everything. Then ask what the product will cost to run each month after launch. A developer who has never thought about hosting costs will not have built for them.[2]
These answers matter because the work you hire for today will pass to someone else. Code that only its author can run keeps you tied to that author, at his rate.
Vetting has a ceiling
Even with all of this, you are still the one deciding whether an explanation sounded convincing, and you can't grade your own homework.[3] For the final choice, pay an independent senior engineer to sit in on the technical conversation and review the work, as you would pay a surveyor before buying a building. The same check works on a developer you already have. Ask for the repository, the accounts and an independent review.
If you want a second opinion on a developer you are about to hire, or one you already pay, talk to Robert Lara III at Moosara.
Sources
- SpdLoad (Vira Kostohlad), "How to Hire Startup Developers (Without Costly Mistakes)," updated May 2026 https://spdload.com/blog/how-to-find-and-hire-developers-for-startup/
- Akash Bansal, "How to vet a developer when you can't read code: 12 questions and the answers that should worry you," updated November 2026 https://akashbansal.tech/blog/how-to-vet-a-developer-non-technical-founder/
- Matt Watson, Full Scale, "The Non-Technical Founder's Guide to Building Software," October 2026 https://fullscale.io/blog/non-technical-founder-guide/