Custom Web Application Development in Kenya

A custom web application is built for a specific business process that off-the-shelf software does not fit. A Haryes engagement typically covers:

• Discovery and scoping: mapping the process, the roles, and the data, and cutting the first version down to what must ship to earn
• Architecture: data model, authentication, hosting, and how the system integrates with what you already run
• Build: the application itself, with role-based access and an audit log
• M-Pesa and integrations: collection, disbursement, and reconciliation over the Daraja API, covered on our API integration and M-Pesa platforms page
• Testing: automated tests on the paths that handle money or sensitive data
• Deployment and handover: documentation, a training session, and the code in a repository you own

Common builds include client portals, booking systems, and internal dashboards that replace spreadsheets.

1. Scope the first version narrowly

   We define the smallest version that delivers real value and can go live, and defer everything else. A first version that ships and earns beats a complete system that never launches.

2. Design the data and the flows

   We model the data, the roles, and the permissions, and design the key screens with UI/UX design before building.

3. Build in increments

   We build in two-week increments you can review on a staging environment, with automated tests on the money and data paths and an audit log from day one.

4. Deploy, document, hand over

   We deploy to infrastructure you control, document how it runs, train your team, and agree a support arrangement for after launch.

Scope My Application →Estimate My Build Budget

The most common way a custom build fails is scope: a system designed to do everything, that takes a year, costs triple the estimate, and never quite launches. We scope against a different question, what is the smallest version that delivers real value and can go live?

• We list every feature anyone has asked for, then sort them into “version one” and “later”
• Version one covers one complete workflow end to end for the people who need it most
• Everything else is documented and deferred, not cut, just sequenced
• You get a fixed price and timeline for version one, and a rough roadmap for what comes after

A first version that ships in 8 to 12 weeks and starts earning beats a complete system that is still in development a year later.

Custom software is not finished at launch, it needs hosting, monitoring, security patching, and future changes. We deploy to infrastructure in your own accounts, document how it runs, and agree a support arrangement: either a monthly retainer covering maintenance and a block of development time, or an on-call basis for fixes with new features quoted per project. You always hold the code and can move it to another team.

A system is too large to buy in one decision, so we break it into stages that each end in something usable. Discovery produces a written specification you own and can take to another developer if you choose. The first build delivers the workflow that hurts most, in production, with real users on it. Later phases are quoted separately once that version has been used for a few weeks.

Payment follows the same shape: discovery is paid for on its own, the build is staged against agreed milestones rather than a single sum at the start, and nothing large is committed before the scope is written down. It means a project can be paused between phases without leaving a half-built system nobody can use, and it means the business is never asked to spend six figures on a description.

It also protects against the classic failure of custom software in this market: an eighteen-month build against a specification written before anyone had used anything, delivered to a business whose process changed nine months in.

Many Kenyan applications are used away from a desk: a field officer recording visits upcountry, a driver confirming a delivery, an agent registering a member at a roadside kiosk. If the system assumes a stable connection, those users will fall back to paper and type it in later, which reintroduces exactly the errors the system was built to remove.

Designing for that means forms that survive a dropped connection, submissions that retry rather than vanish, interfaces light enough to load on a weak signal, and clear feedback about what has and has not been saved. Where the work genuinely happens offline, we scope local storage and synchronisation deliberately, because retrofitting it onto a system that assumed connectivity is close to a rewrite.

A new application almost never lives alone. There is usually accounting software, a payments provider, an existing website, a stock system, or at minimum several years of spreadsheets that have to be carried over. How that data is modelled at the start determines what the system can do in year three.

We map the entities before writing code: what a customer is, what an order or a case or a member is, how they relate, and which fields are genuinely required. Then we plan the integrations honestly. Some systems offer a proper API. Some offer a file export on a schedule. Some offer nothing, and the practical answer is a structured import that somebody runs weekly, which is not elegant but is far cheaper than pretending otherwise.

Migrating existing records is a project of its own and we scope it as one: cleaning, de-duplicating, deciding what not to bring, and running the import twice, once as a rehearsal and once for real.

A custom application is not a one-off purchase; it is something you now operate. That means at least two environments, a staging copy where changes are tested and the production system people depend on, with releases moving in one direction after a check rather than edits made live.

It also means running costs: hosting sized to real usage, a database with automated and tested backups, monitoring that tells us when something fails before a user reports it, certificate renewals, and third-party services the system depends on. We put a monthly figure on all of it during scoping, because a business that budgets only for the build is surprised twice, once by the running cost and once by the support it turns out to need.

Support itself is scoped rather than assumed: what is covered, how quickly we respond to a system that is down as opposed to a cosmetic bug, and how new features are requested and priced once the thing is live.

The most common failure of internal systems in Kenya is not technical. The software works and the team keeps using the spreadsheet, because the old way is faster for the person doing it even if it is worse for the organisation. A system nobody uses is a total loss regardless of how well it is built.

We plan for that from the start: involving the people who will actually use it during discovery, making the first version genuinely faster than what it replaces for at least one daily task, training in the organisation’s own words with a recording kept for new staff, and agreeing a cut-over date after which the old method stops rather than running both indefinitely.

Then we watch the first month. Which screens are used, where people stop halfway, what they still do outside the system. That is where the second release comes from, and it is a far better guide than the feature list anyone wrote before launch.

Describe the process you want to systemise, who uses it, and what breaks today. You get back a build-versus-buy recommendation and, if a build makes sense, a scoped first-version proposal within five working days.

Request an Application Roadmap →Describe Your Project on WhatsApp