1–2 spots available for Q2 · Claim yours→
Back to Articles

15 Questions to Ask a Developer Before Hiring (For Non-Technical Founders)

A practical checklist for non-technical CEOs and founders. Each question comes with why it matters, what a strong answer sounds like, and the red flags to walk away from. Drawn from 16 years and 250+ projects of hiring and rescuing developers.

By Adriano Junior

Why these questions to ask a developer before hiring matter

Hiring the wrong developer is expensive in ways that do not show up on the invoice. Per BLS data, median pay for software developers in the US sat near $130K in 2023, and senior contract rates routinely exceed that. A failed three-month engagement can quietly cost a small company a quarter of its annual development budget once you count rework, rehiring, and the lost calendar.

The questions to ask a developer before hiring exist for one reason: to surface the things a non-technical founder otherwise discovers in month four of a stalled project. Over 16 years and 250+ projects, including time as a senior engineer at the bolttech $1B+ unicorn and the Cuez API rescue that went from three seconds to 300 milliseconds, the same patterns keep showing up in the conversations that go badly. This guide is the conversation I wish more founders had at the very start.

TL;DR

Before hiring a developer, work through five categories: technical competence (can they actually build what you need?), process and communication (will you know what is happening?), timeline and budget (will it stay on track?), experience with your use case (have they done this before?), and references and track record (can you verify they deliver?).

Each of the 15 questions below comes with why it matters, what a good answer sounds like, and the red flags worth walking away from. The standards are the same whether you hire a freelancer, a contractor, or an agency.

Table of Contents

Technical Competence

The goal is not to become a programmer overnight. It is to understand whether this person can actually build what the business needs. A strong developer explains technical choices in business language, not jargon.

Question 1: What is your tech stack, and why those choices?

Why it matters: the stack — languages, databases, frameworks — directly drives how fast the project can be built, how much it will cost to maintain, and how easy it will be to hire other developers later. A developer who picks a stack on "I just love this framework" rather than "this fits your timeline and your team's experience" is a red flag.

What a strong answer sounds like:

"For your project, I would recommend React on the frontend because you need real-time feedback, and React scales well as you add features. On the backend I would use Node.js because your team is already familiar with JavaScript, which reduces training when you hire others. I would use PostgreSQL because your data is relational and you will need complex queries. I picked these to balance your timeline, budget, and long-term maintainability."

Red flags:

  • "I always use [framework]. It is what I know best." (Comfort, not fit.)
  • Vague answers or reluctance to explain the why.
  • An overly heavy stack for a simple application.
  • They cannot articulate trade-offs (speed vs cost, scalability vs simplicity).

Question 2: Tell me about your biggest technical failure and how you fixed it.

Why it matters: everyone makes mistakes. What separates strong developers from weak ones is how they respond to failure. Do they hide it, blame others, or own it and fix it? A strong developer walks you through a failure, explains what went wrong, and shows you the lesson they took from it.

What a strong answer sounds like:

"I once deployed a payment system without enough testing. It worked for 95% of transactions and failed on refunds over $1,000. We caught it in production after one customer hit it. I rolled back, added automated tests, and spent two days rewriting the refund logic. I learned to never deploy payment code without full coverage, and I now build a staging environment that mirrors production exactly."

Red flags:

  • "I have not really had any major failures." (Either dishonest or under-tested.)
  • Blaming external factors without owning their part.
  • Cannot name what they learned or how they would prevent it next time.
  • Laughing it off rather than taking it seriously.

Question 3: How do you handle technical debt?

Why it matters: technical debt is the accumulation of shortcuts and quick fixes that slow development over time. Every project has it. The question is whether the developer acknowledges it, manages it, and prevents it from compounding into a rebuild. A developer who says "I never cut corners" is either lying or has never shipped under a deadline. Per McKinsey's research on tech debt, some CIOs estimate technical debt accounts for 20–40% of the value of their entire technology estate before depreciation.

What a strong answer sounds like:

"Technical debt is real. When we are racing to a deadline, I will sometimes write code that works but is not perfectly structured. That is fine in the short term. I track it in a backlog and pay it down during slower sprints. With my last client I ran one cleanup sprint per quarter. I also flag debt to the founder upfront so 'we need a week to clean this up' is never a surprise."

Red flags:

  • "What is technical debt?"
  • "I refactor everything as I go." (Often inefficient and slow.)
  • Dismissing refactoring as not a priority.
  • Cannot give concrete examples of debt they have managed.

