Your app needs professional help. Maybe it is crashing, maybe it is slow, maybe the AI tool that built it cannot fix it anymore. You have decided to hire someone. Good.
But hiring the wrong person can make things worse — more expensive, more broken, more dependent on someone else's schedule. Before you sign anything, ask these five questions. The answers will tell you whether you are talking to the right team.
1. Will You Look at My Code Before Telling Me What to Do?
This is the single most important question. Anyone who proposes a solution without reading your codebase first is guessing. And guesses in software are expensive.
A good team will ask for access to your repository, spend a day or two reviewing it, and then come back with specific findings: here is what is breaking, here is why, here is what it will take to fix. Not "we recommend a full rewrite" without evidence.
Red flags:
- They quote a price before seeing the code
- They recommend rewriting everything (the most profitable option for them, rarely the best option for you)
- They want to start work immediately without a discovery phase
What you want to hear: "Let us triage your codebase first. We will deliver findings in 48 hours and then you decide."
2. What Happens to My Code and Data When We Are Done?
Ownership matters more than anything else in this conversation. Some agencies and freelancers build on their own infrastructure, their own accounts, their own repositories. When the relationship ends, you discover that your app lives on their server and you cannot move it without their help.
The answer you need: "Everything is in your accounts. Your GitHub, your hosting, your domain, your database. We work in your infrastructure, and if we part ways tomorrow, you keep everything."
If they hesitate on this question, walk away. Full ownership from day one is non-negotiable.
3. How Do You Handle Surprises?
Every software project has them. You think the problem is the login page, but the real issue is the database schema underneath it. Fixing one thing reveals that two other things were held together with tape. This is normal — but how the team handles it determines whether your budget doubles or stays controlled.
What you want to hear:
- They work in short sprints (one to two weeks) with a demo at the end of each
- Scope changes go through a clear conversation, not a silent invoice increase
- They surface surprises early (within days, not at the end of the project)
- They distinguish between "must fix now" and "can address later"
Red flags:
- "We will figure it out as we go" (no structure, no predictability)
- Billing by the hour with no sprint structure (incentivises slow work)
- No communication between kickoff and final delivery
4. Can You Show Me Something Similar You Have Fixed?
Building new software and rescuing broken software are different skills. A team that is great at greenfield development might have no experience with legacy codebases, AI-generated spaghetti, or the kind of tangled architecture that needs untangling rather than rebuilding.
Ask for a case study or reference where they took something broken and made it work — not where they built something shiny from scratch. The constraints of rescue work are different: you cannot break things for existing users, you have to understand someone else's decisions (or an AI's decisions), and you have to stabilise before you improve.
If they only have "we built X from zero" stories, they might be great builders but inexperienced rescuers. That is a meaningful gap for your situation.
5. What Does After Look Like?
The fix is not the finish line. Software needs ongoing attention: security patches, dependency updates, performance monitoring, bug fixes as users find edge cases. Before you hire someone for the rescue, understand what happens next.
Questions to ask:
- Do you offer ongoing maintenance after the initial fix?
- What does that cost monthly?
- What response time can I expect for critical bugs?
- Will the same people who fixed it be available for questions later?
What you want to hear: a clear maintenance offering with defined scope and response times. What you do not want: "Call us when something breaks" (reactive, not proactive) or silence on the topic entirely (they will disappear after delivery).
The Meta-Question: Do They Tell You the Truth?
Behind all five questions is one underlying test: does this team tell you what you need to hear, or what you want to hear?
A trustworthy team will say:
- "This part of your app is fine — do not pay us to rewrite it"
- "This problem is smaller than you think — here is a quick fix"
- "This is bigger than our initial estimate — here is why and here are your options"
- "You do not actually need an agency for this — a freelancer can handle it"
A team that agrees with everything you say, never pushes back, and never tells you something is out of scope is optimising for their revenue, not your outcome.
Make the Decision
If a team passes all five questions — they diagnose before prescribing, you own everything, they handle surprises transparently, they have rescue experience, and they are honest about what happens after — you have found a good partner. Price becomes a simpler decision when trust is established.
If they fail on even one, especially questions two or five, keep looking. The wrong hire does not just waste money — it wastes time you could have spent with the right team.
We Pass These Questions
We wrote them because they reflect how we actually work. If you want to put us to the test, tell us about your app and we will deliver a free triage report within 48 hours. You decide what happens next.
