How to hire a freelance app developer (and what to ask first)

Hiring a freelance developer to build your app is one of the bigger bets a founder or a small business makes. The money matters, but the time matters more: three months with the wrong person is three months your competitors spent shipping. I have been writing code since 2018, and every product on this site — SplitMate, FrameRx, ProAI Training, Clearday and FeedSeek — was built by one developer, end to end. This guide is what I would want a client to check before hiring me, or anyone else.

It is written for people who are not developers. You do not need to read code to make a good hire. You need to ask questions that are hard to fake, and know which answers to worry about.

Start with what you actually need

Before you look at a single profile, write down three things: what the app is for, who uses it, and what has to exist on day one. Not a feature list — a sentence or two each. "Restaurant staff log stock at the end of a shift, and the owner sees what to reorder the next morning" is more useful to a developer than forty bullet points.

This step does two jobs. It forces you to decide what matters, and it gives you a fair way to compare developers: send the same short brief to each one and see how they respond. A good developer will ask about the parts you have not decided yet. A weak one will agree to everything and send a number.

Also decide what kind of help you need:

• A product build — someone to take an idea from nothing to a released app, including all the decisions in between.
• A feature or a fix on an existing app — someone comfortable reading another person's code and working inside it.
• A specialist job — a Shopify app, an AI feature, a payment integration — where narrow experience matters more than breadth.

Most freelancers are stronger at one of these than the others. Ask which kind of work they prefer, and believe them.

Look for shipped work, not screenshots

The best predictor of whether a developer can finish your app is whether they have finished apps before. Designs and mockups are easy to collect. Working software is not.

When you look at a portfolio, ask:

• Is it live? Can you install the app, open the site or see the store listing? A case study about a product that never shipped tells you about the design, not the delivery.
• What exactly did they build? "Worked on" covers everything from fixing one button to building the whole system. Ask which parts were theirs: the app, the backend, the admin side, the release.
• Can they explain the hard part? Every real project has one. In SplitMate, the hard part was not the arithmetic of splitting a bill. It was a data model where every expense balances to zero, so each person's balance falls out of the data instead of being patched on top. A developer who built something should be able to describe the equivalent for their project in a couple of sentences.

If a developer has public code, look at it even if you cannot judge it line by line. Recent activity, readable commit messages and a README that explains the project are signs of someone who works in the open. My own repositories are public for exactly that reason: the history is there to read.

Ask how they would scope your project

Scoping is where projects are won or lost, long before any code is written. Send your brief and ask the developer how they would approach the first version. Then listen for three things.

What they would leave out. Good scoping is mostly cutting. If the plan includes everything you mentioned plus a few extras, that is not ambition — it is risk, and you are the one paying for it.

Questions back. Who are the users? What happens when the network drops? Who moderates what people post? Questions mean the developer is thinking about your product, not just the job.

A first milestone you can click. You should be able to try something real early on, not wait for a big reveal at the end. I start with the smallest version that is actually useful and build in pieces from there, because you see working screens early, while changes still cost hours instead of weeks.

Be wary of anyone who gives a confident fixed price without asking a single question. Either the price hides a large buffer, or the scope will be "clarified" later at your expense.

Communication is part of the job

With a freelancer you are not only buying code. You are buying a working relationship that will last weeks or months. Before you start, ask:

• How often will I hear from you, and where? A short written update each week and a link to the latest build beat daily calls about nothing.
• What happens when something is not ready? You want someone who tells you early, with what is blocking it and what they are doing next. Silence followed by a late surprise is the most common way freelance projects go wrong.
• Which time zone and hours do you work? Overlap matters less than predictability. A developer six hours ahead of you can be ideal: you send feedback in the evening and wake up to the changes.

Pay attention to how they write during the hiring conversation itself. The way someone answers your first three messages is the way they will answer your fiftieth.

Agree on ownership before any code is written

This is the part non-technical clients skip most often, and the one that hurts most later. Agree in writing that:

• You own the code once it is paid for, and it lives in a repository you control or is transferred to you at handover.
• The accounts are in your name. App Store and Google Play developer accounts, the domain, the hosting, the database and any API keys should belong to your business, with the developer added as a user. If the developer disappears, you should lose nothing but a contact.
• There is a real handover. At the end you should receive the code, the credentials and enough written notes for another developer to continue without starting over.

I write things down as I go — what a feature is for, why a table has a particular column, what was left out on purpose — because six months later that is the difference between fixing a bug and rewriting the file. Ask any developer you are considering what they will leave behind.

Structure payments around milestones

Freelance projects usually run on one of three models:

1. Fixed price for a defined scope. Clear for both sides when the scope is genuinely clear. Pair it with a written list of what is included and, just as important, what is not.
2. Hourly or weekly. Flexible and fair while the scope is still moving, but it needs visibility: regular updates and a working build you can check.
3. Milestones. A price per stage — for example the core flow working, then the full app, then the store release — with payment released as each one is accepted.

For a first project with a new developer, milestones are usually the safest middle ground. Each milestone should end in something you can try yourself, not a status report.

If you hire through a platform such as Upwork or Fiverr, the platform holds the payment and handles disputes. If you hire directly, a short written agreement covering scope, milestones, payment and ownership is enough for most projects.

Red flags to watch for

• No questions about your users. Building without understanding who will use the app leads straight to rework.
• Everything is "easy". Experienced developers know which parts are hard and say so up front.
• They want to start with the admin panel, the settings screen or the logo. The core flow comes first. The rest can wait until people are using it.
• No working build until the end. Ask to see progress you can click, regularly.
• Accounts registered in their name. Your app should never depend on someone else's login.
• Reluctance to write anything down. Scope, decisions and handover notes protect both of you.

Questions to ask before you hire

Copy these into your first message and compare the answers side by side:

1. Which of your past projects is closest to mine, and what exactly did you build in it?
2. What would you leave out of the first version, and why?
3. What is the riskiest part of this project?
4. How will I see progress, and how often?
5. Who will own the code and the accounts?
6. What will you hand over when the project ends?
7. What happens if we need changes after launch?

There are no perfect answers, but there are revealing ones. A developer who answers the third question with "nothing, it is straightforward" has either not thought about it or is telling you what you want to hear.

Where to find a freelance app developer

You can hire through marketplaces, through referrals or directly from a developer's own site. Marketplaces give you payment protection and public reviews. Hiring directly usually means more conversation up front and no platform fee. Referrals from other founders are still the most reliable source of all.

Wherever you find someone, the checks above stay the same. Location matters far less than most clients expect — I work remotely from Dhaka with clients anywhere — but evidence of shipped work, clear communication and honest scoping matter more than anything written on a profile.

FAQ

How long does it take to build an app with a freelancer?

It depends on scope more than anything else. A focused first version that does one job well can ship far sooner than a full product with an admin side, payments and several integrations. Ask for the date of the first clickable milestone rather than a single finish date.

Should I hire a freelancer or an agency?

An agency gives you a team and a project manager. A freelancer gives you direct contact with the person writing the code, usually at a lower cost. For a first version with a clear scope, a strong freelancer is often the faster route. For a large system with several streams of work running in parallel, an agency may fit better.

Do I need a technical co-founder first?

Not to build a first version. Many products start with a freelance build that proves the idea. What matters is that you own the code and the accounts, so a future technical co-founder or in-house team can pick it up without starting again.

If you are planning an app and want a second opinion on the scope, send me a short brief: what you are building, what already exists and when you need it working. You can also see how I approach projects on the services page, or read how much an app costs to build.