10 Questions Every Non Technical Founder Must Ask Before Hiring a Developer

What you actually need to know

• Most founder developer disasters do not happen because the developer was bad. They happen because the founder did not ask the right questions before signing.
• The right questions are not technical. They are about scope, communication, ownership, and what happens when the project hits the wall, because it will.
• A good developer welcomes these questions. A bad developer flinches at them.
• You do not need to understand the answers in full. You need to listen for confidence, specificity, and the willingness to give you a straight no.
• Trial work always beats interviews. Two weeks of real work tells you more than two months of conversations.
• The ten questions below are mine. They are the ones I would want a founder to ask me if I were the one being hired.

The core argument

The trap most non technical founders fall into is treating the hire like a vendor decision. You compare three quotes, you pick the middle, you sign. That works for office furniture. It fails for software, because software is not a deliverable. It is an ongoing relationship with the person who knows how your product actually works. A bad signature here costs you six months of runway, and the second engineer you hire to clean it up costs more than the first one did.

I take work from founders who have lived through one of these. The pattern is the same every time. They hired the cheapest option, the work shipped late, the codebase was unreadable, and now they are paying someone like me to either rewrite it or apologize for it to investors. The cheap hire ends up being the expensive one, on a delay of about nine months. I would rather you not learn that lesson firsthand, so I am writing the questions down.

The questions are not a script. They are a frame. The first three test whether the developer has actually shipped anything. The next three test whether they can communicate under pressure. The last four test whether the working relationship will survive contact with reality. If a developer cannot give a clean answer to all ten, you have the data you need. You walk.

The hardest part for a non technical founder is trusting the gut response. You are going to hear a lot of words you do not fully understand. Some of those words will be honest, some of them will be smoke. The thing that separates one from the other is not the vocabulary. It is whether the developer slows down when you ask a follow up, or speeds up to bury the question. Real seniors slow down. They like the follow up. The follow up is where they get to be useful.

The ten questions

1. Walk me through the last production system you shipped, from kickoff to launch. The honest answer takes about four minutes. It names the stack, the timeline, the largest unexpected problem, and what they would do differently. Anyone who keeps it at the marketing layer is not the hire.

2. What part of my project worries you the most? This question is impossible to fake. A real engineer has already started building a mental model of the risks. If they tell you nothing worries them, they have not thought hard enough or they are afraid to say something that might lose the deal. Both are disqualifying.

3. If I told you I wanted to add three more features tomorrow, how would you respond? You want to hear a polite but firm version of "let me push back." The wrong answer is "sure, no problem." Scope creep is the number one reason MVPs miss their launch, and a developer who never says no is a developer who will absorb your worst instincts as a founder.

4. How do you handle a week where you fall behind? The answer should include the words "I tell you on Monday, not on Friday." If they tell you they never fall behind, run. Everyone falls behind sometimes. The question is whether the communication holds up.

5. Who owns the code when we ship? You own it. Full stop. There should not be ambiguity. If they hedge, hesitate, or talk about "licensing the framework I use," that is a conversation that needs to be settled in the contract before any code gets written. I have seen this used as leverage in disputes and it never ends well for the founder.

6. What is the smallest possible version of my product that would still be useful to a paying customer? This question sorts the engineers from the order takers. A good developer has opinions about your product. They have already mentally drafted a smaller MVP than the one you brought to the meeting. If their answer is just a polite rephrasing of your spec, you do not have a partner, you have a wage worker.

7. How do you decide when something is good enough to ship? You are listening for a definition of done that includes "real users can complete the core flow without my help," not "all tickets are closed." The first definition is product. The second definition is busy work.

8. What happens to my project if you get hit by a bus? Morbid but necessary. The good answer is "you have access to the repository, the deployment pipeline, the database, and the documentation. You can hire any competent developer to pick up from where I left off." The bad answer is silence.

9. What is your hourly rate, and what is the smallest engagement you take? You want price clarity. You want to know if they can take a five hour task or only a five week sprint. The reason matters less than the willingness to say a number out loud without dodging.

