In this guide 6 sections
Shortlist three partners and test each on the same list. Ask for a named team, two recent references, written ownership of code and accounts, a support arrangement after launch and a contract you can leave. A partner that dodges any of these has answered for you.
Questions that expose how a partner really works
Start with the dull questions. Who will be on my project, and for how many hours a week? How do you track tasks? How often will I see working software? Good partners answer with specifics such as a Jira board, a Friday demo or a staging link you can open. Ask to see a sample sprint board with the client name removed, so you know the tracking is real and not drawn for the sales deck.
Then ask about failure. Tell me about a project that ran late and what you changed afterwards. Honest partners have a story ready, while evasive ones claim a spotless record across every engagement they have ever taken.
Write the answers down side by side. Memory flatters whoever spoke last.
- Who is on the team and their hours
- How tasks and progress are tracked
- How often you see working software
- A late project and what changed afterwards
Ask for references and then actually call them
Request two recent clients whose job resembled yours in size and in tools. A reference chosen by the partner will be positive, so make your questions harder than a thank-you note. Call on a weekday afternoon and keep the questions identical for every partner, so the answers can be compared later without guesswork.
Ask whether the first release arrived on the promised date. Ask how the final invoices compared with the quote. Ask who picked up the phone when the payment page broke, and whether the original developers were still around a year later.
A reference that stays vague, or takes a week to arrange, is a finding in itself.
Read these contract terms before you sign
Most disputes trace back to four clauses: scope, change handling, payment milestones and termination. Read each one aloud to a colleague who never attended the sales meetings and see whether they reach the same meaning.
Check who owns the intellectual property, and when. Some contracts keep the code with the vendor until the last invoice clears, or for ever. Pay attention to any clause letting the vendor reuse your code or data for other customers, because that rarely comes up in meetings. Look at notice periods, your right to take work in progress and any lock-in to the vendor’s own hosting.
If the contract is silent on a point, ask for a sentence to be added. Verbal promises evaporate when staff change.
- Scope and what counts as a change
- Milestones tied to working software, not dates alone
- Intellectual property transfer on payment
- Termination notice and handover duties
- Confidentiality and data processing terms
Code, accounts and what you must hold yourself
Hold the keys. The source repository, cloud hosting, domain name and app store developer account belong to you. So do the payment gateway merchant account and the email sending service, with the partner added only as a user.
This costs nothing at the start. Opening an account takes an afternoon. Recovering one from a vendor who has stopped answering email can take a quarter, and some platforms will never release it without the original owner’s consent. A partner that insists on registering everything under its own name is keeping a lever over you.
Ask for a short handover pack each quarter. It should hold an architecture note, deployment steps and a list of secrets with the names of people who can rotate them.
Support after launch and the red flags to walk away from
Launch is the start of the running cost, not the end of the work. Agree who fixes bugs, how fast they respond to a stopped system compared with a cosmetic glitch, and what the monthly retainer actually covers. Support terms hide in appendices, so read the service levels for response time, resolution time and the hours when someone is truly on duty.
Ask whether the people who built it will also support it. Walk away from fixed delivery dates promised without any discovery work, from pressure to sign by Friday and from a quote that lists no assumptions. Be wary of a partner who agrees to everything.
Before you call anyone, print this checklist and score each candidate straight after every conversation.
Partner scoring checklist
Fill-in sheet, one row per topic. Rows cover team and hours, tracking method, two references called, contract clauses, ownership of code and accounts, support response times and red flags noticed. Three columns hold your candidates. Each cell has a rating and a notes strip for follow-up questions.
Open a blank worksheet to printQuestions owners ask
How many partners should I shortlist?
Three is enough. Fewer leaves you without a comparison, and more produces calls you will not remember. Give each the same brief so the answers compare fairly.
Is a fixed price safer than hourly billing?
Only when scope is clear. A fixed price on vague scope breeds arguments over every change. Hourly work needs a cap, a weekly report and a review point.
Do I need a lawyer to review the contract?
For anything with real exposure, yes. At minimum, ask someone who missed the sales calls to read the ownership, liability and termination clauses. That fee is small next to a dispute over who owns the code.
What if I am not technical?
Ask each partner to explain the plan in plain words and to show a demo. If you still cannot follow, pay an independent adviser for a few hours of review. A neutral reader will also spot promises that sound good but commit the partner to nothing.