software product engineering in Kenya rarely fails at the demo. It fails eighteen months later, when the person who built the billing module has left and nobody can explain why a credit note posts twice.
That distance between a working prototype and a maintainable product is where most of the money disappears.
software product engineering in Kenya should be judged on what a new team can do with the code in year three, not on how quickly the first team impressed the board.
Three things carry most of that weight: what gets written down before coding, what gets automated, and who owns the accounts in the end.
Discovery That Answers the Awkward Questions
Discovery is sold as a workshop and a wireframe. It is really an interrogation of how the business behaves when something goes wrong.
Good software product engineering in Kenya begins with the person doing the work today: a dispatch clerk shadowed for a morning, a credit controller chasing a statement, the store clerk keying counts.
The brief describes the happy path; shadowing reveals the exceptions. Exceptions are where products fail, because no requirements document mentions them.
software product engineering in Kenya should produce a process map with every exception marked, then agree which ones version one handles and which stay manual.
Write acceptance criteria in plain sentences. “A credit note can be raised against a partially delivered order and the balance stays open” is testable; “handle returns” is not.
Prototype the two riskiest screens before anyone estimates. A clickable mockup exposes disagreement in twenty minutes that a document hides for a month.
Two weeks of interviews costs less than one sprint spent rebuilding a workflow nobody uses. That comparison, rather than the schedule, is the honest argument for discovery.
Discovery ends with a scope statement, a delivery sequence, a non-scope list and an estimate range. A single number is a promise nobody can keep.
Budget discovery separately at five to ten per cent of the build, because software product engineering in Kenya is cheapest when the thinking happens before the code.
A Scope Document With a Non-Scope List
Scope creep rarely arrives as a demand. It arrives as a reasonable request from a senior person in week six, small enough to accept.
The defence is a written non-scope list: features deliberately excluded, user groups not served yet, reports you will not build.
software product engineering in Kenya should attach that list to the contract, so a later request becomes a priced change rather than an argument about memory.
Revisit it every quarter. Some exclusions turn urgent, and moving them into scope deliberately is very different from absorbing them silently.
software product engineering in Kenya should keep requests in one backlog with a date and a requester. A list living in email threads can only be argued about, never prioritised.
Decide who can say yes. If four managers can add work, the delivery date belongs to none of them.
Write the decision rights into the project charter and name the deputy in the same paragraph. Unowned approval is the most common reason a two-week change takes six.
Give the product owner a written mandate and a deputy. Decisions stall when the only person who can approve a screen is in a two-week workshop.
software product engineering in Kenya should price every change at the same rate whatever its size, so small additions do not become free work that quietly eats the contingency.
Architecture for the Team You Can Actually Hire
Most Kenyan products are built by small teams, so the architecture should assume a small team will maintain it. Microservices for three developers is a cost with no matching benefit.
A modular monolith with clear internal boundaries is usually the right shape for software product engineering in Kenya: one deployment, one database, modules that can be separated later.
Choose a stack you can hire for in Nairobi. The gap between a mainstream framework and an exotic one is measured in weeks of onboarding, not in elegance.
software product engineering in Kenya should record the two or three decisions that would be expensive to reverse, and leave the rest open for the team to change.
Keep the dependency count low. Every library is a future upgrade, a licence question and a security advisory with your name on it.
Design the schema with reporting in mind. Retrofitting reporting onto a transactional schema is a project in itself, usually discovered by a finance manager in month nine.
Version public interfaces from day one. Internal endpoints can change freely; anything a customer integrates with cannot.
software product engineering in Kenya should write an architecture note of four pages, not forty. The pages nobody reads protect nothing, and the team knows which ones those are.
Data Model Decisions That Are Expensive to Reverse
The data model outlives the framework, the team and often the vendor. A wrong relationship costs more in year three than any interface mistake.
Model the customer once. Duplicating a customer per module is the most common reason two reports disagree about revenue in the same meeting.
Money needs a currency, a rate and a date attached to it. One shilling column works until the first invoice is priced in dollars.
software product engineering in Kenya should keep an audit table for anything an auditor might ask about: price changes, credit limits, stock adjustments.
Decide how deletion works before the first record exists. A soft delete with a reason beats a support ticket that begins “the invoice disappeared”.
Test the model with three years of plausible volume. A schema that performs on demo data fails quietly at month fourteen, usually on a report nobody tested.
Name every table in a data dictionary and keep it current. Two developers guessing what a status code means is how reporting breaks in year two.
Migration scripts deserve the same care as the schema. A one-line update run without a verified backup has ended more projects than any framework upgrade.
software product engineering in Kenya should review the model with the finance team, not only the developers, because half the expensive mistakes are accounting ones.
Estimates, Prototypes and the Range You Can Defend
An estimate is a forecast, and a forecast without a range is a guess wearing a suit. Give the board a low, likely and high figure with the assumptions listed.
Estimate by feature group, not by screen. A screen hides validation, permissions, error states and the report someone will request in week two.
software product engineering in Kenya should quote in ranges and commit to a date only after discovery closes. A fixed date invented before the work was understood is a liability.
Velocity for a new team is unknown for a month at least. Planning as if it were known produces the overtime that precedes most resignations.
Track actual hours against the estimate for the first three months. That ratio is the only reliable calibration available, and it beats any benchmark borrowed from another project.
Prototype the integration before estimating it. Payment, SMS and eTIMS connections each carry failure paths that a wireframe cannot show.
Keep a buffer for the work nobody scoped: environment setup, data migration, training and the tidying that software product engineering in Kenya always finds after launch.
Report progress against the range weekly, not against the original optimism. A forecast updated in public is more useful than one defended in private.
software product engineering in Kenya should put the assumptions in writing, including who provides test data and when the integration credentials arrive.
Buy, Configure or Build: The Five-Year Comparison
Payroll, statutory accounting and email are solved problems. Building them is an expensive way to be late.
The build case is strongest when the workflow is the differentiator, which is the argument software product engineering in Kenya should test before writing code: how you price, dispatch and serve.
Configure before you customise. A package configured to eighty per cent of the process usually beats a bespoke system at a third of the cost.
Deep customisation of an ERP is the classic trap. The customisation becomes unupgradable, and the vendor’s next release turns into a project rather than a patch.
software product engineering in Kenya should include a buy-versus-build note for every module, with licence cost projected over five years.
Recurring licence cost deserves the same scrutiny as build cost. A subscription that grows with headcount can outrun a build within four years.
Consider the exit before the entry. If data cannot leave in a usable format, a low monthly price is a rental you can never end.
Ask two vendors the same twelve questions and compare the answers in writing. The gaps between those answers are the real specification, and they are usually informative.
Write the comparison on one page with three columns, and have software product engineering in Kenya defend the numbers in front of the board. A table nobody can read is a decision nobody made.
QA That Runs on Every Commit
Quality is a process, not a phase at the end. If testing happens once, the final fortnight decides whether the launch happens.
Automate the paths that carry money and records: login, checkout, invoice generation, stock movement, payment reconciliation.
Manual testing still matters for judgement, layout and the awkward case. A tester who knows the business finds the scenario no script covers.
software product engineering in Kenya should keep a regression suite that finishes in under twenty minutes, because a slow suite gets skipped and then abandoned.
Test on the devices users hold. A mid-range Android phone on congested data behaves nothing like a laptop on office fibre, and the difference appears as a support queue.
Keep one test handset on the slowest network the business tolerates and treat it as production. Performance problems found there are cheap; the same problems found by customers are not.
Use realistic volumes. A system tested with three customers behaves differently at three thousand, and the difference is usually a missing index.
Bugs need severity, an owner and a date. Forty open issues without triage is a list nobody acts on, however diligently it is maintained.
software product engineering in Kenya should publish the pass rate weekly. A suite that has been red for a month is measuring nothing at all.
Release Cadence and the Rollback You Have Rehearsed
Small frequent releases are safer than large occasional ones. A release of two changes is diagnosable; one of forty is an investigation.
Weekly or fortnightly suits most products, and software product engineering in Kenya should publish the calendar so branches know when to expect change.
Do not deploy on Friday afternoon. The rule sounds superstitious until the first rollback at seven in the evening, and then it sounds obvious.
Feature flags separate release from launch. Deploying code that is switched off removes most of the drama from a risky change.
Name the owner of every flag and set an expiry date. Flags left open for a year become permanent branches, and permanent branches never get tested.
software product engineering in Kenya should keep migrations backward compatible, so the previous version still runs while a rollback is in progress.
Write release notes for the business: three sentences on what changed and what to watch. Engineers read the commit log; managers read the three sentences.
Nominate one person on call after a release, with a written rollback step and the number of whoever owns the integration.
software product engineering in Kenya should rehearse a rollback once a quarter. A rollback that has never been executed is a plan, and plans fail at the worst possible moment.
Documentation a New Engineer Uses in Week One
Documentation fails when it is a separate activity nobody owns. It works when it sits beside the code and changes with it.
Start with a README a new developer can follow: run locally, run tests, deploy, who to ask. If those four answers are missing, every hire starts at a disadvantage.
Write short decision records. One page per choice, with the context, the options considered and the reason, dated and signed.
software product engineering in Kenya should set an onboarding target: a new developer ships a small change in the first week, with review.
Runbooks matter more than diagrams during an incident. A page on restarting the payment worker will be read at two in the morning, by someone who did not write it.
Record a short screen capture of the deployment while it still works. Five minutes of video answers questions that three pages of careful prose somehow cannot.
Generate API documentation from the code, and let software product engineering in Kenya review it against a real integration. A handwritten reference drifts within a month.
Review quarterly and delete what is wrong. A wiki of obsolete pages teaches people to ignore all of it, including the three pages that still matter.
Treat documentation as part of the definition of done, and software product engineering in Kenya should refuse a release that leaves the runbook stale.
Taking Over a Product From a Departing Agency
Handovers fail when the commercial relationship ends before the technical one. Plan the handover while everyone is still polite.
Ask for repository access, infrastructure credentials, deployment scripts, third-party account ownership and the current architecture.
software product engineering in Kenya should insist on a code walkthrough with the receiving team, not a zip file and a wish of luck.
Run one small change end to end during the overlap. It proves the pipeline works and exposes the manual step nobody documented.
Check what is registered in whose name: domains, cloud accounts, SMS shortcodes, payment accounts, certificates.
Keep a paid support window of thirty days after handover. Questions arrive in week three, when the new team first touches the billing logic.
List every integration with an owner and a renewal date. A lapsed credential is the most common post-handover outage, and it always happens on a weekend.
software product engineering in Kenya should hand over a written risk list, including the parts of the product that nobody currently understands.
Source Code, IP and the Accounts in Whose Name
The contract should state that the client owns the source code, the designs and the data. Anything less is a rental with extra steps.
Contractors must sign an assignment of intellectual property. A contributor who never assigned rights can complicate a sale, an audit or an investment round.
software product engineering in Kenya should list third-party licences in a file in the repository, with the licence type for each dependency.
Escrow is worth considering for critical systems. Release conditions should be specific: insolvency, a missed support level, or a defined notice period.
Check the deposit is usable. Source code without build instructions and credentials is a filing cabinet, not an escrow.
Ask for the escrow agent’s release process in writing. An escrow nobody can trigger is a storage fee with a legal cover attached to it.
Keep a copy of the repository in an account the company controls, and let software product engineering in Kenya verify that the export actually builds.
Review ownership at every renewal. Accounts migrate quietly when staff change, and nobody notices until a password reset fails during a go-live.
software product engineering in Kenya should put the ownership schedule in the contract appendix, with a named company officer responsible for each asset.
Payments, Messaging and the M-PESA Failure Paths
Payment integration is where optimistic designs meet Kenyan reality. Mobile money callbacks arrive twice, arrive late, or never arrive while the customer insists they paid.
Make every callback idempotent. The same transaction reference must be processed once however many times it is delivered.
software product engineering in Kenya should reconcile against the provider’s statement daily, not only against its own ledger.
Handle the timeout path explicitly. A request that times out may have succeeded, so query before retrying, and log the query.
Distinguish paybill and till flows in the data model, as software product engineering in Kenya should from the first sprint. They generate different references, and merging them creates reconciliation work that never ends.
Test failures deliberately: insufficient funds, cancelled prompts, wrong amounts, duplicate submissions, a callback arriving after midnight.
Keep the provider’s test credentials current and refresh them before every integration change, not during the change window at eleven at night.
SMS is not a reliable channel. Treat delivery reports as advisory and never let product state depend on a message arriving.
Keep a reconciliation report a finance officer can read without a developer beside them, and have software product engineering in Kenya test it against a week of real traffic.
Performance Budgets for Kenyan Networks
Performance is a product decision with a number attached. A page taking eight seconds on a mid-range phone is abandoned, whatever the design says.
Set the budget before building: first meaningful paint under five seconds on a throttled 3G connection, measured on a real device.
Images are usually the largest cost. Compress on upload, resize on request, serve modern formats; a four megabyte hero image is a decision, not an accident.
software product engineering in Kenya should measure from a location your users occupy, on the network they actually buy.
Cache what does not change and defer what is not needed. Third-party scripts are the quiet budget killer on most pages, and nobody remembers adding them.
Latency from Nairobi to Europe is roughly a hundred and fifty milliseconds per round trip. Fewer round trips is often cheaper than a closer region.
Test with the phone in hand on a matatu route. That is the environment the design has to survive, not the fibre in the boardroom.
Put the budget in the acceptance criteria, so software product engineering in Kenya treats a missed target as a defect rather than a later complaint.
Data Protection and the ODPC Register
The Data Protection Act applies to almost every product built in Kenya. Registration with the Office of the Data Protection Commissioner is a legal step, not a marketing exercise.
Collect less, and let software product engineering in Kenya challenge every field on the form. A field you never capture cannot leak, be retained wrongly or be explained in a breach.
software product engineering in Kenya should define retention per data type and enforce it with a scheduled job, not a policy page.
Consent needs a record: what was shown, when, and what the user agreed to. A checkbox without an audit trail proves nothing to a regulator.
Breach notification has a seventy-two hour expectation. Detection, escalation and a template must exist before the incident, not after it.
Draft the notification template while nothing is wrong. Writing it at midnight with a regulator’s clock running produces sentences that create more problems than they close.
Cross-border storage needs a lawful basis. Know which region holds personal data and who can reach it.
Access should be role-based and reviewed quarterly. A support account with full visibility is a finding, not a convenience.
Keep a data inventory that names the owner of each table holding personal data, and let software product engineering in Kenya review it before an audit rather than during one.
Building the In-House Team That Inherits the Product
The usual path is an agency build followed by an internal hire. That transfer works when it is planned and fails when it is improvised.
Hire the first engineer before the agency leaves, and overlap for at least a month. A handover is a conversation and it needs two people present.
Hire for judgement, not only framework knowledge, and let software product engineering in Kenya set the interview task. Frameworks change; reasoning about a data model does not.
software product engineering in Kenya should give that first hire a clear product owner and a written backlog, or the role becomes firefighting within a quarter.
Pay competitively and be honest about the ceiling. A developer who leaves after eight months costs more than the salary gap that caused the departure.
Give the team ownership of a small area quickly. People who ship stay; people who only read code eventually leave for somewhere they can build.
Set a code review standard and keep it. A team without review learns quickly and learns the wrong things with great confidence.
Keep one external reviewer for architecture decisions. A second opinion twice a year is cheaper than the rewrite it prevents.
Plan the second hire before the first one resigns, and let software product engineering in Kenya interview for the gap rather than the replacement.
Support, Warranties and the Defect That Returns
Support is a product feature. A bug that returns three times teaches users to stop reporting, and the next complaint arrives as a cancellation.
Define severity with examples from your own system, then commit to a response time per severity. Resolution is harder to promise and easy to measure.
software product engineering in Kenya should include a warranty period after launch, typically thirty to ninety days, covering defects in delivered scope.
Keep a reproduction template: what the user did, what happened, what was expected, and the reference. Support without reproduction steps is guessing with a ticket number.
Root-cause every repeat defect. The third occurrence is a design problem, and no amount of patching fixes a design problem.
Report support volume monthly. The trend shows whether quality is improving faster than the product grows, which is the only comparison that matters.
Agree what counts as a defect before the warranty begins. Definitions argued after launch are argued with lawyers in the room, and nobody wins those.
Separate defects from change requests in the same queue, or the warranty will quietly pay for new features.
software product engineering in Kenya should publish the response times achieved, not only the targets, so the renewal conversation rests on evidence.
Total Cost of Ownership Across Five Years
The build is the easiest number to budget and the smallest part of the lifetime cost. Support, hosting, licences and enhancements continue while the product exists.
Plan for fifteen to twenty per cent of the build cost each year in maintenance, as software product engineering in Kenya should state in the proposal. Products that skip it accumulate the debt that forces a rewrite.
software product engineering in Kenya should present a five-year model with the assumptions written down, including headcount, hosting growth and integration changes.
Integration changes are the invisible line. When a payment provider changes a callback format, someone must test and deploy, and that someone costs money every year.
Internal time is real even when no invoice arrives. Product owners, testers and trainers come from the same small management team that runs the business.
Budget for device and browser churn. The phones in use in 2026 will not all run the same browser in 2031, and the replacement cycle belongs in the model.
Include the cost of the exit. Migration, data extraction and a parallel run belong in the model if the vendor relationship sours.
Compare the five-year total against the cost of doing nothing. A slow manual process has a price too, paid monthly in salaries and in customers who quietly stop calling.
Review the model annually against actual spend, and let software product engineering in Kenya explain every variance above ten per cent. A forecast never tested is a rumour.
Keeping the Product Maintainable in Year Three
By year three the original team has usually moved on. What remains is the code, the tests and whatever the documentation says.
Upgrade dependencies on a schedule rather than in a panic. A quarterly afternoon is cheaper than a forced migration under a security advisory.
Keep coverage on the paths that matter, even if total coverage is modest. Percentages flatter; critical-path tests protect.
software product engineering in Kenya should maintain a debt register with an owner and a rough cost, reviewed each quarter.
Avoid single-person knowledge. Two people should be able to deploy, and two should understand the billing rules well enough to change them.
Onboarding speed is the best health metric. If a competent developer needs three weeks for a first change, the product is drifting.
Keep the build reproducible from a clean machine. If setup depends on tribal knowledge held by one person, the product is already in more trouble than the roadmap admits.
Watch the release frequency. A team that has stopped deploying weekly has usually stopped trusting its tests, and the next release will be a large one.
Schedule a maintainability review every year, with software product engineering in Kenya asking the same questions a buyer would ask during due diligence.