10. Why are you taking this project? This is the cleanest signal in the conversation. You want to hear something that is not "I need the money." You want them to be slightly excited, slightly nervous, and clear about what about your problem matched their interest. If the answer is purely commercial, the work will be too.

What it actually costs

The numbers above are honest ranges based on what I see in the market and what I have charged for comparable work. They are not universal. They will move based on your country, your scope, and how much of the spec you have written down before you talk to anyone. The single largest variable that controls cost is whether you have a clear product brief or a vague hope. Clear brief, lower cost. Vague hope, every developer pads their estimate by forty percent or more to absorb the risk.

What features to look for in the developer

• A live portfolio at a real URL. Not Figma screens, not Loom walkthroughs. Actual production work.
• A GitHub profile with regular commits across more than one repository. A dormant profile is a signal.
• Written communication that is clear, on time, and not over polished. Over polish is often agency ghost writing.
• A clear answer to what they will not work on. Specialists who know their boundaries are rarer and more valuable than generalists who say yes to everything.
• An opinion about your product, offered without prompting. Engineers who only react to your spec are order takers. Engineers who push back are partners.
• A reference call that the developer offers without being asked. The ones who hesitate to give references have a reason.

Expert opinion

Most of the founders I work with come to me because the previous developer disappeared, missed every deadline, or shipped a codebase the next engineer cannot read. The questions in this article would have caught all of those problems in the first conversation. Asking them is not rude. It is the cheapest insurance a founder ever buys.

>

Yashveer Singh, founder of Yashveer Labs

How this plays out in practice

When I took on the Velmora build, the founder did not know how to read code. He had a clear product brief, a budget, and one question he kept coming back to: how do I know you are going to ship this. I answered with a two week trial, a weekly demo cadence, and a written rule that any feature added mid sprint required a written tradeoff. We hit the launch date. We are still working together. The framing in the first meeting set every conversation that followed.

The opposite story is one I am still cleaning up. A founder came to me with a half built SaaS that another developer had abandoned. The contract was a single page, the codebase had no documentation, and the previous developer had used a personal AWS account that the founder had no access to. Recovering that situation took six weeks and cost more than rebuilding the system from scratch would have. The question that would have prevented it was number eight on this list.

If you want to see what the other side of a clean handover looks like, the systems stack page lays out how I document the work. The projects page shows the live URLs.

Common mistakes founders make in the first hire

1. Hiring on price alone. The lowest quote almost always becomes the highest bill, because the work has to be redone or completed by someone else.
2. Skipping the trial period. Two weeks of real work is the single most predictive signal you have. Skipping it to save time costs you months later.
3. Treating the developer like a contractor when you should be treating them like a partner. The good ones want context. Withholding it makes them work blind.
4. Letting scope creep go unmanaged. A developer who never pushes back on scope is a developer who is silently padding the timeline.
5. Not setting a weekly demo cadence. Without a forcing function, the project drifts. With one, problems surface early enough to fix.
6. Assuming "fixed price" means "no surprises." Fixed price contracts shift the risk to the developer, who absorbs it by padding the estimate. You pay for the padding whether the risks materialize or not.
7. Not getting access to the production accounts on day one. Hosting, domain, database, repo, secrets. If the developer holds the keys, the developer holds the leverage.

Where to start, a 30 day plan

1. Week one. Write a one page product brief. The problem you are solving, the customer you are solving it for, the smallest version of the product that would be useful, and the budget range you can support. If you cannot write that page, you are not ready to hire yet.
2. Week two. Source three candidates. One from a referral, one from a public portfolio, one from a job board or platform. Have a thirty minute call with each. Ask the ten questions. Take notes.
3. Week three. Pick one. Run a paid two week trial on a real piece of the product. Pay the trial regardless of outcome. Cheap insurance.
4. Week four. Make the call. If the trial was clean, sign the longer engagement with a weekly demo cadence baked into the contract. If the trial was muddy, walk. Either way, you have spent four weeks and a small fraction of the budget to avoid the six month mistake.

For more on the framing behind these hiring conversations, the vetting framework covers reference checks and trial structure in detail, and red flags in a developer's portfolio covers the visual cues that should make you slow down. If you are still deciding between an agency and a freelancer, the freelance vs agency comparison lays out the math.