Most software decisions start with a feature list and end with a regret. Someone asks for a module, a vendor demonstrates it, and nobody asks who will update it when the pricing rules change in March. This guide starts from a workflow that has outgrown its tools, and compares three ways to fix it: buy a product as it comes, configure a product, or build to order.
The example below is fictional. It is built to show the method, not to report a client result.
Start with the process that outgrew its tools
Write one sentence naming what must improve, with a number if you have one. “Quotes take three days because pricing lives in a spreadsheet only one person updates” is a usable sentence. “We need a digital transformation” is not, because nothing can be tested against it.
Our fictional example is Kisumu Ridge Hardware, a distributor with two branches. A salesperson agrees a discount with a trade customer. The branch manager must approve any discount above 8%. The store releases goods only after approval, and accounts invoice from the approved quote. Today the approval travels by phone call and a WhatsApp message. Twice last month a store released goods against a discount nobody had signed off.
What must improve: no goods leave without a recorded approval, and the manager can approve from a phone in under two minutes.
Separate the rules that matter from habits
List every rule the workflow follows. Then ask of each one: what happens if this rule disappears?
| Rule at Kisumu Ridge | If it disappears | Verdict |
|---|---|---|
| Discounts above 8% need manager approval | Margin leaks; the owner cannot see who agreed what | Essential |
| Store releases goods only against an approved quote | Goods leave unrecorded | Essential |
| The quote is printed and signed in blue ink | Nothing breaks; customers accept a PDF | Habit |
| Approval requests go to one named manager | Delays when that manager is away | Habit, with a deputy rule to add |
Essential rules must live in the system. Habits can change to fit the system. The longer the essential list, the more likely you need configuration or a build. A short list that matches how products already work points to buying.
Run all three options through the same workflow
Give each option the same test: the discount approval above, plus one exception (the manager is on leave; a deputy approves). Score what you see, not what the brochure says.
A suitable ready product. The product already has an approval step on discounts, a release-against-approval control and mobile access for the approver. You change your habits, not the software. Risks: the product handles the main path but not your exception, and you discover this after paying.
A configured product. Take a platform with settings for approval thresholds, roles and document templates, and set it up for your rules. Chwezi’s sector products and its Kraal Code ERP sit in this category as options to investigate; owning a product does not prove it fits your workflow, so the demonstration still has to use your example. Risks: configuration that only one consultant understands, and upgrades that overwrite your settings.
Bespoke development. A developer builds exactly the approval chain, with your field names and your deputy rule. Risks: you now own every future change, and the first version only encodes what you knew at the time.
Illustrative image, licensed from Magnific. The dashboard is not a Chwezi product screen and its figures are unrelated to the example.
Ask who maintains it after delivery
Every option has a maintenance owner, even if you have not named one. For each, write down:
- Who changes a setting or rule when the business changes?
- Who supports users when they are locked out or confused?
- Who maintains integrations, such as the link to accounting or mobile money?
- Who approves a change, and how long does a change take?
A product usually has a vendor support desk but limits what you can change. A configured product splits the work between you and the implementer. Bespoke software puts it all on whoever built it, or on you if that person leaves. A system with no named owner decays quietly: fields stop matching reality, workarounds return, and the spreadsheet comes back.
Decide on exit before you decide on technology
Ask, for each option: can I export all my records in a usable format, and what would moving away cost?
For a product, check the export formats and whether your data can leave without the vendor’s help. For bespoke work, check that you hold the source code, the database and the deployment credentials, in writing. Continuity matters too: if the supplier is unavailable for a month, can someone else run and fix the system? This is a contract and documentation question, not a technology one. Raise it before you compare features, because it is hard to negotiate after go-live.
Score the options on one page
Use this scorecard. Rate each cell Pass, Partial or Fail and write the evidence next to it.
| Criterion | Ready product | Configured product | Bespoke |
|---|---|---|---|
| Handles the main workflow with your field names | |||
| Handles the exception (deputy approver) | |||
| Essential rules enforced by the system | |||
| Named owner for settings and changes | |||
| Change effort for the next rule change | |||
| Data export and exit path in writing | |||
| Cost of owning it for your planning horizon | |||
| Open question to resolve in discovery |
Fill the last row honestly. Every option has one unresolved question, and discovery exists to answer it.
Set a checkpoint where evidence can change the choice
Agree a short discovery period before committing. In it, the shortlisted options handle your sample workflow, your essential-rules list is checked against what each does, and the maintenance owner is named. If the evidence moves the choice from build to configure, or from configure to buy, that is the checkpoint working. Write the decision date and the evidence you will accept into the project brief.
What changes by market
The method is the same wherever you work. What changes is what you must confirm locally: where data may be stored under your national data-protection law, which payment and tax integrations a product supports in your country, and whether a supplier can deliver and support you where you operate. For Uganda, Kenya and Tanzania, confirm these with each supplier in writing. For the UK or other markets, check hosting location, support hours and contract law with a local adviser. Do not assume a product’s feature list holds in every country.
Sources and scope
- Chwezi Core Systems, Software development and systems implementation. Public offer description, not independent evidence of capability or results.
- The Kisumu Ridge Hardware example is fictional and invented for this guide. It does not describe a Chwezi client.
Common questions
- Is bespoke software always more expensive than a ready product?
- Not always over the full life of the system, but the cost sits in different places. A product charges a licence or subscription and may need workarounds. Bespoke work charges for design and build up front, then for every later change. Compare the cost of owning each option for the years you expect to use it, including who pays for changes.
- How do I know a rule is essential and not just a habit?
- Ask what happens if the rule disappears. If money, safety, a contract or a legal duty is at risk, it is essential. If the answer is that people would feel uncomfortable, it is a habit the team can change.
- What should I ask a vendor before choosing a product?
- Ask them to run your sample workflow, including one exception, using your field names. Then ask how you export your data, who can change settings, and what a version upgrade does to your configuration.
- Can Chwezi tell me which option suits me?
- Chwezi sells its own products and builds custom systems, so it has an interest in the answer. Ask for a short discovery session in which each option is tested on your workflow and the evidence is written down, including where a product or another supplier fits better.