Question 4: What frameworks and languages do you specialise in?

Why it matters: depth beats breadth on a real project. A developer with eight years of React experience will ship better and faster than someone with two years each in five frameworks. The answer also tells you how easy it will be to find another developer later if you need continuity.

What a strong answer sounds like:

"I specialise in React and Node.js. I have used them for the past eight years and shipped 30+ production apps. I have also worked with Vue and PHP, but I would not recommend hiring me primarily for those. For your project, React and Node fit. If you ever need to switch stacks, I can learn it, but I would suggest finding someone with five-plus years in that specific stack instead."

Red flags:

  • A list of fifteen frameworks with claimed expertise in all of them.
  • "I can learn whatever language you need." (True, but risky for your timeline.)
  • Cannot quantify experience (projects, years, scale).
  • Specialisation only in dead or outdated frameworks with no learning of newer alternatives.

Process and communication

A brilliant developer who disappears for two weeks is worse than a competent developer who sends a Friday update. These questions reveal how much visibility you will have into your project.

Question 5: How will you keep me updated on progress?

Why it matters: you need to know what is happening. Not daily, but on a predictable cadence so you are never surprised. A developer who waits until the end to show you the work has often hit a problem in week three and is hoping to fix it before you notice.

What a strong answer sounds like:

"I will send you a written update every Friday with what shipped this week, what is planned for next week, and any blockers I am facing. Every other Monday I will run a 20-minute call to walk through new features and gather feedback. If something goes wrong, I reach out immediately rather than waiting for Friday."

Red flags:

  • "I will update you when it is done."
  • No standard cadence.
  • Communication only via Slack (chaotic, easy to miss).
  • "I do not like meetings" with no alternative offered.
  • Vague on how problems will be surfaced.

Question 6: What happens if scope creeps during the project?

Why it matters: scope creep is the single biggest killer of project budgets and timelines. "Just add a small feature" repeats five times and the project is suddenly double its original cost. A strong developer acknowledges the risk and has a process for managing it. The Standish Group CHAOS reports have tracked software project failure rates for decades, and changing scope without process control is one of the most consistent contributors.

What a strong answer sounds like:

"Scope creep kills projects. Here is how I handle it: we define scope in writing upfront, with what is in and out. As you think of new features, I document them as Phase 2. If you want one of those Phase 2 items added before launch, we pause, reassess timeline, and update the contract. You stay in control, and you see the cost impact immediately rather than three weeks later."

Red flags:

  • "We will just fit it in."
  • No formal change-control process.
  • Vague about when scope changes stop being acceptable.
  • No mention of timeline or budget impact.

Question 7: Do you have a written process or methodology?

Why it matters: professional developers have a documented process. Agile, Kanban, or something they have built themselves. The specific method matters less than the fact that one exists. The answer tells you whether they have thought through how to deliver reliably or whether they "just start coding."

What a strong answer sounds like:

"Yes. We start with a discovery meeting to understand requirements. I create a project specification we both sign off on. We then move to two-week sprints where I build, you review, and we iterate. At the end of each sprint, I show you what shipped and we adjust priorities. Everything is tracked in a project tool you can access anytime."

Red flags:

  • "I do not really have a process. I just start building."
  • Cannot explain the process clearly.
  • The process has no client review or feedback loop.
  • No documentation, no structure.

Question 8: How do you handle feedback and changes?

Why it matters: nobody gets a project right the first time. You will have feedback. You will ask for changes. You want a developer who welcomes that, not one who treats every revision as a personal slight.

What a strong answer sounds like:

"Feedback is how we build something good. I structure sprints so every two weeks you see what shipped and tell me what to adjust. The only thing I ask is that we document each change and discuss timeline and budget impact together so there are no surprises later."

Red flags:

  • "Let us lock the requirements and not change anything."
  • Charges extra fees for routine feedback.
  • "You should have known that from the start."
  • Defensive when you ask for revisions.

Timeline and budget

Money and time are tied together. These questions help you avoid "this will cost 50% more" surprises in the second month.

Question 9: Can you break down the cost estimate by deliverable?

Why it matters: a single line that says "$25,000 for your app" tells you nothing. What are you buying? If it slips to $40K, what changed? A developer who breaks costs down by feature has actually thought through the work.

What a strong answer sounds like:

