Most of the risk in a software project is not technical. It is that you end up depending on a company you cannot leave, or holding something nobody else can pick up.
These are the questions that surface that early. Ask them of us, and ask them of everyone else you speak to. The pattern in the answers tells you more than any portfolio.
Ownership
When we have paid, who owns the source code?
The answer you want is that you do, stated in the contract, without qualification. Be careful with "you have a licence to use it" and with "it runs on our platform". Those can be fine, and they can also mean you are renting something you thought you had bought. Follow up with: what happens to our system if we stop paying you?
Whose accounts does it run on?
Hosting, domain, database, payment provider, email sending, AI providers -- all in your company name, with you as the owner and the supplier added as a user you can remove.
The one that catches people is the app stores. If the developer account belongs to the agency, the agency owns your listing, your reviews and your download history. Moving an app between developer accounts is possible and it is slow and unpleasant. Insist on your own accounts from the start; this is standard practice for mobile work and any supplier who resists is telling you something.
Where will our data be stored, who on your side can see it, and what happens to that access when we finish?
What happens if you disappear
If your company stopped trading next month, what would we do on the Monday?
A good answer is concrete: the code is in a repository your company owns, the deployment steps are written down, the passwords and keys are in your own accounts, and another developer could take it over. A bad answer is reassurance about how long they have been in business.
Can we have a complete copy of everything today?
Ask during the build, not at the end. If it takes a week to produce, it does not really exist yet. This single request is the best test on the list.
Who else at your company knows this system?
Agencies have single points of failure too. One developer who holds the whole thing in their head is the same risk whether they work for you or for them.
Define the word handover
Everyone promises handover. It means different things. Ask for the list:
- The source code, including its full history
- Written instructions for running it, deploying it, and fixing the two or three things that commonly break
- The accounts, and how to get into each one
- The database structure and a tested way to restore a backup
- A recorded walkthrough by someone who built it
- A named period afterwards where you can ask questions
Could a developer who has never met you pick this up? Ask what they would expect to happen if you hired your own developer in a year. A firm that has thought about it answers immediately. A firm that has not will change the subject.
After launch
What breaks first, and who finds out? You want monitoring and alerts that tell somebody, rather than a customer telling you.
What does support cost, and what does it cover? Separate the two things clearly: fixing something that was meant to work, and building something new. Ask what happens on a Saturday night, and prefer an honest "we are a small team, email us and we will get to it" over a guaranteed response time nobody can keep.
When a third party changes something, who pays? Payment providers change their interfaces, phone operating systems update, an API gets retired. It happens to every system. There is no single fair answer, but agreeing it in advance beats arguing about it later.
What is your maintenance recommendation, and what happens if we do nothing for a year?
The project itself
Who will actually write the code? The people in this meeting, or a team you have not met. In-house or subcontracted. Where. There is nothing wrong with any of those answers; there is something wrong with not being told.
What have you built that is like this? And if what they show you is a demonstration build rather than paid client work, they should say so without being asked. Our own work page labels which builds are concepts rather than paid client work, for exactly that reason. A portfolio you cannot verify is not evidence.
What will you need from us, and how many hours? Any supplier who says "almost nothing" either has not built this kind of thing before or is planning to guess at the parts only you know.
What would make you tell us not to do this? The best question on the list. Someone who cannot name a single reason to turn your project down has not thought about your project.
Signals worth slowing down for
A fixed price arriving before anyone has scoped the work, with no assumptions listed. Reluctance to put ownership in writing. Every question answered with "no problem". A demonstration you are not allowed to drive yourself -- ask to type your own input and watch what happens. Case study numbers with no explanation of how they were measured. And urgency about a deadline that belongs to their sales month rather than to your business.
Get the answers into the document
Before any work starts you should have one document containing: what is being built, what is explicitly not being built, who owns the code and the accounts, what handover includes, what support costs and covers, and payments tied to things being delivered rather than to dates. Our version of that sits in how we work.
If a supplier will not write these down, that is the answer to the question you were really asking.
The question to ask yourself
Who inside your business is going to own this? Not sponsor it -- own it. Answer questions, make decisions, chase colleagues, be the person the supplier rings.
Projects without that person stall a long way in, and no amount of diligence about the supplier will save you from it. That part is not in their gift.
Filed under
- buying software
- ownership
- handover
- contracts