What to Ask a Developer Before Hiring Them: Eight Questions

What to ask a developer before hiring them comes down to eight questions, and the reason there are only eight is that no paid work has begun yet. The app exists and runs, but at this stage there is nothing of theirs to be shown and no error of theirs to be opened. You are buying one person’s judgement about an app that already exists, and the only evidence in the room is what they say about it. This page gives the eight questions, what a real answer names for each one, what a hand-wave names instead, and the point where no answer settles anything.

Eight questions cover most of what decides whether the arrangement works: what they would keep, where they would look first, what they have done with machine written code, what they need from you, whose name the accounts sit in, what you will be shown on the day it is called done, what happens overnight, and what the next person gets.

The eight questions below were set against what four of the hiring guides currently ranking for them tell owners to ask, read on 26 August 2026, and each answer key was checked twice: against the account roles GitHub, Stripe, Supabase, Vercel and App Store Connect publish in their own documentation, and against what AxonBuild’s fixed study of 26 AI-built applications audited in June and July 2026 found missing. Nobody was interviewed for this page, no candidate was hired, and no app was examined.

What you are judging before anyone has touched your app

Someone put their own position into a single line while asking other people for help in public:

I have no technical background but I had to hire a developer to make real, scalable software I could sell.

They were not asking how to read code. They were asking how to buy the work of somebody who can, which is a harder problem. When there is a running app in front of you, a good question opens something on screen. Before there is one, a good question makes the candidate describe your app back to you.

That is the whole grading rule, and every question below leans on it.

Before anyone has touched your app, a real answer names something that would only be true of your app. A hand-wave names something that would be true of any app.

A real answer also names what would change the candidate’s mind. Somebody who says they would probably keep the payment code, and would think again if refunds turn out to be written in three different places, has told you two things at once: what they currently believe, and what would move them off it. Somebody who says every AI-built app needs the same three fixes has told you what they say to everybody who calls.

A thread in r/EntrepreneurRideAlong titled “Where do people find strong freelance mobile developers these days?”, read here on 25 August 2026, drew a reply making the same argument from the other side of the table: a portfolio settles less than asking somebody to walk you through what they built and the decisions they made. The person giving that advice was also offering their own services in the same reply, which is worth knowing and does not make the advice wrong.

Plenty of owners are told to hire somebody long before they can say what they would be buying. Where you find candidates, and whether a freelancer or an agency fits the job, is a decision this page assumes you have already made. If the last person you paid has already stopped replying, getting your accounts and your data back is the job that comes before this one, and the hiring conversation waits until it is done.

Eight questions to ask before hiring a developer

The eight below cover the person and the app between them. Each one has a shape a real answer takes and a shape a hand-wave takes, and you can hear the difference live without understanding a single technical word in either. Ask them in one sitting, in this order.

As of 26 August 2026, the pages ranking on Google for this question are written for somebody commissioning an app that does not exist yet: web design studios, app development agencies and hiring marketplaces, all pricing a build. The closest one to this page is a software house’s guide published on 19 August 2026, which gives ten questions with a good answer and a red flag for each and does name machine written code and store accounts. It is named here and not linked, because it sells development work. Its reader is buying a new build, so its answer key grades promises about how future work will be run rather than statements about an app that already has customers.

What would you do with what is already there: keep it, or start again?

Keeping and starting again are both real answers, and the useful part is never the verdict. A real answer names which parts of your app they would keep and what they would need to see to change their mind. A hand-wave calls the whole thing a mess.

The reason the verdict tells you nothing is that it is true of almost every app built this way. AxonBuild’s fixed study, 26 AI-built applications audited across June and July 2026, put 22 of them in the red band and none in green, counted from that study’s findings ledger. The method behind that band, and every other number on this page, sits in what a fixed study of 26 AI-built apps actually found. “This is a mess” describes the overwhelming majority of them. It separates no candidate from any other candidate, and it is also the cheapest thing to say, because a rebuild is simpler to price and simpler to hand over than picking through work somebody else left behind.

So listen for the parts. “I would keep the database shape and the sign-up and rewrite the checkout, because that is where the three of them disagree about what a paid account is” is an answer about your app. Whether the thing is worth cleaning up at all is a decision with its own arithmetic, worth making before you go looking for somebody to carry it out.

