Most businesses learn the right questions to ask a software development agency only after an engagement has gone wrong — when the budget has doubled, the work does not fit, and the relationship has soured. The questions are not technical, and you do not need to be technical to ask them. They are about how the agency works, how it protects you, and whether your interests are aligned. Asked before you sign, they reveal far more than the polished pitch does.
The ten questions
How will you make sure you understand our problem before building? An agency that wants to start building immediately is a warning. The good ones invest in understanding the problem first, because that is where projects succeed or fail.
What will the specification cover, and who writes it? The specification is your main protection. You want one that is precise about what “done” means, and you want a say in it rather than signing whatever is put in front of you, as explained in what a software specification should actually include.
Free · 4 minutes
Is your engineering team shipping safely, or quietly accumulating risk?
Fourteen questions on how work gets from idea to production — cadence, testing, rollback, and the key-person risk in your delivery. Banded finding on screen, full sheet by email.
How do you handle changes to scope? The answer should be a clear process where changes are named, costed and decided — not absorbed silently, which is how budgets quietly double.
How will I see progress? You want visibility into what is being done and finished, in terms you can follow. An agency reluctant to make its work visible is telling you something.
What happens to the code and the knowledge if we part ways? The answer reveals whether you will own and be able to move what you paid for, or whether you are being quietly locked in.
How do you handle data, security and the things that are not visible features? The unglamorous requirements are where corners get cut. A good agency raises them unprompted; a worrying one only mentions features.
Who, specifically, will work on this? Agencies sometimes win work with senior people and deliver it with junior ones. You want to know who is actually building your software.
How will we know the work is good? The answer tells you whether quality is something they can evidence, or something you are expected to take on trust.
What does support and handover look like when the build is finished? The end of the build is one of the most under-managed moments, and you want to know what happens after they walk away before they do.
Can you put us in touch with clients for whom things did not go perfectly? Anyone can supply happy references. How an agency handled a project that hit trouble tells you far more.
What the answers really tell you
Across all ten, you are listening for one thing: whether the agency thinks about protecting your outcome, or only about delivering a project. The good ones answer these comfortably, because they already work this way. The ones to avoid get defensive, vague, or treat the questions as obstacles. That reaction is itself the most useful answer you will get. These questions also map directly onto the causes behind IT projects going over budget — ask them well and you remove most of those causes before they start.
If you are about to sign, I can give you an independent view of the agency and the engagement before you commit — the protection described in build and oversee. We will make sure you are asking the right questions and reading the answers correctly.
Start a ConversationBuild and rescue work
Hands-on delivery of this kind is handled by Sixteen Pillars Studio.
Free interactive tool
Website compliance checklist
What your site has to do, based on what it actually does
Answer as much or as little as you like — the list builds as you go. Nothing is stored against your name and no email is required.
Everything that applies
Ordered by what to do first: legal requirements you can close quickly, then larger pieces of work, then what is expected rather than required. Not exhaustive, and not a legal audit.
Dated PDF, yours to keep or circulate.
Most technology problems are not technology problems. They are control problems.
The systems exist. The investment has been made. The question is whether leadership can understand, direct, evidence, and sustain what those systems produce. Find out where control exists — and where it only appears to.