ATPL Engineering5 min read
Questions to answer before you commission custom software
Ten questions ATPL asks in the first conversation about custom software, drawn from doing this since 2010, and what to bring so the call ends in a scope rather than a brochure.
- Software
The first conversation
We have been having first conversations about custom software since 2010. The ones that lead to a system the business still runs years later share a pattern: the owner has already answered a few questions before anyone talks about a framework, a price or a deadline. The ones that go wrong usually skipped one of them. Here are the questions, in the order we ask them.
1. Which one job will the first release replace completely?
Not "manage the business". One job. The bill at the counter. The dispatch note. The weekly stock count. Ethos began in 2013 as a billing screen for four cafés; inventory, central reporting and order intake came afterwards, each one a release. A first version that replaces one painful job completely gets used from the first week. A first version that half-replaces six jobs gets worked around, and the spreadsheets come back.
2. Who does the work today, and what do they do when it goes wrong?
The happy path is easy to describe and is almost never where the real work is. What happens when the customer changes the order after dispatch, when the supplier invoice does not match the purchase order, when the till is offline? We sit with the people doing the job and write down every branch, including the ones everyone says never happen. Software that does not know about them is software the team stops trusting.
3. What is the number you will look at to know it worked?
Hours saved a week. Days of stock on hand. Time from order to dispatch. Errors per hundred invoices. If the number cannot be named, the project has no finish line and will drift. If it can, it also tells us what to build first: the screen that moves that number.
4. What exists already, and what must be kept?
Nearly every business we meet runs on a mix: an off-the-shelf tool that does seventy per cent of the job, spreadsheets for the rest, and a couple of WhatsApp groups holding it together. The accounting package usually stays, and the new system exports to it. The question to answer is which parts are the problem and which parts are merely old.
5. What has to connect to it?
Payments, GST invoicing, SMS and email, the accounting export, the courier, the aggregator, the bank file. Integrations are where estimates go wrong, because each one is a conversation with someone else's system and someone else's timetable. Listing them in the first meeting is the difference between a plan and a hope.
6. Who will own the code and the data?
You should. Source in your own repository from the first week, the database in an account you control, and documentation that would let another team take over. If a vendor's answer to this is vague, the price you are being quoted is not the whole price.
7. Who will run it after launch?
Software that is used every day needs someone watching it, fixing it and extending it as the business changes. It has to be someone, and it has to be decided before launch, not after the first outage. We have looked after Ethos this way since 2013. Ask what the monthly cost of keeping the system healthy will be, separately from the cost of building it.
8. What should be true at week six?
Our answer is that there should be working screens on a staging site that your own operators have clicked through, built from real data, with the first job close to replaceable. Decisions are better made on the real thing than on a document.
9. What happens when the developer leaves?
They will, eventually, whether they are a freelancer, an employee or a company. The things that survive a departure are boring: readable code, a documented data model, an admin guide, access held in the business's name. The things that do not survive are the clever parts only one person understood.
10. Should this be custom at all?
The honest limit. If an off-the-shelf product does ninety-five per cent of what you need and the other five can be lived with, buy it, and we will tell you so. Custom software earns its cost when the process is genuinely yours: when the way you quote, price, pick or bill is the reason customers choose you, and no package will bend to it. It also earns its cost when the off-the-shelf tool's missing thirty per cent is being done by hand, every day, by someone senior, because that is the most expensive software in the building.
What to bring to the first call
A one-page description of the one job, the names of the people who do it, the number you will watch, a list of the systems it must talk to, and an honest account of what you have tried. With that in hand, a first conversation produces a scope and a first-release plan rather than a brochure.
That conversation is how our custom software engineering work begins. The page sets out what we deliver and what staying with a system after launch involves.
