A request for custom software often reaches the finance director as a long document written by the people who want to build it. The CFO reads the first page, looks for the cost and the risk, and asks for a shorter version. This article gives you that shorter version in advance. It is a one-page memo for a decision, not a full business case. If you need the full case with return calculations and board questions, our guide to the business case for custom software covers it. This memo comes first: it gets you to a yes, a no or a "bring me more on this one point".
What the memo is for
The memo answers one question: should we spend money on this, in which way, and by when must we decide? It does not prove the idea is good. It makes the choice visible, so the CFO can compare it with other uses of the same money.
A good test: someone who was not in your meetings should be able to read the page in three minutes and say what is being asked, what it costs and what could go wrong.
The page, section by section
1. The decision and the ask (top of the page)
Two sentences. What you want decided, the amount or range, and the date. For example: "Approve up to X for a four-month first release of a quote tool, decision needed by the end of the month because the current contract renews on the first." Putting the ask at the top saves the reader from hunting for it.
2. The problem in business terms
Three to four lines: what happens today, who it affects and what it costs in time, errors or lost orders. Use your own figures and say where they come from. If you do not have a measured figure, write "estimate" and who made it. Do not use industry averages as if they were your numbers.
3. The four options
A small table is the best format. One row per option:
| Option | What it means | Cost over 3 years | Main risk |
|---|---|---|---|
| Buy | Use a ready product as it is | Licences + set-up + training | Product does not fit a key step |
| Adapt | Buy or reuse, then configure or extend | Licences + extension work + upkeep | Dependence on the vendor's changes |
| Build | Develop software for your process | Build + run + change | Scope grows, owner leaves, upkeep is underestimated |
| Do nothing | Keep the current way of working | Ongoing manual time + known losses | Problem grows with volume |
The fourth row matters most. Without it the memo compares a new cost with an imaginary zero. For a longer treatment of the choice between the first three, see our build versus buy decision framework.
4. Cost over three years, as a range
A single launch price hides most of the spend. Show three parts for each option:
- Build or buy: the first release and set-up.
- Run: hosting, licences, support, monitoring.
- Change: the work needed when your process, your rules or a connected system changes. Software that is used gets changed.
Give a low and a high figure, and write in one line what separates them. Our article on the real cost of custom software explains what usually goes into each part.
Worked example (invented numbers, for illustration only). Suppose the current manual process takes 2 people 10 hours each per week. That is 20 hours a week, or about 1,040 hours a year (20 × 52). At a loaded cost of 30 per hour, that is 31,200 a year, or 93,600 over three years. This is the cost of "do nothing" before any growth. A build option with 60,000 for the first release, 8,000 a year to run and 6,000 a year for changes costs 60,000 + 3 × (8,000 + 6,000) = 102,000 over three years. On these numbers, building does not pay back in three years unless it also removes errors, speeds up orders or lets the process handle more volume without more people. The memo should say so, not hide it.
The point of the example is the method: put "do nothing" and each option on the same three-year basis, then ask what else the option changes besides the hours saved.
5. Top three risks
Only three. For each, one line with:
- what could happen,
- the first sign you would see,
- who watches it and what they would do.
Typical choices are scope growth, a key person leaving, a connected system changing, data quality and user adoption. Pick the ones that apply, not the whole list. If a risk has a cheap test, say that you will run it first. Our article on discovery that prevents expensive custom software mistakes describes a short phase that reduces several of these at once.
6. How you will know it worked
Two or three measures with a starting value and a date. Time per case, error rate, orders handled per person. Say who will measure them and when you will report back. Do not promise a return figure you cannot trace to a measurement.
7. Recommendation and what you need
One option, one reason, one next step. If you recommend building, say what the first stage is and what the stop point is: "after the first release we review the measures and decide whether to continue". A staged commitment is easier to approve than an open one.
Keep it to one page
If the memo does not fit, the usual reasons are:
- Too much technical detail. Move it to an appendix and link it.
- Too many options. Four is the maximum; combine similar ones.
- Too many risks. If everything is a risk, nothing is. Keep three.
- Too much history. The CFO needs the present state and the choice, not the project's story.
Common mistakes
- Leaving out "do nothing". The comparison then looks like a cost against nothing.
- One launch price. Run and change costs are often larger than the first release over several years.
- Averages from the internet instead of your own figures. If you have none, say it is an estimate and propose a quick measurement.
- No decision date. A memo without a date gets put aside.
- A request for the whole budget at once. A first stage with a review point is easier to approve and easier to stop.
Where to start this week
Write the first section last. Start with the problem in your own numbers and the four-option table, fill in the three-year ranges with finance, and only then write the ask. Share it with one person who was not involved and ask them what is unclear.
Sources
- Your own process measurements, finance rates and vendor quotes, as noted in the memo; all figures in the worked example are invented for illustration.
- Our related articles linked above.