Owners routinely advertise the last tenth of an unfinished build as the easy part, which is why a candidate who asks what is left rather than what is done is already ahead. If most of what you are buying is the part that was never started, turning “nearly done” into a list somebody can price is the step before any of these questions.

Which part of my app would you look at first, and why that part?

A real answer names a part of your app and a reason: the checkout, the sign-up, the invite flow, the page where one signed-in customer could end up looking at another customer’s information. A hand-wave names the codebase as a whole, or says they would start with best practice.

The reason matters more than the part. Anybody can guess that checkout is important. A candidate who says they would look at checkout because you told them refunds are what customers complain about has tied their answer to something you said five minutes earlier, which is the only proof available at this stage that they were listening.

One kind of answer gets misread as evasion. A candidate who says they would check what the app is built on before they open anything else is naming the cheapest real finding there is. Nine of the 26 apps in the same fixed study were running a framework release with a hole that was already published and reachable from outside, and closing it usually meant bumping one version number. That is the highest-value hour anybody spends on an app like yours, and a candidate who reaches for it first is not avoiding your question.

Security is where owners expect this question to go. The point of asking it is narrower: whether the person can prioritise inside your app, which is the skill you are renting.

Have you worked on code a machine wrote most of, and what did you do differently?

A real answer names a tool and one concrete difference in how they worked. A hand-wave recites the stereotype, which is that AI writes code that leaks API keys.

The stereotype is worth knowing about precisely because the data does not support it. Secrets and credentials scored best of the twelve areas measured in the same study, averaging 84 points out of a hundred over its 21 third-party apps, and 6 of those 21 still shipped a live secret, both counted from that study’s findings ledger. A candidate whose entire answer is about leaked keys is describing a headline. A candidate who says the generated code usually looks finished and usually is not checked anywhere, and that they read the paths touching money first because that is where a plausible-looking mistake costs something, is describing what the code does.

Naming the tool is the easy half. Bolt, Replit, Lovable, Base44, v0, Cursor and Claude Code each leave different traces, and somebody who has worked inside one of them will say so without being asked. If the person you are about to hire will be working on code a machine wrote, what changes is where the weak spots sit rather than what you ask for.

Nobody needs to have used your exact tool. What you are listening for is whether they have opinions formed by working on this kind of code, or opinions formed by reading about it.

What do you need from me before you can tell me what this will take, and what do you not need?

A real answer names specific access and, more usefully, names what they will not need. A hand-wave asks for everything and sorts it out later.

The second half does the work. A candidate who says they do not need your production customer data to give you a number, and would rather work from sample rows, has told you how they intend to treat the thing your customers trusted you with. Stripe’s own Start a team page puts the same principle in one line for the people doing the inviting: “Grant the lowest permission required by the user to perform their job.” It is a reasonable standard to hold a candidate to before they have asked for anything.

Asking a candidate to get the app running on their own machine first, once confidentiality terms are signed in writing, is part of a longer set of checks that decide whether somebody has really taken the app over. At this stage you are only listening to what they ask for.

Writing down what you want built, in plain words, before anybody prices it is the piece of homework that makes every answer here sharper. A candidate given one sentence about the outcome will ask better questions than a candidate given a tour of the app.

Whose name are the accounts in while you work, and after?

A real answer names a role on each account and leaves the account itself with you. A hand-wave says the accounts will be set up on the developer’s side and transferred at the end.

That transfer promise is the single most expensive sentence on this list, and it is avoidable. Three of the four accounts that matter document a role for this outright, and the fourth documents one on its paid team plans. Four platforms, read on 26 August 2026:

Two details from those same pages are worth having in your head while the candidate talks. Stripe’s page documents exactly one owner per account, so on the payment account there is nothing to share and only a role to grant. GitHub’s page states that “All links to the previous repository location are automatically redirected to the new location”, which is the reassurance a candidate reaches for when they argue the repository can live on their side for now. The redirect is real. It does not change whose account the code is in this month.

App store accounts are the exception, because there the transfer really is a procedure. Apple’s App transfer criteria page, read on 26 August 2026, lists published conditions an app has to meet first: it has to have had a version released to the App Store, it cannot sit in states such as Waiting for Review, In Review or Pending Developer Release, and “Apple Arcade apps can’t be transferred.” “We will transfer it at the end” has preconditions on somebody else’s page.

Which accounts have to be in your name, all of them, and how to check each one in under a minute is a longer list than this table and worth walking before you hire anybody.

