Checklists for buying software you'll still own in three years.

1. 01

   It runs more than once a week.

   Something that happens twice a year is cheaper to keep doing by hand, and you will have forgotten how the automation works by the time it next fires.

2. 02

   The steps are the same every time.

   If a person makes a judgement call at step three that changes steps four through nine, you are not automating a process — you are automating a decision. That is a different and more expensive build, and it needs a person reviewing its output for a while.

3. 03

   The inputs arrive in a form a machine can read.

   An emailed CSV is one project. A photograph of a printed invoice is a different one, with a failure rate you will have to design around rather than eliminate.

4. 04

   Somebody can describe it end to end in one sitting.

   If nobody in the building can, that is not a blocker — but the first deliverable is the map, not the automation, and it should be priced as its own piece of work.

5. 05

   You can live with it being wrong occasionally.

   Everything automated is wrong sometimes. If a wrong result moves money, medication or a legal filing, you need a human checkpoint in the flow. Budget for the checkpoint, not just the automation.

6. 06

   The process is not about to change.

   Automating something that is mid-renegotiation with a supplier, or that a new regulation lands on in six months, means paying to build it twice.

Fewer than four? Leave it manual for now and put the money somewhere else. That is a real answer, it costs nothing to reach, and any studio unwilling to give it to you is selling you a build rather than a fix.

1. 01

   Who writes the code?

   "Our team" is not an answer. Ask how many people, how senior, and whether the person who scoped the work is one of the people building it. Scoping and building being different people is how a fixed price quietly becomes an estimate.

2. 02

   What do I own on the last day?

   "You own your data" is the answer given when the answer is not everything. You want the repository, the infrastructure config, the deploy pipeline, the accounts, and the practical ability to hire someone else to change it.

3. 03

   Whose name is on the hosting and the domain?

   If the production account is in their name, you are renting your own software, and the handover conversation will happen at the worst possible moment.

4. 04

   What is explicitly not in scope?

   A studio that cannot name three exclusions has not scoped the work. This is the single question that most reliably separates a quote from a guess.

5. 05

   What happens if we stop after the first phase?

   You are asking whether phase one is a usable thing or a down payment on phase two. Both are legitimate. Being told which is not optional.

6. 06

   Show me something you built that broke.

   Everyone has one. The answer tells you how they behave when it is going badly, which is the only part of the relationship you cannot evaluate in advance any other way.

7. 07

   What does month two cost?

   Hosting, third-party APIs, model usage, monitoring, and their time if you want any. Get the running cost separated from the build cost in writing.

8. 08

   What would make you tell us not to build this?

   If nothing would, they are not advising you. Ask it early — the answer is also a preview of whether they will tell you when something is going wrong.

9. 09

   How do I get a change made in six months?

   Ask for the mechanism and the price, not the sentiment. "Just give us a shout" is a support contract with no terms.

10. 10

    Can I talk to someone you no longer work with?

    A current client is being asked a favour. A finished one has nothing at stake, which is what makes the reference worth having.

You are not buying a deliverable, you are buying how someone behaves under pressure. Score the answers on specificity, not on warmth.

1. 01

   The repository, with its history intact.

   Full commit history in an organisation you control, not a zip of the final state. The history is how the next engineer works out why something is the way it is.

2. 02

   Infrastructure as configuration, not as prose.

   The servers, databases and queues defined in files you can re-run. A document describing how it was set up by hand is an archaeology assignment.

3. 03

   Every environment variable, and where the secrets actually live.

   Including the ones nobody thinks about until a key rotates: mail, storage, payment webhooks, model API keys.

4. 04

   One documented way to deploy.

   You should be able to read a page and ship a change. If deployment lives in one person's terminal history, it is not handed over.

5. 05

   Accounts in your name, with your billing.

   Hosting, DNS, error tracking, every third-party service. Transferred, not shared.

6. 06

   A runbook for the three things most likely to break.

   Not exhaustive documentation nobody reads — the specific failures this system will actually have, and what to do at 2am.

7. 07

   The data: schema, and a backup you have restored.

   A backup nobody has ever restored is a belief, not a backup. Restore one together before the last invoice.

8. 08

   A record of the decisions.

   Why this database, why this queue, what was ruled out. It is the difference between inheriting a system and inheriting a puzzle.

If the handover is a zip file and a goodbye call, what you bought was a prototype — which is fine, as long as that is what you meant to buy.

1. 01

   Describe a Tuesday, not a feature.

   What happens, in order, from the moment the work arrives to the moment it is finished. Features written as features hide the steps that make them expensive.

2. 02

   Name the systems by name.

   Not "our accounting software" — Xero, and which plan. Half of what makes integration work cheap or ruinous is which specific product, and whether it has an API worth the name.

3. 03

   Say how many.

   Forty orders a day and forty thousand are different buildings. Volume is the single fact that most changes the shape of the answer, and it is the one most often left out.

4. 04

   Say who touches it.

   How many people, how technical, on what devices, and whether any of them are on a phone in a van with no signal. That last one is an architecture decision, not a preference.

5. 05

   Say what happens when it goes wrong today.

   Who notices, how, and what they do. The existing failure path is usually the requirement nobody writes down.

6. 06

   Say what you have already tried.

   The spreadsheet, the Zapier chain, the contractor it did not work out with. It saves everyone proposing the thing you already know does not work.

7. 07

   Name the real constraint.

   A date, a budget ceiling, a regulator, or one specific person who has to be persuaded. Every project has one. Naming it early is how you get a plan shaped around it instead of a plan that ignores it.

8. 08

   Say what success is, in a sentence someone could check.

   "Nobody rekeys an order into a second system" is checkable. "Improved efficiency" is not, and cannot be built toward or signed off.

You do not need to know the solution, and you should be suspicious of anyone who expects you to. Every item above is something only you know, and none of them require a technical answer.