10 Questions to Ask a Developer Before Hiring Them for Your App

You found a developer who seems legit. Portfolio looks good, the price feels reasonable, and they say they can start next week. So you wire the deposit, kick things off, and three months later you have half an app, zero documentation, and a developer who takes four days to answer a text.

I have seen this play out dozens of times. Founders come to me after burning through their first budget with someone who looked great on paper. Most of these disasters were avoidable. A few pointed questions during hiring would have revealed the red flags early.

Here are the ten questions I would ask any developer before signing anything.

Questions about process and communication

1. "What does your development process look like, week by week?"

A good developer will describe a clear rhythm: planning, building in short cycles, showing you working software at regular intervals. A bad one will say something vague like "I just start coding and we go from there."

You want someone who builds in sprints of one or two weeks, shows you progress you can actually click through, and adjusts based on your feedback. If they cannot describe their process in plain language, they probably do not have one.

2. "How often will I see working progress, not just updates?"

A Slack message saying "working on the backend" is not progress. A link where you can tap through actual screens is. Written updates are easy to fake. Working software is not.

When I built CherryStripes, a women's wellness app, I showed the founder working builds every week. We discovered in week two that two planned features, live chat and a shopping list, were unnecessary. We cut them, focused on what mattered, and launched in six weeks. That kind of course correction only happens when you can see and touch real progress early.

3. "What happens if I need changes mid-project?"

Every app changes during development. Every single one. If a developer quotes you a fixed price with zero room for adjustments, that is a red flag. Either they will resist every change request, or they will nickel-and-dime you with change orders.

Look for someone who expects changes and has a clear way to handle them. A flexible hourly arrangement, a process for re-scoping without drama, something concrete.

4. "Who else is working on this, and will I talk to them directly?"

Some developers outsource parts of the work. Fine, as long as you know about it upfront. What you do not want is to hire one person and discover later that your app is being built by a rotating cast of anonymous subcontractors.

Ask who is writing the code. Ask if you will have direct access to them. If the answer involves layers of project managers between you and the person actually building your product, think twice.

Questions about technical decisions

5. "What tech stack are you recommending, and why this one specifically?"

You do not need to understand every framework. But you do need to hear a reason beyond "it's what I know." A thoughtful developer will explain why a particular stack fits your project, your budget, and your future needs.

When a founder comes to me with an MVP idea, I often recommend Next.js and a managed database. Not because they are trendy, but because they keep hosting costs low, let a small team move fast, and make it easy to hand the codebase to another developer later. The "why" matters more than the "what."

6. "What will you build first, and what will you skip for now?"

A good developer will push back on your feature list. They will tell you what to launch with and what to save for version two.

I built the Prettan ERP for a Mexican manufacturer. They originally wanted a full reporting module, invoicing, inventory, the works. I told them to launch with invoicing first. It was the one thing causing daily pain. Reports could wait. We shipped in six weeks instead of four months.

7. "How do you handle security and authentication?"

A lot of founders get burned here, especially now with AI-generated code everywhere. If a developer cannot clearly explain how they handle user login, data protection, and basic security, your app is going to be vulnerable.

I built Data Hogo specifically because I kept seeing apps, many built with AI tools, that had serious security holes their founders did not even know about. Ask your developer what authentication system they use, how they store sensitive data, and whether they run any kind of security review before launch.

Questions about what happens after launch

8. "Will I own the code, and can another developer pick it up?"

Sounds obvious. But I have talked to founders who discovered after the fact that their developer owned the repository, or that the code was so messy no other developer could work with it without starting over.

Get code ownership in writing. Ask them to show you an example of their code or documentation from a past project. Clean, commented code is not a luxury. It is insurance.

9. "What does post-launch support look like?"

Your app will have bugs after launch. Users will request features you did not anticipate. The question is whether your developer will still be around when that happens.

Ask if they offer a support period after launch. Ask what it costs. Ask what their response time is for critical bugs versus nice-to-have improvements. A developer who disappears after delivery is one of the most expensive mistakes you can make, and most founders do not think about it until it is too late.

10. "Can I talk to a past client?"

The most revealing question on the list, and the one most founders skip. A developer who has done good work will happily connect you with a previous client. One who hesitates or makes excuses is telling you something important.

When you talk to that client, ask two things: Did the project finish on time and on budget? And would you hire them again? The second answer tells you everything.

The real red flags are in what they do not say

The biggest red flags are not in the answers. They are in the silences. A developer who cannot explain their process, gets defensive about change requests, or avoids talking about past clients is showing you exactly what working with them will be like.

Hiring a developer is not about finding the cheapest option or the flashiest portfolio. Find someone who communicates clearly, builds in a way you can verify, and treats your project like it matters.

Not sure which path is right for your project? Describe your idea and I'll give you my honest take -- no sales pitch. Get in touch