Questions to ask before you hire someone to build your app

When you are about to hand your business process to someone who will turn it into software, the first call feels like a test you might fail. You don't know the technology, so how do you tell a good developer from a smooth talker?

You don't need to know the technology. You need the right questions, and you need to know what a good answer sounds like. These are the ones I would ask if I were in your seat, including the ones that might make someone like me uncomfortable.

Who will actually build it?

Ask who writes the code day to day, and whether you can talk to that person directly.

• Good answer: a name, and yes, you can talk to them.
• Warning sign: "our team" with nobody specific, or a salesperson who disappears after you sign.

Also ask how many other projects that person is working on at the same time. Two or three is normal. If it's many more, your project only gets attention when it is the loudest one.

Have you built something like this, and can I try it?

Not "have you built an app", but something close to yours: a booking flow, a stock count, a customer portal, a dashboard pulling data from other tools.

• Good answer: a live link or a demo you can click through on your own phone.
• Warning sign: screenshots only, or "it's under NDA" for every single example.

How would you start?

Describe your idea in a few sentences and ask what the first week would look like.

• Good answer: questions about your users, your current process, what already exists and what done means. Often a suggestion to start smaller than you planned.
• Warning sign: a full plan and a fixed total after one message. They are guessing, and you will pay for the guesses later.

I wrote about what to prepare for that first conversation in how to brief a freelance developer.

How will I see progress?

• Good answer: a working test version you can open every week or two, from early on.
• Warning sign: status updates in words, and the first real demo near the end.

Working software is the only progress report that can't be dressed up.

What happens when I change my mind?

You will. Everyone does once they see the real thing.

• Good answer: a simple, written way to handle changes: what gets swapped out, what moves to later, and how the size of the work changes.
• Warning sign: "we'll figure it out", or, the opposite, a contract so rigid that every small change becomes a fight.

Who owns the code and the accounts?

This is the question that matters most after launch.

• Good answer: you do. The code lives in a repository in your organisation. The domain, hosting, app store and payment accounts are in your company's name, and the developer is invited as a user.
• Warning sign: "we'll host it for you" under their own account, or code you only receive at the very end.

What happens after launch?

• Good answer: a clear period for fixing bugs that real users find, then a choice: your own team takes over with proper handover notes, or a small ongoing arrangement for updates and fixes.
• Warning sign: silence, or no plan at all for security updates, renewals and backups.

When would you tell me not to build this?

My favourite question, and the most revealing. A developer who never says no is selling hours, not solving your problem.

• Good answer: a real example. "If an existing tool already does most of it, use that." "If the process isn't decided yet, sort that out first."
• Warning sign: they can't think of one.

You can ask me all of these

I am happy to be asked every question on this list, the uncomfortable ones too. Get in touch and I will reply with my own questions first, or see how I work.