IndustriesWorkPlaybookHow it worksAboutBook a systems auditBring us your idea

Questions to ask before paying anyone to fix your app

Straight answer

Before paying anyone, ask what they will assess before quoting, what you will own at the end, how they handle your data and keys, what happens if they leave, and what they would keep versus rebuild. Honest, specific answers are the signal you want. Vagueness, defensiveness or a rush to start are the signals to walk away.

Information current as at 5 July 2026

You do not need to be technical to vet someone well. You need a short list of pointed questions and the patience to listen to how they answer. The content of the answer matters, but so does the manner: a good partner welcomes these questions, because they are the questions a careful client should ask.

Plain English
Scope
The agreed boundary of what the work will and will not cover.
Fixed price
An agreed total for a defined piece of work, as opposed to open-ended time billing.
Escrow
Holding payment with a neutral third party until agreed work is delivered.
Ownership
Holding the code, data and accounts so the system is legally and practically yours.

Questions about how they start

Ask what they will do before they quote a fixed price. A good answer involves assessing your actual app: reading the code, checking the data, finding the risks. Ask how they arrived at their estimate, and whether it could change. Anyone willing to name a firm price for finishing your app without looking at it is either guessing or planning to revise it upward later. You want a partner who treats the assessment as a real step, priced modestly or even free, and who can then explain the fuller quote in terms of what they actually found. How they begin tells you how they will continue.

Questions about ownership and lock-in

Ask, plainly, what you will own at the end. Will the code sit in your accounts? Will the data be under your control? If you and this partner parted ways in six months, could someone else pick it up? The answers reveal whether they build to hand over or build to keep you dependent. A confident, ownership-first partner answers these easily and even volunteers reassurance. Hesitation, or an implication that you would not want to leave, is the sound of lock-in. This is the question people most often forget to ask before paying, and the one they most often regret skipping. If you take only one question from this list into your next conversation, make it this one, and do not accept a vague answer, because vagueness about ownership almost never resolves in your favour later.

No pressure
Show us what you built.

If you have made something and it needs to become real, send it over. We will tell you honestly what it needs to be live, safe and yours, whether that is a quick fix you can do or a proper build. No obligation.

Questions about your data and security

Ask how they will handle your secret keys and your customers' data during the work, and what they will do about anything they find exposed. A serious partner has a clear answer: they use proper, revocable access, they never need your raw passwords pasted into a chat, and they treat an exposed key as urgent. If security seems to be an afterthought in their answer, or they wave it away, that is telling, because casual handling of data is exactly the problem you are hiring them to fix. How they talk about your data before they are paid predicts how they will treat it after.

Questions about what could go wrong

Ask the uncomfortable ones. What happens if the work runs over? What if a fix does not hold? What if you are unhappy partway through? How do payments work, and would they use staged payments or escrow so you are not paying everything up front for an unproven result? A trustworthy partner has thought about these and answers without defensiveness, because they have been asked before by good clients. Evasiveness or irritation here is worth more than any glowing promise, because it shows you how they behave when things are not going smoothly, which is exactly when you will need them to behave well. It is also worth asking who will actually do the work, and whether the person you are talking to is the person who will be typing, because a warm sales conversation followed by unfamiliar hands on your system is a common and avoidable disappointment.

Common questions

Questions, answered

Is it rude to ask a partner all these questions?
Not at all, and a good one welcomes them. These are the questions a careful client should ask, and how someone responds tells you as much as their answers. A partner who bristles at reasonable due diligence before payment is showing you how they will handle scrutiny later, which is useful to know early.
What is the single most important question?
What will I own at the end. It exposes lock-in, sets up a clean handover, and protects you if the relationship ends. Everything else can be recovered from; a system you do not truly own quietly holds you hostage. Ask it plainly and listen for an easy, confident answer.
How do I judge answers if I am not technical?
Judge clarity, not jargon. A strong partner explains technical decisions in plain terms you can follow and does not hide behind complexity. If an answer leaves you more confused than before, that is a signal in itself. The ability to make you understand is a reliable proxy for competence and good faith.
Should I get more than one quote?
Usually yes. Comparing two or three responses to the same brief reveals a lot: who assessed properly, who rushed to rebuild, who explained their thinking. The cheapest is rarely the right measure. What you are really comparing is reasoning and respect for your work, which the questions above are designed to surface.
No pressure
Show us what you built.

If you have made something and it needs to become real, send it over. We will tell you honestly what it needs to be live, safe and yours, whether that is a quick fix you can do or a proper build. No obligation.

Start here

Two doors. Same senior team.

Whether you can name exactly what you want built, or you just know something is leaking, the next step is the same conversation.