What will you show me on the day you say it is done?

A real answer names the thing you will watch happen inside your live app. A hand-wave promises an update, a walkthrough, or a summary of the work.

This is the question owners most often get talked out of, usually gently. One owner described their position while looking for somebody, with customers already lined up: “customers on our waitlist who have agreed to trial… We are looking for a developer… wary about tests/security”. Somebody in that position needs to know the thing works before the trial starts, and only one kind of evidence does that job.

What you agree to be shown is a thing happening on screen in your own app, not a summary of it arriving in your inbox.

The answer to listen for next is what runs between the change being made and your customers seeing it. Here an honest no is the ordinary starting point: at least 17 of the 21 third-party apps in the same fixed study had nothing checking a change before it reached customers, and all 5 founder-owned apps in the study were the same, counted from that study’s findings ledger, which records the notable findings rather than all 958. So “there is nothing checking your releases today and I would put something in first” is a candidate describing your app accurately and saying what they would do about it. A candidate who says everything is tested and cannot say what runs has described a habit.

What happens when it breaks at 2am?

A real answer names who finds out first, how they find out, and what they will do before morning. A hand-wave says they are always available.

Availability is not the answer, because the failure you are worried about happens while everybody is asleep, the candidate included. The chain has three links: something notices, somebody is told, and that person can act at that hour. A candidate who says nothing currently notices, and would rather set up the thing that tells you the app is down before a customer does in the first week, has given you the most useful answer in the conversation.

A second kind of overnight failure costs money rather than uptime, and it does not look like breakage. In the same fixed study, 12 of the 14 third-party apps that had an AI feature had a path by which somebody with no account, or a free one, could run up the owner’s AI bill, counted from that study’s findings ledger. Nothing goes down. The app answers every request politely and the invoice arrives at the end of the month. Ask what would notice that.

If we stop working together, what does the next person get on day one?

A real answer says which account the code sits in, what somebody else would have to install to run it, and what a new person is given before they can change anything. A hand-wave says any developer could pick it up.

Asked after delivery, this is a request for information. Asked before the hire, it is a term of the arrangement, and that is the whole difference. You are not checking whether the situation is currently good. You are agreeing now what it will look like later, at the only moment when nobody has anything to defend.

Almost nobody asks it, because opening a conversation about somebody leaving while you are trying to persuade them to start feels rude. It costs nothing and it is the only answer here that still has value a year from now. What the next person actually needs on day one is a list rather than a feeling, and a candidate who has been on the receiving end of a bad one will recognise every item on it.

How to score the answers while they are talking

Three things decide the score, and nothing else on the call does: whether the answer names something specific to your app, whether it names what would change the candidate’s mind, and whether it names who decides. Everything else is tone, and tone is the thing most owners over-weight.

The third one is easy to miss. “I would probably rewrite it” and “I would rewrite it if you agree once I have shown you what is duplicated” are the same opinion with a different owner attached. The second version leaves you holding the decision. On a job you cannot inspect, that is the difference that shows up in month three.

Then calibrate, because the answer that worries owners most is usually the one that should worry them least.

Expect some honest no answers; on an app built with AI tools a few are common, but the count that matters is whatever your own app produces once somebody has looked at it.

The one to watch for is the fluent, confident answer that would have fitted any app on earth. A candidate who has never seen your app and describes it correctly is guessing well, and guessing well runs out at exactly the point you start paying for it.

If the set comes back mixed, take the two weakest answers and ask them again in writing, a day later, in the same words. The gap between the spoken version and the written one tells you more than either version on its own.

Checking somebody’s history, their references and the work they say they shipped is a separate exercise from grading what they tell you, and it answers a different worry. Owners looking for a way to vet a developer usually want this page’s answer key as well, and the two halves work best together.

None of this scores price, deliberately. Rates depend on where somebody is and what they do, and the candidate who answers all eight well may be the more expensive one on your list. What the same work costs through each hiring route is a separate comparison, and it belongs after this conversation. If what you want is somebody to repair one thing rather than somebody to work alongside for months, that page splits the two.

What no answer settles, whoever you hire

Three answers sit below the level any conversation reaches. Whether the version your app runs on carries a hole somebody has already published. Whether a live key is sitting in the project’s saved history. Whether one signed-in customer can pull up another customer’s rows. Knowing which three keeps you from over-reading a good conversation.

