What to Prepare Before You Commission Custom Software

Most of the difference between a software project that goes well and one that drags on is decided before any code is written. If you are about to commission custom software, meaning a system built for your organisation rather than bought off a shelf, the preparation you do in the first week will shape the next six months.

I have been building and running systems from Belmopan since 2008, for businesses, NGOs, international organisations and government. I also manage Systems Development and Data Processing at the Statistical Institute of Belize. Across eighteen years the pattern is consistent. The projects that go well start with the same handful of things in place, and none of them require you to be technical.

This is the list I would ask you for at a first meeting, and why each item matters.

What should you prepare before you commission custom software?

Seven things. You can assemble most of them in a few evenings with what you already have in a filing cabinet or a spreadsheet.

1. A one-page statement of the problem

Not a specification. One page, in your own words, describing what is going wrong and what it costs you. "We lose two days a month reconciling bookings between three channels." "Parents call the office for results because there is nowhere to see them." "Our payroll is in a spreadsheet and only one person understands it."

A problem stated this way can be tested later. A wish list of features cannot, because nobody can tell you whether the features worked.

2. A named decision-maker

One person who can say yes, say no, and say "that is out of scope". They do not have to attend every meeting. They do have to exist, and everyone in your organisation needs to know who it is.

Decisions by committee are the single most reliable way to turn a three-month build into a nine-month one. Consultation is good. Consensus as a prerequisite for every screen is not.

3. The current process, written down

Even on paper. Even badly. Who does what, in what order, on which form, and what happens when something is wrong or late.

I have had clients apologise for handing me a hand-drawn flow chart. That chart is worth more to me than a polished requirements document, because it describes what actually happens rather than what is supposed to happen. The exceptions are where the real work is.

4. Sample data

Real records, or a copy of them with names changed. A few hundred rows of your actual bookings, students, loans, employees or inventory.

Sample data tells me the shape of your world. It shows me that some properties have two owners, that some students transfer mid-term, that some invoices are issued in two currencies. Those details decide how the system is structured, and they are much cheaper to discover in week one than in month four.

5. A list of who uses it, and where

Field, office, or phone. A garbage truck driver on a route, an agent on a site visit, an accounts clerk at a desk, a head teacher at home on a Sunday.

This changes the build more than people expect. When I built the GPS vehicle tracking that runs at rideya.bz and as the Belmopan City Council CleanCity garbage-route tracker, the primary user was someone looking at a map, not someone filling in a form. A system designed for a desk and used on a phone in the sun is a system nobody uses.

6. Your external obligations

Reports, regulators, auditors, funders. The Belize Tax Service. A ministry return. A board pack every quarter. A donor template with fixed column headings.

These are non-negotiable outputs, and they are often the cheapest part of a build if they are known from the start and the most expensive if they surface at the end. If you are in the public sector, I have written separately about what a workable digitisation strategy actually needs.

7. A realistic view of who maintains it later

Someone has to add the new user, change the tax rate, upload the new term dates, and notice when a backup fails. That person might be in your office, or it might be me under an operations arrangement.

What does not work is assuming it will be nobody. Software is not a building that stands once finished. It is closer to a vehicle that needs servicing.

What do you actually get at the end?

This is a fair question to ask anyone before you sign. Here is what I provide, and what I think you should expect from any builder.

• A written scope. What is being built, what is not, and what happens when that changes.
• A staged plan. Work delivered in pieces you can see and use, not one large reveal at the end.
• A staging site. A private copy of the system, online, that you review as it is built. You click through it. You tell me what is wrong.
• Source code and documentation. Handed over at the end. You own it. If you stop working with me, you can hand it to someone else.
• In-app help. Guidance inside the screens, so a new staff member can learn without a training session.
• Operations, if you want them. I run my own Linux servers and can host and maintain the system. That is optional, not a lock-in.

The ownership point matters. Everything I build for a client is delivered with the code. That is the difference between commissioning software and renting it.

Build, buy, or carry on by hand?

Not every problem needs a custom build. A short checklist to work through before you spend anything.

| Situation | Likely answer | |---|---| | A standard product exists and your process is ordinary | Buy the hosted product | | Your process is unusual, or it is your competitive edge | Build | | The work is small, occasional, and one person handles it | Carry on by hand, for now | | You need to connect several systems that do not talk | Build the bridge, keep the systems | | You have local obligations a foreign product ignores | Build, or build a layer on top |

I have done all of these. Some of what I run is multi-tenant, meaning one system serving several separate organisations with their data kept apart, such as the real-estate platform behind several Belizean agency websites, a school management system live with a Belizean school, and HR and payroll. Other work is a narrow bridge, such as moving QuickBooks Desktop data to the web, or filing e-invoices with the Belize Tax Service. The services page sets out the range.

What slows projects down?

Three things, almost always.

1. Content that never arrives. The staff photos, the policy text, the price list. The build finishes and waits.
2. Decisions by committee. See the named decision-maker above.
3. Scope that grows without a change note. Additions are fine. Additions that nobody writes down, prices or schedules are how a project loses its shape.

None of these are technical problems, which is why they are worth naming before the work starts.

Where to start

1. Write the one-page problem statement. Do it yourself, not by committee.
2. Name the decision-maker and tell your team who it is.
3. Sketch the current process on paper, including what happens when things go wrong.
4. Pull together a sample of real data and a list of every report you are obliged to produce.
5. Decide, honestly, who will look after the system a year from now.

If you have those five things, a first conversation is usually productive rather than exploratory, and I can generally tell you within a meeting whether a build is the right answer. You are welcome to get in touch when you are ready.