For product businesses in Ireland and the UK
12 questions to ask before you hire a web and systems partner
Twelve questions for the first call with an agency, a freelancer or a software company. Each one has the reason you ask it and what a good answer sounds like. Ask them in this order and write the answers down.
How to use this listAsk the same questions to every provider you talk to, in the same order. A good provider answers with names, dates and documents. A vague answer to one question is normal; vague answers to four of them are a decision.
The twelve questions
12 checksWhich of your clients had a problem like ours, and can we talk to them?
Why it matters: A reference from a similar project tells you more than a portfolio page.
A good answer: A client name, the problem they had, what changed, and an introduction.
Which of our current tools will you keep, and which do you want to replace?
Why it matters: Replacing everything costs more and breaks the habits of your team.
A good answer: They start from what you use and name the one tool they would replace, with the reason.
What is the first thing you will deliver, when, and what will it cost?
Why it matters: A provider who can fix the first stage can scope the rest.
A good answer: A first stage with a date, a price and a description you could show to your team.
Who exactly will work on our project, and who is our contact?
Why it matters: The people in the pitch and the people in the project are sometimes different.
A good answer: Names and roles, and one person you can call.
How do you handle a request that goes beyond the agreed scope?
Why it matters: Unplanned requests are where budgets and relationships break.
A good answer: A written change process: what it costs, how long it takes, who approves it.
Who owns the code, the accounts and the data when we stop working together?
Why it matters: You should be able to leave with everything that was built for you.
A good answer: You own it all, and the system is documented so another provider can take it over.
What happens if a key person on your side leaves?
Why it matters: A system known by one person is a risk for both sides.
A good answer: Documentation, a second person who knows the system, and the code in a repository you can access.
How will our team learn the new system, and what do you leave behind?
Why it matters: A system the team avoids changes nothing.
A good answer: Training sessions with the people who will use it, a manual, and screens built for their steps.
What do you need from us, and how much of our time?
Why it matters: A project that needs no time from you is not built around your team.
A good answer: A list: the people to interview, the access, the decisions, and the hours per week.
How do you test before launch, and with whose data?
Why it matters: A demo with sample data hides what real orders reveal.
A good answer: Tests on your real orders, with your warehouse and office staff, before the switch.
What do maintenance and support cost after launch, and what do they include?
Why it matters: The system will outlive the project, and so will the questions about it.
A good answer: A monthly price, response times, and a clear line between fixing and new work.
In which country and time zone are you, and how do we meet?
Why it matters: A remote partner is fine when the working hours overlap and the rules are written.
A good answer: The country, the hours you share, the meeting tool, the contract language and the invoicing entity.
How to use the answers
Put the answers of each provider side by side. The one with the clearest first stage, the clearest ownership rule and the most concrete reference is usually the one worth a second call. If you want to ask us the same twelve questions, book a call.
