What should I ask a software agency before hiring them?

The highest-signal question is: who exactly will write the code, and can I see something working every week? Follow it with questions about scope in writing, ownership of code and accounts, what happens to changes mid-project, what is explicitly excluded from the quote, and what happens after launch.

How do I compare quotes from different agencies?

You cannot compare them until each one names the same things: the screen list, which platforms, whether the backend is included or assumed, every third-party integration by name, and who owns the code and accounts at the end. Two quotes against a one-paragraph brief are not comparable at any price.

What are the warning signs when hiring a software studio?

A quote arriving with no written scope; an inability to name who will actually write the code; no working software until the end of the project; accounts or app store listings held in the vendor's name; and vagueness about what happens when you want a change mid-build.

Should I hire a freelancer, a studio, or an agency?

It depends on failure tolerance more than size. A freelancer is cheapest and highest-variance with a single point of failure. A small senior studio suits most product work. A large agency is worth its overhead when the problem is organisational scale — many stakeholders, compliance regimes, or integration with enterprise systems.

Is a cheaper quote usually more expensive?

Often, yes. A low quote frequently prices a smaller imagined scope, or staffs juniors under a delivery manager. The rework is invisible until it is not. Compare what each quote actually includes before comparing the numbers.

What to ask a software studio before you hire them

You are usually choosing a vendor with less information than they have, under time pressure, in a field where everyone’s website says the same things. These twelve questions do most of the work — along with what a good answer actually sounds like.

Short answer

Two questions carry most of the signal: who exactly will write the code, and can I see something working every week? Follow them with what the quote excludes, how mid-project changes get priced, who owns the code and accounts at the end, and what happens after launch.

Every studio's website promises quality, partnership and transparency. None of that is checkable. These questions are, and the answers separate vendors faster than any portfolio does.

They are ordered by how much signal they carry.

1. Who exactly will write the code?

The single highest-signal question, which is why it goes first. You want a name and a level, not a description of a process.

Good answer: "I will — you are talking to the engineer." Or: "Two named senior engineers; here is what each will own."
Bad answer: anything describing a "delivery team" without naming anyone. If the person selling cannot name who builds, the answer is usually whoever is unallocated when the contract signs.

2. Can I see something working every week?

Not a status call. A URL you can open yourself.

Weekly working software is the mechanism that catches a wrong direction in week two instead of at handover. Any engagement where the first real thing you see is at the end has quietly transferred all the risk to you.

3. What is explicitly excluded from this quote?

A good vendor answers this immediately and specifically, because they have thought about it. Watch for the usual omissions: developer accounts, hosting, third-party fees, store submission, content, and post-launch maintenance.

Hesitation here means either the scope was never defined or the exclusions are a commercial strategy.

4. What happens when I want a change mid-project?

You will want changes; that is normal and not a failure. What matters is whether there is a named process.

Good answer: changes get priced openly, and traded against existing scope or added explicitly.
Bad answers, both directions: "we'll just absorb it" (which means it comes out of quality somewhere you cannot see), and a flat refusal to consider changes at all (which means you will get exactly what you specified before you knew anything).

5. Who owns the code, the repository and the accounts at the end?

Everyone says you own the code. Ask the longer version: repository with history, deployment accounts, app store accounts, domain, third-party services — in whose name? The full checklist is here, and the answer should be "yours, and we set them up that way from week one."

6. What does the fixed price actually fix?

If the quote is fixed, against what written scope? If hourly, what is the not-to-exceed ceiling and where is the checkpoint at which you can stop? Either model can be fair; neither is fair without structure.

7. What happens after launch, and what does it cost?

Software is not finished at launch; it is merely started. Ask what a bug in month two costs, whether there is a retainer, what happens when iOS ships a version that breaks something. A vendor with no answer has not thought past the invoice.

8. What would you talk me out of?

An unusually revealing question. A vendor who has never talked a client out of anything is a vendor who sells whatever is asked for. The good answer names something specific — a feature that is not worth it, a platform not worth supporting yet, sometimes the whole project.

9. Tell me about a project that went badly

Everyone has one. The answer tells you how they handle trouble — which you will eventually need to know. Look for specifics and for ownership. "The client kept changing their mind" is a worrying answer, because managing that is part of the job.

10. Can I talk to a client whose project is finished?

Note the emphasis. Anyone can arrange a reference in week two of a project, when everyone is optimistic. Ask for someone six months past launch, and ask them one question: what happened when you needed something changed after the invoice was paid?

11. What is your stack, and why that one for my project?

The stack matters less than the reasoning. A vendor who recommends the same technology for every problem is telling you about their staffing, not your product. A good answer connects a choice to your specific constraints — and is willing to say "for your case, the other option is better."

12. How will we know if this is going badly?

The best final question, because it asks what a leading indicator of failure looks like. A vendor with a real answer has thought about failure modes. One who cannot imagine the project going badly has not built enough software.

On the cheapest quote

It is often the most expensive project. Not because the vendor is dishonest, but because a low number usually prices a smaller imagined scope, or staffs juniors under a delivery manager, and the rework is invisible until it is not. Before comparing prices, get every quote to name the same screens, the same integrations, and the same ownership terms. Two quotes against a one-paragraph brief are not comparable at any number — a point worth reading alongside what apps actually cost.

The short version: ask who writes the code and whether you see working software weekly — those two carry most of the signal. Then pin down exclusions, the change process, ownership of accounts, and what happens after launch. Any vendor who answers all twelve without hedging is a vendor who has done this before.

Try them on us.

Book a free 30-minute discovery call and ask every question on this list. You'll get straight answers, and a fixed quote within 48 hours if the project is worth building — or an honest "not yet" if it isn't.

Book a free discovery call