This article is currently available in English while its AM translation is prepared or reviewed.
A request for custom software usually starts with frustration: too many spreadsheets, missed renewals, or customers asking questions nobody can answer quickly. Turning that frustration into a decision means comparing what the system will cost with what it will change. A simple, honest business case helps owners decide whether to build, buy, wait, or fix the process first.
This guide explains how to put one together without pretending to more precision than you have.
Describe the problem in operational terms
Start by writing down what happens today, in numbers where you can. For example:
- how many hours staff spend each week re-entering or reconciling information;
- how many jobs, deliveries or bookings are delayed, missed or disputed each month;
- how often renewals, payments or follow-ups are missed, and what each miss costs;
- how long it takes to answer a customer or manager who asks for a status update; and
- what growth you cannot take on because the current process will not cope.
Use real records where possible: a month of spreadsheets, message threads, job sheets or complaint logs. Estimates are acceptable, but label them as estimates and note who provided them.
Count the full cost of the system
The build price is only part of the cost. A fair comparison includes:
- Discovery and design: the time to map the workflow and agree requirements.
- Development and testing: building the agreed scope in phases.
- Your team's time: staff attending workshops, testing, preparing data and learning the system.
- Data migration: cleaning and importing existing records.
- Hosting and services: servers, storage, backups, SMS or messaging, maps and payment fees.
- Support and improvement: fixes, security updates and changes as the business evolves, usually as a monthly arrangement.
For an off-the-shelf product, the equivalent costs are subscriptions per user or per month, setup, integration, customisation limits, and the workarounds your team will still need where the product does not fit.
Estimate the benefits you can defend
Group benefits into categories and estimate each one conservatively:
- Time saved: hours of manual work removed, multiplied by a realistic cost per hour.
- Losses avoided: fewer missed renewals, penalties, write-offs or disputes.
- Revenue protected or added: faster quotes, fewer lost bookings, capacity to serve more customers without more administrative staff.
- Risk reduced: better access control, audit history and backup of business-critical records.
Some benefits, such as better decisions or happier customers, are real but hard to price. List them separately rather than forcing a number on them, so the core case does not depend on them.
Work through an illustrative example
The figures below are made up to show the method. Your own numbers will differ.
A service business has three coordinators who each spend about 8 hours a week reconciling job sheets, payments and customer messages. At an assumed fully loaded cost of KES 600 per hour, that is roughly KES 14,400 a week, or about KES 62,000 a month. The business also estimates it loses two jobs a month to missed follow-ups, worth about KES 40,000 in margin.
If a system removes most of the reconciliation work and halves the missed follow-ups, the monthly benefit might be around KES 50,000 in time and KES 20,000 in protected margin, roughly KES 70,000 a month before ongoing costs. Subtract monthly hosting and support, then compare the remaining benefit with the one-time cost of discovery, build and migration to estimate the payback period.
The point is not the exact figure. It is to see whether the case is clearly positive, borderline, or depends entirely on optimistic assumptions.
Test the assumptions
Before deciding, ask:
- Which assumption, if wrong, would change the decision?
- Have the people who do the work today agreed with the time estimates?
- Could a process change, training or a cheaper tool capture most of the benefit?
- What is the smallest first phase that would prove the benefit?
If the case only works when everything goes perfectly, reduce the scope or start with an off-the-shelf tool and revisit later.
Plan in phases
A phased plan lowers risk and lets you measure results early. A typical shape is:
- Discovery: map the workflow, agree measures and the first-phase scope.
- First release: the smallest set of features that removes the biggest manual effort.
- Measure: compare the agreed measures after a few weeks of real use.
- Extend: add integrations, reports or automation based on what the first phase showed.
Each phase should end with something the team uses, not just documents.
What a good proposal should include
When you speak to a development partner, expect a proposal that explains the problem in your words, the scope of the first phase, what is out of scope, the delivery timeline in milestones, ownership of code and data, hosting and support arrangements, and how changes are priced. If a proposal promises a fixed result without discussing your workflow, ask more questions.
Business case checklist
- Describe today's problem with real numbers or labelled estimates.
- Include all costs: discovery, build, your team's time, migration, hosting and support.
- Estimate benefits conservatively and keep hard-to-price benefits separate.
- Identify the assumptions that would change the decision.
- Compare with process changes and off-the-shelf options.
- Start with a measurable first phase.
For help comparing options, read custom software vs. off-the-shelf platforms and signs your business has outgrown spreadsheets.