Guide · Hiring, contracts & ownership
How to vet a developer when you can't read code: 12 questions and the answers that should worry you
How to vet a developer as a non-technical founder: 12 questions to ask, the answers that should worry you, a paid trial and the contract checks.
Short answer
You don't need to read code to vet a developer. Judge what you can check: live products they shipped, how they explain trade-offs in plain words, whether they push back on your scope, and how a small paid trial goes. Then confirm in the contract that you own the repo and accounts from day one.
The most common question non-technical founders ask before they build is some version of "how do I know if this developer is any good?" It shows up in threads like r/SaaS: "Non-tech founders, how did you build your SaaS?" again and again. The fear is reasonable: you're about to hand someone a large share of your savings, and you can't inspect what they hand back.
I've sat on the other side of this. As head of technology at Urban Culture, a salon marketplace that grew to 500K registered users with four apps, I hired and led the developers who built and ran them. Here's the process I'd use if I were a founder who couldn't read a line of code. Where to look for candidates in the first place is a separate question, covered in how to find a developer for your startup.
How do you vet a developer if you can't read code?
You vet what you can observe: shipped work you can click, how clearly they explain decisions, whether they challenge your plan, and how they behave on a small paid project. Code quality matters, but you can buy an hour of a senior engineer's time to check it. Judgement, honesty and communication you have to check yourself, and those are what decide most projects.
Think of it like hiring a builder for a house when you're not an architect. You can't check the load calculations, but you can visit houses they've finished, ask how they'd handle your awkward plot, and watch whether they tell you bad news early.
What should you check before the first call?
- Live products, not screenshots. Ask for links to apps or sites in production that they built, and what part they personally did. "I built the backend and the admin panel" is useful. "Our team worked on it" is not.
- Something like your product. Not the same idea, but the same kind of difficulty: payments, real-time features, a marketplace with two sides, AI features.
- A named person. If it's an agency, ask who will actually write your code, and ask to talk to them. Agencies sometimes sell with senior people and staff with junior ones. The same check applies to offshore teams, and the outsourcing setup that protects you covers the rest.
- Founders who hired them before. Ask for two you can call. You'll use specific questions for these calls (below).
A GitHub profile is nice to have but not required. A lot of the best professional work lives in private client repositories.
What are the 12 questions to ask a developer?
Ask these on a video call. Listen for specifics. A good developer answers in plain words and tells you when something depends on information they don't have yet.
| # | Ask | Good sign | Should worry you |
|---|---|---|---|
| 1 | Show me something live you built. What would you do differently? | Names a real mistake and what it cost | "Nothing, it went perfectly" |
| 2 | Here's my feature list. What would you cut from version one? | Cuts things, and explains why | Agrees to build everything |
| 3 | What would you need to know before quoting? | Asks about users, flows and integrations | A price before any questions |
| 4 | What are the riskiest parts of this, and how would you find out early? | Names one or two and how to test them first | "No risk, it's straightforward" |
| 5 | How will I see progress each week? | A working demo I can click, on a schedule | Status reports and percentages |
| 6 | Who owns the code, the repository and the cloud accounts? | "You, from day one, in your accounts" | "We'll transfer it at the end" |
| 7 | If you disappeared tomorrow, how would someone else take over? | Docs, a readme, setup scripts, your access to everything | "That won't happen" |
| 8 | How do you handle a feature I add halfway through? | A clear change process, with the cost and time impact written down | "Don't worry, we're flexible" |
| 9 | What will this cost to run each month after launch? | Rough hosting and service costs, with assumptions | Never thought about it |
| 10 | How do you test before something reaches my users? | Describes a staging environment and what they check | "I test it myself" |
| 11 | How do you protect user data and passwords? | Concrete practices, such as secrets out of code and access controls | Vague or dismissive |
| 12 | When would you tell me not to hire you? | An honest answer, such as "if you haven't validated demand, try no-code first" | "Never" |
Questions 2, 4 and 12 matter most. A developer who pushes back on your scope is protecting your money. One who agrees with everything is either inexperienced or planning to sort it out later, on your budget.
How do you test a developer's skills without reading code?
Run a paid trial. It's the closest thing to a test you can grade yourself.
- Pick a real slice. One to two weeks of work on something you need anyway: sign-up and login, one core screen, a payment flow in test mode.
- Pay a fair rate. Unpaid "test projects" filter out the experienced people who have other options.
- Put it in your repository. Create the GitHub (or GitLab) organisation yourself and invite them. This tests question 6 for real.
- Ask for a demo you can click. On a staging link, not a screen recording.
- Grade the behaviour, not just the result. Did they ask good questions early? Tell you about a problem before the deadline? Write a short note on how to run it?
Then, if the budget is large, pay a senior engineer you trust for an hour or two to review the trial code. You're not asking "is this perfect?" You're asking "would you be comfortable inheriting this?"
What should you ask a developer's past clients?
Generic references ("they were great!") tell you nothing. Ask questions that force specifics:
- What went wrong during the project, and how did they handle it?
- How close were the final cost and timeline to the original quote?
- Did you own the code and accounts the whole time?
- Is the product still running? Who maintains it now?
- Would you hire them again for your next product?
The last answer, and how quickly they give it, tells you most of what you need.
What red flags mean you should walk away?
- A quote before questions. They're pricing a template, not your product.
- No live work they can point to.
- Refusing to work in your repository and accounts. This is the biggest single protection you have. See who owns the code: a founder's checklist.
- Most of the money upfront. Pay by milestone, with each one tied to a working demo.
- Vague answers about who does the work.
- "Yes" to everything. Every serious build needs cuts.
Most stories of founders losing tens of thousands of dollars on a build have one or more of these at the start. I go through the patterns in why founders waste $50K on agencies.
What should the contract say?
Vetting doesn't end at the interview. The contract turns what they promised into something you can enforce. At a minimum:
- Ownership: all code and IP assigned to your company, and all repositories, cloud accounts and app store accounts in your name from day one.
- Scope: a written list of what's in version one and what's out, plus how changes are priced.
- Milestones: payments tied to working demos, not to dates.
- Handover: documentation, setup instructions and a handover session at the end.
These are the terms I work on myself: a fixed quote after scoping, weekly working demos, client-owned code, repos and cloud accounts from day one, written design docs and a handover. I mention it not as a pitch but because you can ask any developer for the same terms, and their reaction tells you a lot.
When don't you need to vet this hard?
If you haven't confirmed that anyone wants your product, you may not need a developer yet. A no-code tool, a landing page with a waitlist or a manual "concierge" version can test demand for far less money. Hire a developer when you know what the first version must do and why. If you're still deciding between a cofounder, a freelancer, an agency or a founding engineer, start with this comparison, and for budget ranges see the MVP cost breakdown.
For a printable version of many of these checks, Blue Coding's non-tech founder's checklist is a useful second opinion (it's a vendor's page, so read it as one).
If you're at this point and want to run these 12 questions on me, that's welcome. Here's how I work and what an MVP costs.
Questions founders ask
What questions should I ask a developer before hiring them?
Ask them to show something live they built and explain one decision they'd change, to cut your feature list to a first version, to estimate it with assumptions, to explain how you'll see progress each week, and who owns the code and accounts. Clear, specific answers matter more than technical vocabulary.
How do I test a developer's skills if I'm not technical?
Pay for a small, real trial: one to two weeks on a slice of your product with a working demo at the end. Judge whether it works when you click it, whether they told you about problems early, and whether the code is in your repository. Optionally pay a senior engineer for an hour to review the result.
Should I hire a freelancer or an agency for my MVP?
Either can work. The vetting is the same: you need to know which named person will write the code, see their past work, and own the repository. Agencies add project management but often staff junior developers on small accounts. Freelancers are cheaper but are a single point of failure, so ask how handover works.
What are red flags when hiring a developer?
A price given before any questions about your product, no live examples, refusing to work in a repository you own, large upfront payments with no milestones, vague answers about who will do the work, and agreeing to everything on your feature list without pushing back. Each one predicts a specific way the project goes wrong.
Do I need a technical cofounder to hire developers?
No. Plenty of non-technical founders hire well by using a structured process, a paid trial and an hour of review from a senior engineer they trust. A technical cofounder is a different decision about who owns the product long-term, not a requirement for hiring.