A candidate can only tell you what they expect to find in those three, and expecting is not the same as having looked. Nobody can know them about an app they have not opened, and a person who states them as facts before reading the code has told you something useful about how they talk.

This is where owners usually ask how do I judge a developer’s answers if I cannot read code, and the honest end of the answer is that eight of them get you most of the way and then stop. The rest is covered by paying somebody to read the code before you commit to a bigger job, a small bounded purchase next to the work you are about to buy. Buying somebody’s reading of the code, and understanding what actually comes back from one, is a different transaction from hiring a person to work on the app.

Once somebody has built the thing and you are grading what they hand back, the requests change, because there is a running app to be shown rather than an intention to be described. Keep the two conversations apart. Everything above assumes none of their work exists yet to open.

Common questions about hiring a developer for an app that already exists

What should I ask a developer before hiring them if I cannot read code?

Ask the eight questions above, in one sitting, and grade each answer on whether it names something specific to your app. You do not need to understand the technical content of any answer to do that. A candidate who names your checkout, your refund complaints and your sign-up flow is answering about your app; a candidate who names best practice, clean code and modern standards is answering about apps in general.

The second thing to listen for is what would change their mind. An opinion with a condition attached to it is a considered opinion. An opinion with no condition attached is a position.

What are the red flags when hiring a developer for an AI-built app?

Four are worth watching for, and none of them is a technical claim. A verdict on the app before they have opened it. A request for your production customer data at the quoting stage. A promise to set the accounts up on their side and transfer them at the end. And a fluent answer to every one of the eight questions with no honest no and no uncertainty anywhere in the set, which usually means they are describing apps in general rather than yours.

The last one surprises people. In AxonBuild’s fixed study of 26 AI-built applications audited in June and July 2026, not one came out green, so a candidate who finds nothing worth flagging in yours has either not looked or is not saying.

Do I have to tell candidates the app was built with AI?

Yes, and early, because it changes what a sensible first look costs and where a sensible person starts. Hiding it buys you nothing: the traces are visible to anybody who opens the repository, and a candidate who finds out on day two will reprice the work on day three.

It is also not an admission of anything. What turns up in machine written code is what generators leave out by default, and it turned up in the founder’s own apps in the same study.

What if a candidate answers in words I do not understand?

Ask them to say it again in words you do, once, then judge the second answer rather than the first. Anybody who works with owners for a living can do this, and the ones who cannot are telling you what the next six months of updates will read like.

If the second answer is still opaque, ask what it would look like on screen when it is working. That has a plain-language answer every time, because the thing either shows up in your app or it does not.

What if every candidate says the app should be rebuilt?

Take it as data rather than a verdict, then make the candidates argue with each other on paper. Ask each one which parts they would keep, and compare the lists. If three people independently want to keep the database and rewrite the checkout, that is a finding. If three want to rewrite everything and none can say which part is worst, that is a habit.

That incentive, as question one sets out, has nothing to do with your app. Settle the cleaning-up-or-starting-again decision before you hire, because it changes what you are buying and who to buy it from.

Can I send these questions in writing instead of asking on a call?

Yes, and there is a real trade. Written answers are more careful and easier to compare across candidates, and they lose the thing a call gives you, which is watching somebody think about your app in real time and hearing what they ask you back.

The version that works best is both: send questions one, four, five and eight in writing, then talk through the rest. Running the hire itself, from the first message to the agreed start date, is its own sequence, and these eight are what you say once you are in the conversation.

Do these questions work for an agency as well as for a freelancer?

They work for both, with one addition for an agency: ask who specifically will do the work and whether you get to put these same questions to them. The person on the sales call is often not the person who opens your code, and the answers you graded belong to whoever is on the call.

Questions to ask a freelance app developer and questions to ask an agency are otherwise the same eight, because both are selling judgement about an app that already exists. The agency answer that should slow you down is the one where nobody will name the person.

What if I already hired somebody and never asked any of this?

Ask a different set, because the instrument has changed. There is a running app now, so the useful move is asking to be shown things rather than asking what somebody would do: the feature working on a live account, the last error a customer hit, the accounts list read out loud. Answers you can watch beat answers you have to grade.

Nothing is lost by having skipped the pre-hire version. Most of what these eight surface early turns up in the first month anyway, at more cost in attention than the asking would have taken.