"Sure. Authentication and login: $2,500 (one week). Dashboard with analytics: $4,500 (two weeks). Payment integration: $5,000 (two weeks). Admin panel: $3,000 (1.5 weeks). Testing, deployment, and documentation: $2,500. A 15% buffer for unknowns: $3,000. Total: $20,500. If you cut the admin panel, you save $3,000. If you add a mobile app version, that is a separate scope."

Red flags:

  • A single round number with no breakdown.
  • Estimates are $50K or $100K with no justification.
  • Cannot explain what each component costs.
  • "I will give you an estimate once I start." (A professional estimates before starting.)

Question 10: What is included in your price, and what is not?

Why it matters: is hosting included? Revisions? Post-launch support? Domain registration? Hidden costs and assumptions kill projects. You need clarity upfront.

What a strong answer sounds like:

"My $20,500 price covers all development, testing, and deployment. It does not include: server hosting (budget $50–$200/month depending on traffic), SSL certificate (free these days), a domain name (you buy that separately), or new features after launch. After launch I provide 30 days of free support for bugs. After that I am available at my hourly rate or on a small monthly retainer."

Red flags:

  • Vague about what is in.
  • "We will figure it out as we go."
  • Hosting, maintenance, or support quietly missing from the conversation.
  • "That is extra" appearing later.

Question 11: How do you handle delays or setbacks?

Why it matters: everything slips eventually. The question is whether the developer owns the slip, communicates it early, and has a plan to recover. A developer who hides delays until the last minute is the most expensive kind of risk.

What a strong answer sounds like:

"I review risk weekly. If something looks like it will slip, I tell you immediately, not the day before deadline. We then decide together: add capacity, cut a feature into Phase 2, or extend the timeline. I also keep a 15% buffer for unknowns. If we do not use it, you finish early. If we do, we still hit the date."

Red flags:

  • "It will not slip."
  • No early-warning system.
  • Blaming delays on you ("you did not give me requirements fast enough").
  • No contingency plan.

Question 12: What is your payment schedule?

Why it matters: if you are writing a $25,000 cheque, you need to know when. Upfront? In milestones? Monthly? A developer asking for 100% upfront is a risk. One asking for it in stages tied to deliverables is protecting both of you.

What a strong answer sounds like:

"I ask for 50% upfront to cover initial setup and planning. 25% at the midpoint after a progress review, and the remaining 25% at launch. That protects you because you can stop at the midpoint if something is wrong. It protects me because I am not funding your project for three months only to have it disappear."

Red flags:

  • 100% upfront.
  • No clear milestones tied to payment.
  • Payment terms that drift from the original conversation.
  • "Pay me monthly" with no link to deliverables.

Experience and track record

The past is the best predictor of the future. Ask for proof.

Question 13: Have you built something like this before?

Why it matters: experience with your specific use case dramatically reduces both timeline and cost. Someone who has built ten e-commerce platforms will build yours faster and with fewer mistakes than someone building their first one, even if both are equally skilled in the abstract.

What a strong answer sounds like:

"Yes. I have built four e-commerce platforms using React and Shopify's API. The smallest was a custom storefront for a jewellery brand. The largest was a platform for a corporate gift company with 50,000 SKUs. I know the common pitfalls with inventory, payment processing, and scaling. For your case I would recommend using Shopify's admin rather than building one, which saves a few weeks and a chunk of budget."

Red flags:

  • "First time doing your specific use case, but I am a fast learner."
  • Vague about past projects, no concrete examples.
  • "I have built a lot of apps, similar enough." (When they are not.)
  • Cannot articulate lessons learned from past similar projects.

Question 14: Can you show me live projects you have shipped?

Why it matters: anyone can claim to be good. You need evidence. Live projects you can visit are the gold standard. A developer reluctant to show past work is a red flag.

What a strong answer sounds like:

"Absolutely. Here are three recent projects I am proud of: [link 1, link 2, link 3]. For each one I built [specific role and contribution]. A few more sit in my portfolio, and I can send NDA-covered case studies if you want detail on older work."

Red flags:

  • "I do not really have anything to show." (How are they getting hired?)
  • Everything is a basic landing page.
  • Cannot articulate what they specifically built.
  • All projects are pre-2019 with no recent work.
  • NDAs that conveniently prevent any portfolio sharing at all.

Question 15: What support do you provide after launch?

Why it matters: launch is not the end. Bugs surface. Things break. You will need changes. A developer who disappears after launch leaves you stranded.

What a strong answer sounds like:

