Commissioning custom software can feel opaque if you have never done it before. Proposals use unfamiliar terms, timelines are hard to judge, and it is not always clear what you are expected to contribute. This guide walks through what a well-run engagement with a development partner looks like, stage by stage, and what to ask at each step.
1. Discovery and scoping
Discovery is a working conversation about how your operation runs today: the process, the people involved, the systems already in place, and where things break down. Expect questions about who enters each piece of information, who relies on it, what happens when something goes wrong, and which reports managers actually use.
A good provider pushes back on scope that does not need to exist rather than agreeing to everything. The outcome should be a short, plain description of the problem, the users, the first set of features worth building, and what is deliberately left out.
What you contribute: time from the people who do the work, examples of real records, and a decision-maker who can settle priorities.
2. Proposal and agreement
The proposal turns discovery into a plan you can approve. It should state, in plain language:
- the problem being solved and the outcome expected;
- the scope of the first phase and what is out of scope;
- the delivery plan, broken into milestones you can test;
- costs for the build and for ongoing hosting and support;
- who owns the source code, designs, documentation, accounts and data;
- how changes to scope are agreed and priced; and
- what support, response times and maintenance look like after launch.
Read it with the people who will use the system. If something is unclear, ask for it to be rewritten. The agreement that follows should match the proposal, so nothing important lives only in an email thread.
3. Design and architecture
Before code is written, the data model, user roles and system structure are mapped out. You will usually see screen designs or clickable prototypes for the main workflows, which is the cheapest point to change your mind.
For anything involving compliance, payments, personal data or real-time information such as vehicle tracking, this stage is where those requirements are built in from the start rather than added later. Ask how access will be controlled, how data will be backed up, and how the system will connect to tools you already use.
4. Build in phases
Larger systems are delivered in working milestones rather than one big reveal at the end. After each milestone you test real features with your own data, report what does not fit, and adjust priorities before too much is fixed in place.
Expect regular check-ins, a shared list of open issues, and a test environment where you can try changes before they reach the live system. If you only see progress at the end, the risk of a mismatch rises sharply.
5. Testing and launch
Before launch, the system is tested against the scenarios agreed in discovery, including the awkward ones: missing information, duplicate records, a payment that arrives late, or a user without the right permissions.
Launch itself needs planning. Existing records are cleaned and imported, users are trained on the tasks they will actually perform, and there is a clear plan for the first days, including who to contact when something looks wrong. Some teams run the old and new processes side by side for a short period to build confidence.
6. Support and improvement
Launch is not the end of the relationship. Real systems need security updates, fixes and new features as your operation changes. A support arrangement usually covers monitoring, updates, an agreed way to report issues, and a set amount of improvement work each month.
Agree how requests are prioritised and how quickly different kinds of issues are handled. Review the system's use with your partner every few months so that improvements follow what the business needs next.
Questions to ask before you start
- What will we have in our hands at the end of each milestone?
- Who on our side needs to be available, and for how long?
- Who owns the code, accounts and data, and how do we get them if we change provider?
- How are changes to scope handled and priced?
- What happens after launch, and what does support cost?
For help choosing a partner, read how to choose a software development partner in Kenya, or see how we work.