If you’re thinking about building an app, you’re probably already picturing it — the icon on your home screen, users downloading it, the problem it solves. What you might not be picturing is the conversation you need to have before any of that is possible.
After 12 years of building apps, we’ve sat across the table from a lot of clients. Some came prepared. Most didn’t. The difference in how those projects went was significant.
Here are the questions you should be asking — and a few you probably haven’t thought of yet.
First: Do You Actually Need an App?
Before you ask anything of a developer, ask something of yourself: is an app genuinely the right tool here?
This is the question we ask every prospective client, and it’s the one that saves more time and money than any other. The assumption that “if I have a website, I should get an app” is one of the most common — and costly — misconceptions we encounter. Apps and websites are fundamentally different. They have different purposes, different capabilities, and very different price tags.
The real reason to build an app is to use technology that only a native mobile application can access: the device camera, GPS location, accelerometer, push notifications, offline functionality. If your idea doesn’t genuinely require those things, a well-built website or web app will almost certainly serve you better — at a fraction of the cost.
So before you pick up the phone to call a developer, ask yourself: what problem is this app actually solving? If you can’t answer that clearly and specifically, you’re not ready to have the conversation yet.
The Questions to Ask Your Developer
1. “What’s your honest opinion on my feature list?”
Most developers, if you hand them a list of features and a budget, will nod and start building. A good developer will push back.
Ask them directly: do they think every feature you’ve requested is worthwhile? Which ones add genuine value, and which ones are padding? This question separates developers who are order-takers from those who are actual partners in your project.
The best app builds we’ve been involved in have always involved a degree of simplification — cutting the features that felt exciting in a meeting but wouldn’t actually be used.
2. “How much of what I’m asking for is based on assumptions rather than real-world feedback?”
This one stings a little, but it’s important. Many app ideas are built on what business owners think users want, rather than what users have actually asked for. A developer worth their salt will want to understand whether your requirements come from user research, customer interviews, or market testing — or whether they’re largely gut feel.
You don’t need to have done formal research to move forward, but you should be honest with yourself and your developer about the difference. Features built on assumptions often get removed after launch.
3. “Can you show me — or tell me about — relevant experience?”
Not every good developer has a sprawling public portfolio. Some of the best work gets built under NDA, for internal business tools, or for clients who simply don’t want their product publicised before launch. A thin portfolio isn’t automatically a red flag.
What matters more is whether they can speak knowledgeably and specifically about problems similar to yours. Ask them: have you integrated third-party APIs before? Have you built anything with CarPlay support? These are the kinds of technical challenges that separate developers who’ve genuinely been in the weeds from those who are figuring it out as they go. A developer who can walk you through how they solved a complex integration problem — even without showing you the finished product — is demonstrating exactly the kind of thinking you want on your project.
References from past clients are worth asking for too. A short conversation with someone who’s actually worked with them will tell you more than any portfolio page ever could.
4. “What happens when things go wrong mid-project?”
And they will. Scope shifts, technical blockers, third-party APIs that don’t behave as expected — this is the reality of app development. Ask your developer how they handle it. Do they communicate proactively? Do they flag issues early or scramble to hide them? How do they manage changes to the brief?
The answer to this question will tell you a lot about whether you’ll enjoy working with this person for the next six to twelve months.
5. “Who owns the code once it’s built?”
This is non-negotiable to ask, and the answer might surprise you.
Intellectual property ownership in software development isn’t automatic. If you want to fully own all the code that’s written on your behalf — meaning you could take it to another developer at any point — that will typically cost more. If you’re willing to license the code rather than own it outright, you can often bring the overall cost down.
Neither option is wrong, but you need to go in with your eyes open. Get this in writing before a single line of code is written.
6. “What will this actually cost me to run after launch?”
The build cost is just the beginning. Before you commit to anything, ask your developer to walk you through the ongoing costs:
– Apple Developer and Google Play Store fees
– Server or cloud hosting costs
– Third-party API subscriptions
– Regular maintenance updates (more on this below)
These costs catch people off guard constantly. A £20,000 app build might come with £500–£1,000 or more in monthly running costs on top. Know what you’re committing to.
7. “Why will this app need ongoing maintenance, and what does that involve?”
Apps don’t stay still. Apple and Google regularly update their operating systems, and apps that aren’t maintained to keep pace with those updates will break, get delisted from app stores, or develop security vulnerabilities.
A good developer will explain this to you upfront. If someone tells you the app is “build it and forget it,” walk away. Ask them specifically: what will maintenance involve in year two? Year three? Who does it, and what does it cost?
8. “What’s your pricing based on, and what could change it?”
This isn’t just about getting the lowest number. It’s about understanding the structure. Is it a fixed price? Day rate? What triggers additional costs — scope changes, delays, third-party integrations that prove more complex than expected?
The clearer you are on this upfront, the fewer unpleasant conversations you’ll have later.
The Green Flag to Look For
If you want a simple signal that a client — or a developer — is serious and prepared, it’s this: have they wireframed the app?
A wireframe is a basic sketch of how the different screens of the app will look and how a user will move between them. It doesn’t have to be polished. It can be done on paper. But if someone has sat down and mapped out the flow of their app before any money has changed hands, it tells you they’ve thought about the product seriously — not just the idea.
If you’re a client reading this and you haven’t done this yet, do it before your first developer meeting. It will sharpen your thinking, save time in discovery, and immediately demonstrate that you’re a client worth working with.
The Red Flag to Avoid
Cheap overseas developers who promise a fully-featured app for a suspiciously low price are one of the most common problems we’re asked to help fix.
We’ve had clients come to us mid-project — sometimes having paid significant deposits — because their developer went silent. Completely disappeared. No communication, no code handover, nothing. Rebuilding from scratch costs far more than doing it right the first time.
The old saying really does apply here: you get what you pay for. That doesn’t mean the most expensive developer is always the best choice, but it does mean that a price that seems too good to be true almost certainly is. Factor in communication, time zone differences, cultural working practices, and the ability to have a proper conversation when something goes wrong.
A Final Thought
The best app projects start with honest conversations — about budget, about purpose, about what success actually looks like. The questions above aren’t just due diligence. They’re the foundation of a working relationship that has a chance of producing something genuinely good.
Ask them. All of them. And if a developer seems uncomfortable being asked, that’s your answer.