"After launch I provide 30 days of free support for bug fixes and minor tweaks. After that I am available on an hourly basis or on a small retainer if you expect ongoing work. I also write detailed documentation and a handoff so you or another developer can maintain the code without me if you choose."

Red flags:

  • "You are on your own after launch."
  • No clear post-launch plan.
  • Support only available at high hourly rates with no option for small fixes.
  • Cannot or will not document the code.
  • Unrealistic response times during your business hours.

Reflecting on what these questions are really for

Every question on this list looks like a check on the developer. They are not. They are checks on you.

The goal is not to catch a freelancer in a lie. It is to make sure you do not hire someone whose work style you cannot live with for the next twelve weeks. Most failed engagements I have been called in to rescue did not fail because the developer was technically incompetent. They failed because the founder hired on enthusiasm, signed a vague statement of work, and discovered in month two that the developer's idea of "regular updates" was a one-line Slack message and the founder's idea was a Friday call and a written summary. Both were operating in good faith. They were just never aligned.

If a candidate gives a hesitant or evasive answer to any of these fifteen questions, the answer itself is rarely the problem. The hesitation is. Strong developers have lived through the patterns these questions point at, and they recognise the questions on sight. They are usually relieved someone is asking. The conversation gets shorter and clearer almost immediately.

Sixteen years in, the strongest signal in any hiring conversation is the one that does not fit on a checklist: does the candidate seem more curious about your business than about getting the contract? When the answer is yes, the rest is usually negotiation. When the answer is no, no amount of interview discipline will save the project.

FAQ

How much should I expect to pay a developer?

Rates depend on scope, timeline, and location. In 2026, common ranges:

  • MVP by a freelancer: $10K–$30K, six to twelve weeks.
  • Custom web app by a freelancer: $25K–$75K, eight to sixteen weeks.
  • Web app by a small agency: $75K–$150K, twelve to sixteen weeks.
  • Scalable web app or complex features: $150K+.

The fastest, cheapest path is not always the best. A $30K freelancer who ships in eight weeks can outperform a $75K freelancer who takes sixteen, or vice versa. Compare value, not just price.

Should I hire locally or remotely?

Remote developers are as good as local ones. The trade-off is time-zone alignment and communication style. If you need frequent real-time collaboration, hire someone in or near your time zone. If you can work asynchronously (detailed specs, written reviews), geography matters less than communication discipline.

What if my developer goes silent or disappears?

Written contracts, clear milestones, and regular check-ins exist for exactly this. The contract should include a clause about what happens if the developer becomes unresponsive. At minimum: a 48-hour response window, after which you can pause payment and bring in someone else. Insist on documented code and access to the git repository so a successor can pick up the work.

Can I hire someone cheaper overseas?

Sometimes it works fine. "Cheaper" often means less domain experience, more time-zone friction, or language gaps that slow communication. In my experience, a $50K US developer who ships on time often beats a $20K developer who takes twice as long. Compare total project cost (rate × hours needed), not the headline rate.

How do I verify a developer's references?

Ask for two to three founders or CEOs they worked with. Call each one. The questions: would you hire them again, what is their biggest weakness, did they deliver on time, how did they communicate problems? "Good engineer" is not the same as "yes, I would hire them again." If you do not get the second answer, keep looking.

Should I run a paid trial before committing?

Yes, especially for engagements over $20K. Two to four weeks of real work, scoped and paid, surfaces communication style, judgement, and reliability in a way no interview can. Skipping this step is the single most common mistake I see in failed engagements.

Conclusion

Hiring the right developer is one of the most important decisions a founder makes. The right developer saves you tens of thousands of dollars and months of calendar. The wrong one drains both.

Key takeaways:

  • Ask about their stack choices, not just what they use.
  • Understand their process and the cadence of updates.
  • Get cost and timeline breakdowns, not vague estimates.
  • Verify they have relevant experience with your use case.
  • Ask for live examples and references. Always verify.

Before signing anything, you should be able to answer these:

  1. Why did they choose their specific tech stack?
  2. How do they manage scope creep and communicate progress?
  3. Can you see examples of past work and speak to past clients?
  4. What is included in the cost, and what is the payment schedule?
  5. What happens if something goes wrong or takes longer?

If you are still uncertain after these conversations, that is a signal to talk to a few more developers. Trust your gut. The best hire is someone who leaves you confident, not just hopeful.

Services I offer

Case studies

Related guides

Related Articles

All posts