How to Hire an App Developer: 7 Questions to Ask First

You have three quotes for the same app: $18,000, $42,000 and $95,000. Every team sounded great on the call. Friendly, confident, “yes, we can do that.” So how do you choose?

Most guides on how to hire an app developer start with portfolios and hourly rates. But most software projects that go wrong don’t go wrong in month six. They go wrong on that first call, because nobody asked the questions that show how the team actually works. A quote tells you the price. It doesn’t tell you what happens when you change your mind, who owns the code, or what “done” means.

Our senior delivery team has spent 8+ years on the agency side, shipping software for US businesses. We’ve watched projects ship and we’ve watched them stall, and looking back, the warning signs were usually there from the start. Below are the seven questions we’d want every business owner to ask, what a good answer sounds like, and the red flag to listen for.

One rule before you start: don’t judge the answers by how confident they sound. Judge them by how specific they are. A good team answers with steps, names and dates. A risky team answers with reassurance.

What happens in the first two weeks?

This one question tells you more than any portfolio. Ask it exactly like that.

Red flag: “We’ll start coding on Monday.” It sounds fast. In practice it means they’re about to build from your one-page brief and fill every gap with a guess. You find out which guesses were wrong months later, when changing them is expensive.

Good answer: “First we run discovery. We interview you and your users, map the screens, and write down what’s in version one and what isn’t. Then we give you an updated estimate.”

Discovery is usually a short, paid phase. That’s fine. It’s the cheapest point in the whole project to change your mind, and it’s where a vague idea turns into something two people can agree on.

Fixed price or hourly, and what happens when I change my mind?

You will change your mind. Everyone does, once they see the app working. So the real question isn’t the pricing model. It’s what happens to a change.

Red flag: “Fixed price, everything included, no surprises.” If the scope is fuzzy, a fixed price either has a buffer baked in, or it turns into an argument about what was “in scope” every time you ask for something.

Good answer: they explain both options. Fixed price works when the scope is clear and small. Time and materials, where you pay for the hours actually worked, works when you expect to learn as you go. Either way, they describe a change process: you ask, they estimate the impact on cost and timeline, and you approve it in writing before anyone builds it.

This is also where a low app development cost on paper can quietly become the most expensive option. A cheap quote with no change process often costs more by the end than a higher quote with one.

Who owns the code and the accounts?

This is the question most people never ask, and the one that hurts most later.

In the US, when an outside developer writes code for you, they generally own the copyright, even though you paid for it, unless the contract assigns it to you in writing. This isn’t legal advice, so have your lawyer read that clause. But you need to know to ask.

And it isn’t just the code. Who owns the domain? The app store accounts? The hosting account, the database, the payment account?

Red flag: “We’ll host it for you on our account, it’s easier.” Easier for them. If you ever part ways, your app is sitting in someone else’s account.

Good answer: “You own everything. The code lives in a repository your company owns, the servers sit in your cloud account, and the app store listings are under your company. We just get access.”

How will we both know a feature is done?

“Done” often means “it worked once, on the developer’s laptop.” That’s not the same as working for your customers.

Red flag: “We’ll test everything before we hand it over.” Test it against what?

Good answer: “For each feature we agree on acceptance criteria up front. Plain-English checks, like: two customers can’t book the same slot. We show it working in a test environment, and you sign it off before we move on.”

While you’re on this topic, ask one more thing: “Do you use AI tools to write code, and who reviews what they write?” Using AI to work faster is normal now, and it can make a good team more efficient. Nobody checking the output is the red flag.

Who exactly will work on my project?

The person on the sales call is rarely the person writing your code. This matters whether you’re talking to a freelancer or a large app development company.

Red flag: “Our team of fifty developers.” Fifty developers won’t build your app. Three or four people will, and you haven’t met them.

Good answer: names and roles. Who is your project manager? Who is the lead developer? Who tests? How many hours a day do their working hours overlap with yours? And can you speak to a past client, on a call, about a project like yours?

If you’re working out how to hire developers you’ll be in contact with every week, this is the question that tells you who those people actually are.

How will I see progress?

Status reports are easy to write. Working software is not.

Red flag: “We’ll send you a weekly update.” Then, week after week, “85% done.” You can’t click a percentage.

Good answer: “Every one or two weeks we demo working software in a test environment you can click through yourself. You also get access to the task board, so you can see what’s in progress and what’s blocked.”

If you can’t see it working, it isn’t progress.

What happens after launch?

Launch isn’t the finish line. It’s the day real users start finding what testing missed.

Red flag: “Once it’s live, we’re done.” Or nothing in the contract about it at all.

Good answer: “There’s a warranty period, usually a few weeks to a few months, where we fix bugs at no extra cost. After that we offer a support plan, or we hand everything over with documentation so any team can take it on.”

That last part matters. A team that’s happy to make itself replaceable is usually a team worth keeping. For what to plan once your app is live, read our guide to software maintenance after launch.

How to hire an app developer: listen for the pattern

Seven questions: the first two weeks, changes, ownership, what “done” means, who’s on it, seeing progress, and life after launch.

You don’t need a perfect answer to all seven. You’re listening for the pattern. Specific answers, with steps and names, mean the team has done this before. Vague answers mean you’ll be the one finding out how it works, with your budget.

Now go back to those three quotes. The cheapest one isn’t always the risky one, and the most expensive one isn’t always safe. The answers to these seven questions will tell you more than the price ever will. And once you’ve picked a team, our guide to software maintenance after launch covers what to agree on before go-live.