How to Choose an App Developer in Kent: 7 Questions to Ask Before You Sign
Most app projects fail at the choosing stage, not the building stage. These are the questions that expose a weak developer in the first meeting, and the answers a good one gives without flinching.
Why this decision matters more than the price
Most failed app projects don't fail because the code was bad. They fail because the wrong developer was chosen for the wrong reasons: the cheapest quote, the flashiest pitch, or an agency that says yes to everything.
If you're a Kent business comparing developers right now, the good news is that weak developers are easy to expose. You just have to ask the right questions and know what a good answer sounds like. Here are the seven we'd ask if we were in your position, including the ones that would catch us out if we couldn't answer them.
1. "Can I download something you've built?"
Not screenshots. Not a portfolio page. A live app, on the App Store, that you can put on your phone in the next two minutes.
This single question filters out a surprising number of agencies. Anyone can show polished mockups, and plenty of agencies subcontract the actual building overseas and have never shipped anything themselves. A developer who has real apps in the App Store has been through Apple's review process, handled rejections, and supported real users. That experience shows up in your project.
A good answer: here's the App Store link, download it now. A bad answer: anything involving the words "under NDA" for every single project they've ever done.
2. "Is this a native app or a wrapped website?"
Many agencies quote for an "app" and deliver a website wrapped in an app shell, or a no-code build on a platform you've never heard of. It looks like an app in the demo. It doesn't feel like one in your customer's hand, and it often struggles with performance, offline use and App Store review.
Native means built specifically for the iPhone, in Apple's own tools and language. It's faster, smoother, and it behaves the way your customers expect apps to behave.
A good answer: a straight yes or no, plus what tools they build in (for iOS, that's Swift and Xcode). A bad answer: vague talk of "hybrid solutions" without explaining the trade-offs, or dodging the question entirely.
3. "Who owns the code and the App Store listing?"
If the relationship ends, what do you walk away with? With some agencies and most white-label platforms, the answer is nothing: the code, the listing, the reviews and sometimes even your customer data stay with them.
You should own the code, the App Store account should be yours, and the developer should be a collaborator on your account rather than the other way round.
A good answer: you own everything, in writing, in the contract. A bad answer: licensing arrangements, "our proprietary platform", or hesitation.
4. "What happens after launch?"
An app is not finished at launch. Apple updates iOS every year, devices change, bugs surface in real use, and your business will want changes within months. A developer who prices only the build and vanishes afterwards leaves you with an asset that slowly rots.
Ask how updates, fixes and new features are handled, what it costs, and how quickly they respond.
A good answer: a clear ongoing arrangement with defined scope and pricing, so month six is as predictable as month one. A bad answer: "we can quote for changes as they come up", which in practice means every small fix is a new negotiation.
5. "Who is actually building my app?"
At larger agencies, the person who wins your business is rarely the person who writes your code. Your project may pass through an account manager, a project manager, and a development team you never meet, sometimes in another time zone. Every handoff loses detail, and you pay for every layer.
There's nothing wrong with teams. But you should know exactly who is doing the work and be able to speak to them directly.
A good answer: a named person or small team you'll work with throughout. A bad answer: organisational charts instead of names.
6. "What would make you say no to this project?"
This one sounds odd, but it's the fastest way to test honesty. A developer who says yes to everything is either desperate or planning to figure it out at your expense. Good developers turn work away: projects outside their expertise, budgets that can't deliver the scope, ideas that would be better served by a website or an off-the-shelf tool.
We've told businesses they don't need an app yet. It costs us a project and earns something worth more.
A good answer: specific examples of work they've declined and why. A bad answer: "we can build anything."
7. "Why should a Kent business hire locally at all?"
A fair challenge, because you could hire from anywhere. The honest case for local isn't sentimentality, it's practicality: same time zone, meetings in person when it matters, accountability you can knock on, and a developer whose reputation lives in the same community your business does. An agency five thousand miles away loses nothing if your project goes badly. A local one does.
That only holds if the local developer also clears questions one to six. Local and mediocre is worse than remote and excellent. Local and excellent is the best of both.
The pattern behind all seven questions
Every question above is really asking the same thing: does this developer make money when my app succeeds, or when the invoice is signed?
Ownership, ongoing support, direct access, honest scoping. These all point to a developer whose incentives run alongside yours. Flashy pitches, vague answers and yes to everything point the other way.
Ask all seven in your first conversation. A serious developer will enjoy answering them. That reaction alone tells you most of what you need to know.
We're happy to be tested on every one of these. If you're comparing developers for a project in Kent or beyond, put these questions to us and see how the answers land.