{"id":1072,"date":"2026-11-10T15:03:50","date_gmt":"2026-11-10T15:03:50","guid":{"rendered":"https:\/\/zamacore.com\/blog\/?p=1072"},"modified":"2026-11-10T15:03:50","modified_gmt":"2026-11-10T15:03:50","slug":"software-product-engineering-in-kenya","status":"publish","type":"post","link":"https:\/\/zamacore.com\/blog\/software-product-engineering-in-kenya\/","title":{"rendered":"Software Product Engineering in Kenya: From Idea to a Maintainable Product"},"content":{"rendered":"<p><a href=\"https:\/\/zamacore.com\/blog\/e-commerce-development-in-kenya\/zamacore_-built-for-whats-next\/\" rel=\"attachment wp-att-978\"><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-978\" src=\"https:\/\/zamacore.com\/blog\/wp-content\/uploads\/2026\/10\/Zamacore_-Built-for-Whats-Next.png\" alt=\"Software Product Engineering in Kenya\" width=\"1254\" height=\"1254\" srcset=\"https:\/\/zamacore.com\/blog\/wp-content\/uploads\/2026\/10\/Zamacore_-Built-for-Whats-Next.png 1254w, https:\/\/zamacore.com\/blog\/wp-content\/uploads\/2026\/10\/Zamacore_-Built-for-Whats-Next-300x300.png 300w, https:\/\/zamacore.com\/blog\/wp-content\/uploads\/2026\/10\/Zamacore_-Built-for-Whats-Next-1024x1024.png 1024w, https:\/\/zamacore.com\/blog\/wp-content\/uploads\/2026\/10\/Zamacore_-Built-for-Whats-Next-150x150.png 150w, https:\/\/zamacore.com\/blog\/wp-content\/uploads\/2026\/10\/Zamacore_-Built-for-Whats-Next-768x768.png 768w\" sizes=\"auto, (max-width: 1254px) 100vw, 1254px\" \/><\/a><\/p>\n<p><a href=\"https:\/\/zamacore.com\">software product engineering in Kenya<\/a> 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.<\/p>\n<p>That distance between a working prototype and a maintainable product is where most of the money disappears.<\/p>\n<p><a href=\"https:\/\/zama.co.ke\" target=\"_blank\" rel=\"noopener\">software product engineering in Kenya<\/a> 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.<\/p>\n<p>Three things carry most of that weight: what gets written down before coding, what gets automated, and who owns the accounts in the end.<\/p>\n<div id=\"ez-toc-container\" class=\"ez-toc-v2_0_86 counter-hierarchy ez-toc-counter ez-toc-grey ez-toc-container-direction\">\n<div class=\"ez-toc-title-container\">\n<p class=\"ez-toc-title\" style=\"cursor:inherit\">Table of Contents<\/p>\n<span class=\"ez-toc-title-toggle\"><a href=\"#\" class=\"ez-toc-pull-right ez-toc-btn ez-toc-btn-xs ez-toc-btn-default ez-toc-toggle\" aria-label=\"Toggle Table of Content\"><span class=\"ez-toc-js-icon-con\"><span class=\"\"><span class=\"eztoc-hide\" style=\"display:none;\">Toggle<\/span><span class=\"ez-toc-icon-toggle-span\"><svg style=\"fill: #999;color:#999\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" class=\"list-377408\" width=\"20px\" height=\"20px\" viewBox=\"0 0 24 24\" fill=\"none\"><path d=\"M6 6H4v2h2V6zm14 0H8v2h12V6zM4 11h2v2H4v-2zm16 0H8v2h12v-2zM4 16h2v2H4v-2zm16 0H8v2h12v-2z\" fill=\"currentColor\"><\/path><\/svg><svg style=\"fill: #999;color:#999\" class=\"arrow-unsorted-368013\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" width=\"10px\" height=\"10px\" viewBox=\"0 0 24 24\" version=\"1.2\" baseProfile=\"tiny\"><path d=\"M18.2 9.3l-6.2-6.3-6.2 6.3c-.2.2-.3.4-.3.7s.1.5.3.7c.2.2.4.3.7.3h11c.3 0 .5-.1.7-.3.2-.2.3-.5.3-.7s-.1-.5-.3-.7zM5.8 14.7l6.2 6.3 6.2-6.3c.2-.2.3-.5.3-.7s-.1-.5-.3-.7c-.2-.2-.4-.3-.7-.3h-11c-.3 0-.5.1-.7.3-.2.2-.3.5-.3.7s.1.5.3.7z\"\/><\/svg><\/span><\/span><\/span><\/a><\/span><\/div>\n<nav><ul class='ez-toc-list ez-toc-list-level-1 ' ><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-1\" href=\"https:\/\/zamacore.com\/blog\/software-product-engineering-in-kenya\/#Discovery_That_Answers_the_Awkward_Questions\" >Discovery That Answers the Awkward Questions<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-2\" href=\"https:\/\/zamacore.com\/blog\/software-product-engineering-in-kenya\/#A_Scope_Document_With_a_Non-Scope_List\" >A Scope Document With a Non-Scope List<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-3\" href=\"https:\/\/zamacore.com\/blog\/software-product-engineering-in-kenya\/#Architecture_for_the_Team_You_Can_Actually_Hire\" >Architecture for the Team You Can Actually Hire<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-4\" href=\"https:\/\/zamacore.com\/blog\/software-product-engineering-in-kenya\/#Data_Model_Decisions_That_Are_Expensive_to_Reverse\" >Data Model Decisions That Are Expensive to Reverse<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-5\" href=\"https:\/\/zamacore.com\/blog\/software-product-engineering-in-kenya\/#Estimates_Prototypes_and_the_Range_You_Can_Defend\" >Estimates, Prototypes and the Range You Can Defend<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-6\" href=\"https:\/\/zamacore.com\/blog\/software-product-engineering-in-kenya\/#Buy_Configure_or_Build_The_Five-Year_Comparison\" >Buy, Configure or Build: The Five-Year Comparison<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-7\" href=\"https:\/\/zamacore.com\/blog\/software-product-engineering-in-kenya\/#QA_That_Runs_on_Every_Commit\" >QA That Runs on Every Commit<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-8\" href=\"https:\/\/zamacore.com\/blog\/software-product-engineering-in-kenya\/#Release_Cadence_and_the_Rollback_You_Have_Rehearsed\" >Release Cadence and the Rollback You Have Rehearsed<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-9\" href=\"https:\/\/zamacore.com\/blog\/software-product-engineering-in-kenya\/#Documentation_a_New_Engineer_Uses_in_Week_One\" >Documentation a New Engineer Uses in Week One<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-10\" href=\"https:\/\/zamacore.com\/blog\/software-product-engineering-in-kenya\/#Taking_Over_a_Product_From_a_Departing_Agency\" >Taking Over a Product From a Departing Agency<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-11\" href=\"https:\/\/zamacore.com\/blog\/software-product-engineering-in-kenya\/#Source_Code_IP_and_the_Accounts_in_Whose_Name\" >Source Code, IP and the Accounts in Whose Name<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-12\" href=\"https:\/\/zamacore.com\/blog\/software-product-engineering-in-kenya\/#Payments_Messaging_and_the_M-PESA_Failure_Paths\" >Payments, Messaging and the M-PESA Failure Paths<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-13\" href=\"https:\/\/zamacore.com\/blog\/software-product-engineering-in-kenya\/#Performance_Budgets_for_Kenyan_Networks\" >Performance Budgets for Kenyan Networks<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-14\" href=\"https:\/\/zamacore.com\/blog\/software-product-engineering-in-kenya\/#Data_Protection_and_the_ODPC_Register\" >Data Protection and the ODPC Register<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-15\" href=\"https:\/\/zamacore.com\/blog\/software-product-engineering-in-kenya\/#Building_the_In-House_Team_That_Inherits_the_Product\" >Building the In-House Team That Inherits the Product<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-16\" href=\"https:\/\/zamacore.com\/blog\/software-product-engineering-in-kenya\/#Support_Warranties_and_the_Defect_That_Returns\" >Support, Warranties and the Defect That Returns<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-17\" href=\"https:\/\/zamacore.com\/blog\/software-product-engineering-in-kenya\/#Total_Cost_of_Ownership_Across_Five_Years\" >Total Cost of Ownership Across Five Years<\/a><\/li><li class='ez-toc-page-1 ez-toc-heading-level-2'><a class=\"ez-toc-link ez-toc-heading-18\" href=\"https:\/\/zamacore.com\/blog\/software-product-engineering-in-kenya\/#Keeping_the_Product_Maintainable_in_Year_Three\" >Keeping the Product Maintainable in Year Three<\/a><\/li><\/ul><\/nav><\/div>\n<h2><span class=\"ez-toc-section\" id=\"Discovery_That_Answers_the_Awkward_Questions\"><\/span>Discovery That Answers the Awkward Questions<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Discovery is sold as a workshop and a wireframe. It is really an interrogation of how the business behaves when something goes wrong.<\/p>\n<p>Good <a href=\"https:\/\/dexa.co.ke\" target=\"_blank\" rel=\"noopener\">software product engineering in Kenya<\/a> 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.<\/p>\n<p>The brief describes the happy path; shadowing reveals the exceptions. Exceptions are where products fail, because no requirements document mentions them.<\/p>\n<p><a href=\"https:\/\/pawa.co.ke\" target=\"_blank\" rel=\"noopener\">software product engineering in Kenya<\/a> should produce a process map with every exception marked, then agree which ones version one handles and which stay manual.<\/p>\n<p>Write acceptance criteria in plain sentences. &#8220;A credit note can be raised against a partially delivered order and the balance stays open&#8221; is testable; &#8220;handle returns&#8221; is not.<\/p>\n<p>Prototype the two riskiest screens before anyone estimates. A clickable mockup exposes disagreement in twenty minutes that a document hides for a month.<\/p>\n<p>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.<\/p>\n<p>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.<\/p>\n<p>Budget discovery separately at five to ten per cent of the build, because <a href=\"https:\/\/pms.co.ke\" target=\"_blank\" rel=\"noopener\">software product engineering in Kenya<\/a> is cheapest when the thinking happens before the code.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"A_Scope_Document_With_a_Non-Scope_List\"><\/span>A Scope Document With a Non-Scope List<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Scope creep rarely arrives as a demand. It arrives as a reasonable request from a senior person in week six, small enough to accept.<\/p>\n<p>The defence is a written non-scope list: features deliberately excluded, user groups not served yet, reports you will not build.<\/p>\n<p><a href=\"https:\/\/estateadmin.co.ke\" target=\"_blank\" rel=\"noopener\">software product engineering in Kenya<\/a> should attach that list to the contract, so a later request becomes a priced change rather than an argument about memory.<\/p>\n<p>Revisit it every quarter. Some exclusions turn urgent, and moving them into scope deliberately is very different from absorbing them silently.<\/p>\n<p><a href=\"https:\/\/churchesadmin.com\" target=\"_blank\" rel=\"noopener\">software product engineering in Kenya<\/a> 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.<\/p>\n<p>Decide who can say yes. If four managers can add work, the delivery date belongs to none of them.<\/p>\n<p>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.<\/p>\n<p>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.<\/p>\n<p><a href=\"https:\/\/vega.co.ke\" target=\"_blank\" rel=\"noopener\">software product engineering in Kenya<\/a> should price every change at the same rate whatever its size, so small additions do not become free work that quietly eats the contingency.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Architecture_for_the_Team_You_Can_Actually_Hire\"><\/span>Architecture for the Team You Can Actually Hire<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>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.<\/p>\n<p>A modular monolith with clear internal boundaries is usually the right shape for <a href=\"https:\/\/dereva.co.ke\" target=\"_blank\" rel=\"noopener\">software product engineering in Kenya<\/a>: one deployment, one database, modules that can be separated later.<\/p>\n<p>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.<\/p>\n<p><a href=\"https:\/\/jaat.co.ke\" target=\"_blank\" rel=\"noopener\">software product engineering in Kenya<\/a> should record the two or three decisions that would be expensive to reverse, and leave the rest open for the team to change.<\/p>\n<p>Keep the dependency count low. Every library is a future upgrade, a licence question and a security advisory with your name on it.<\/p>\n<p>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.<\/p>\n<p>Version public interfaces from day one. Internal endpoints can change freely; anything a customer integrates with cannot.<\/p>\n<p><a href=\"https:\/\/wito.co.ke\" target=\"_blank\" rel=\"noopener\">software product engineering in Kenya<\/a> should write an architecture note of four pages, not forty. The pages nobody reads protect nothing, and the team knows which ones those are.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Data_Model_Decisions_That_Are_Expensive_to_Reverse\"><\/span>Data Model Decisions That Are Expensive to Reverse<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>The data model outlives the framework, the team and often the vendor. A wrong relationship costs more in year three than any interface mistake.<\/p>\n<p>Model the customer once. Duplicating a customer per module is the most common reason two reports disagree about revenue in the same meeting.<\/p>\n<p>Money needs a currency, a rate and a date attached to it. One shilling column works until the first invoice is priced in dollars.<\/p>\n<p><a href=\"https:\/\/awasam.co.ke\" target=\"_blank\" rel=\"noopener\">software product engineering in Kenya<\/a> should keep an audit table for anything an auditor might ask about: price changes, credit limits, stock adjustments.<\/p>\n<p>Decide how deletion works before the first record exists. A soft delete with a reason beats a support ticket that begins &#8220;the invoice disappeared&#8221;.<\/p>\n<p>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.<\/p>\n<p>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.<\/p>\n<p>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.<\/p>\n<p><a href=\"https:\/\/saseni.co.ke\" target=\"_blank\" rel=\"noopener\">software product engineering in Kenya<\/a> should review the model with the finance team, not only the developers, because half the expensive mistakes are accounting ones.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Estimates_Prototypes_and_the_Range_You_Can_Defend\"><\/span>Estimates, Prototypes and the Range You Can Defend<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>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.<\/p>\n<p>Estimate by feature group, not by screen. A screen hides validation, permissions, error states and the report someone will request in week two.<\/p>\n<p><a href=\"https:\/\/prim.co.ke\" target=\"_blank\" rel=\"noopener\">software product engineering in Kenya<\/a> 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.<\/p>\n<p>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.<\/p>\n<p>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.<\/p>\n<p>Prototype the integration before estimating it. Payment, SMS and eTIMS connections each carry failure paths that a wireframe cannot show.<\/p>\n<p>Keep a buffer for the work nobody scoped: environment setup, data migration, training and the tidying that <a href=\"https:\/\/rentaldesk.co.ke\" target=\"_blank\" rel=\"noopener\">software product engineering in Kenya<\/a> always finds after launch.<\/p>\n<p>Report progress against the range weekly, not against the original optimism. A forecast updated in public is more useful than one defended in private.<\/p>\n<p><a href=\"https:\/\/fama.co.ke\" target=\"_blank\" rel=\"noopener\">software product engineering in Kenya<\/a> should put the assumptions in writing, including who provides test data and when the integration credentials arrive.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Buy_Configure_or_Build_The_Five-Year_Comparison\"><\/span>Buy, Configure or Build: The Five-Year Comparison<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Payroll, statutory accounting and email are solved problems. Building them is an expensive way to be late.<\/p>\n<p>The build case is strongest when the workflow is the differentiator, which is the argument <a href=\"https:\/\/spacekits.co.ke\" target=\"_blank\" rel=\"noopener\">software product engineering in Kenya<\/a> should test before writing code: how you price, dispatch and serve.<\/p>\n<p>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.<\/p>\n<p>Deep customisation of an ERP is the classic trap. The customisation becomes unupgradable, and the vendor&#8217;s next release turns into a project rather than a patch.<\/p>\n<p><a href=\"https:\/\/zamacore.com\">software product engineering in Kenya<\/a> should include a buy-versus-build note for every module, with licence cost projected over five years.<\/p>\n<p>Recurring licence cost deserves the same scrutiny as build cost. A subscription that grows with headcount can outrun a build within four years.<\/p>\n<p>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.<\/p>\n<p>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.<\/p>\n<p>Write the comparison on one page with three columns, and have <a href=\"https:\/\/mystayorbit.com\" target=\"_blank\" rel=\"noopener\">software product engineering in Kenya<\/a> defend the numbers in front of the board. A table nobody can read is a decision nobody made.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"QA_That_Runs_on_Every_Commit\"><\/span>QA That Runs on Every Commit<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Quality is a process, not a phase at the end. If testing happens once, the final fortnight decides whether the launch happens.<\/p>\n<p>Automate the paths that carry money and records: login, checkout, invoice generation, stock movement, payment reconciliation.<\/p>\n<p>Manual testing still matters for judgement, layout and the awkward case. A tester who knows the business finds the scenario no script covers.<\/p>\n<p><a href=\"https:\/\/dexa.co.ke\" target=\"_blank\" rel=\"noopener\">software product engineering in Kenya<\/a> should keep a regression suite that finishes in under twenty minutes, because a slow suite gets skipped and then abandoned.<\/p>\n<p>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.<\/p>\n<p>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.<\/p>\n<p>Use realistic volumes. A system tested with three customers behaves differently at three thousand, and the difference is usually a missing index.<\/p>\n<p>Bugs need severity, an owner and a date. Forty open issues without triage is a list nobody acts on, however diligently it is maintained.<\/p>\n<p><a href=\"https:\/\/zama.co.ke\" target=\"_blank\" rel=\"noopener\">software product engineering in Kenya<\/a> should publish the pass rate weekly. A suite that has been red for a month is measuring nothing at all.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Release_Cadence_and_the_Rollback_You_Have_Rehearsed\"><\/span>Release Cadence and the Rollback You Have Rehearsed<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Small frequent releases are safer than large occasional ones. A release of two changes is diagnosable; one of forty is an investigation.<\/p>\n<p>Weekly or fortnightly suits most products, and <a href=\"https:\/\/pawa.co.ke\" target=\"_blank\" rel=\"noopener\">software product engineering in Kenya<\/a> should publish the calendar so branches know when to expect change.<\/p>\n<p>Do not deploy on Friday afternoon. The rule sounds superstitious until the first rollback at seven in the evening, and then it sounds obvious.<\/p>\n<p>Feature flags separate release from launch. Deploying code that is switched off removes most of the drama from a risky change.<\/p>\n<p>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.<\/p>\n<p><a href=\"https:\/\/pms.co.ke\" target=\"_blank\" rel=\"noopener\">software product engineering in Kenya<\/a> should keep migrations backward compatible, so the previous version still runs while a rollback is in progress.<\/p>\n<p>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.<\/p>\n<p>Nominate one person on call after a release, with a written rollback step and the number of whoever owns the integration.<\/p>\n<p><a href=\"https:\/\/estateadmin.co.ke\" target=\"_blank\" rel=\"noopener\">software product engineering in Kenya<\/a> 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.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Documentation_a_New_Engineer_Uses_in_Week_One\"><\/span>Documentation a New Engineer Uses in Week One<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Documentation fails when it is a separate activity nobody owns. It works when it sits beside the code and changes with it.<\/p>\n<p>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.<\/p>\n<p>Write short decision records. One page per choice, with the context, the options considered and the reason, dated and signed.<\/p>\n<p><a href=\"https:\/\/churchesadmin.com\" target=\"_blank\" rel=\"noopener\">software product engineering in Kenya<\/a> should set an onboarding target: a new developer ships a small change in the first week, with review.<\/p>\n<p>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.<\/p>\n<p>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.<\/p>\n<p>Generate API documentation from the code, and let <a href=\"https:\/\/vega.co.ke\" target=\"_blank\" rel=\"noopener\">software product engineering in Kenya<\/a> review it against a real integration. A handwritten reference drifts within a month.<\/p>\n<p>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.<\/p>\n<p>Treat documentation as part of the definition of done, and <a href=\"https:\/\/dereva.co.ke\" target=\"_blank\" rel=\"noopener\">software product engineering in Kenya<\/a> should refuse a release that leaves the runbook stale.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Taking_Over_a_Product_From_a_Departing_Agency\"><\/span>Taking Over a Product From a Departing Agency<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Handovers fail when the commercial relationship ends before the technical one. Plan the handover while everyone is still polite.<\/p>\n<p>Ask for repository access, infrastructure credentials, deployment scripts, third-party account ownership and the current architecture.<\/p>\n<p><a href=\"https:\/\/jaat.co.ke\" target=\"_blank\" rel=\"noopener\">software product engineering in Kenya<\/a> should insist on a code walkthrough with the receiving team, not a zip file and a wish of luck.<\/p>\n<p>Run one small change end to end during the overlap. It proves the pipeline works and exposes the manual step nobody documented.<\/p>\n<p>Check what is registered in whose name: domains, cloud accounts, SMS shortcodes, payment accounts, certificates.<\/p>\n<p>Keep a paid support window of thirty days after handover. Questions arrive in week three, when the new team first touches the billing logic.<\/p>\n<p>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.<\/p>\n<p><a href=\"https:\/\/wito.co.ke\" target=\"_blank\" rel=\"noopener\">software product engineering in Kenya<\/a> should hand over a written risk list, including the parts of the product that nobody currently understands.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Source_Code_IP_and_the_Accounts_in_Whose_Name\"><\/span>Source Code, IP and the Accounts in Whose Name<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>The contract should state that the client owns the source code, the designs and the data. Anything less is a rental with extra steps.<\/p>\n<p>Contractors must sign an assignment of intellectual property. A contributor who never assigned rights can complicate a sale, an audit or an investment round.<\/p>\n<p><a href=\"https:\/\/awasam.co.ke\" target=\"_blank\" rel=\"noopener\">software product engineering in Kenya<\/a> should list third-party licences in a file in the repository, with the licence type for each dependency.<\/p>\n<p>Escrow is worth considering for critical systems. Release conditions should be specific: insolvency, a missed support level, or a defined notice period.<\/p>\n<p>Check the deposit is usable. Source code without build instructions and credentials is a filing cabinet, not an escrow.<\/p>\n<p>Ask for the escrow agent&#8217;s release process in writing. An escrow nobody can trigger is a storage fee with a legal cover attached to it.<\/p>\n<p>Keep a copy of the repository in an account the company controls, and let <a href=\"https:\/\/saseni.co.ke\" target=\"_blank\" rel=\"noopener\">software product engineering in Kenya<\/a> verify that the export actually builds.<\/p>\n<p>Review ownership at every renewal. Accounts migrate quietly when staff change, and nobody notices until a password reset fails during a go-live.<\/p>\n<p><a href=\"https:\/\/prim.co.ke\" target=\"_blank\" rel=\"noopener\">software product engineering in Kenya<\/a> should put the ownership schedule in the contract appendix, with a named company officer responsible for each asset.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Payments_Messaging_and_the_M-PESA_Failure_Paths\"><\/span>Payments, Messaging and the M-PESA Failure Paths<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>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.<\/p>\n<p>Make every callback idempotent. The same transaction reference must be processed once however many times it is delivered.<\/p>\n<p><a href=\"https:\/\/rentaldesk.co.ke\" target=\"_blank\" rel=\"noopener\">software product engineering in Kenya<\/a> should reconcile against the provider&#8217;s statement daily, not only against its own ledger.<\/p>\n<p>Handle the timeout path explicitly. A request that times out may have succeeded, so query before retrying, and log the query.<\/p>\n<p>Distinguish paybill and till flows in the data model, as <a href=\"https:\/\/fama.co.ke\" target=\"_blank\" rel=\"noopener\">software product engineering in Kenya<\/a> should from the first sprint. They generate different references, and merging them creates reconciliation work that never ends.<\/p>\n<p>Test failures deliberately: insufficient funds, cancelled prompts, wrong amounts, duplicate submissions, a callback arriving after midnight.<\/p>\n<p>Keep the provider&#8217;s test credentials current and refresh them before every integration change, not during the change window at eleven at night.<\/p>\n<p>SMS is not a reliable channel. Treat delivery reports as advisory and never let product state depend on a message arriving.<\/p>\n<p>Keep a reconciliation report a finance officer can read without a developer beside them, and have <a href=\"https:\/\/spacekits.co.ke\" target=\"_blank\" rel=\"noopener\">software product engineering in Kenya<\/a> test it against a week of real traffic.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Performance_Budgets_for_Kenyan_Networks\"><\/span>Performance Budgets for Kenyan Networks<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>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.<\/p>\n<p>Set the budget before building: first meaningful paint under five seconds on a throttled 3G connection, measured on a real device.<\/p>\n<p>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.<\/p>\n<p><a href=\"https:\/\/zamacore.com\">software product engineering in Kenya<\/a> should measure from a location your users occupy, on the network they actually buy.<\/p>\n<p>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.<\/p>\n<p>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.<\/p>\n<p>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.<\/p>\n<p>Put the budget in the acceptance criteria, so <a href=\"https:\/\/mystayorbit.com\" target=\"_blank\" rel=\"noopener\">software product engineering in Kenya<\/a> treats a missed target as a defect rather than a later complaint.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Data_Protection_and_the_ODPC_Register\"><\/span>Data Protection and the ODPC Register<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>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.<\/p>\n<p>Collect less, and let <a href=\"https:\/\/dexa.co.ke\" target=\"_blank\" rel=\"noopener\">software product engineering in Kenya<\/a> challenge every field on the form. A field you never capture cannot leak, be retained wrongly or be explained in a breach.<\/p>\n<p><a href=\"https:\/\/zama.co.ke\" target=\"_blank\" rel=\"noopener\">software product engineering in Kenya<\/a> should define retention per data type and enforce it with a scheduled job, not a policy page.<\/p>\n<p>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.<\/p>\n<p>Breach notification has a seventy-two hour expectation. Detection, escalation and a template must exist before the incident, not after it.<\/p>\n<p>Draft the notification template while nothing is wrong. Writing it at midnight with a regulator&#8217;s clock running produces sentences that create more problems than they close.<\/p>\n<p>Cross-border storage needs a lawful basis. Know which region holds personal data and who can reach it.<\/p>\n<p>Access should be role-based and reviewed quarterly. A support account with full visibility is a finding, not a convenience.<\/p>\n<p>Keep a data inventory that names the owner of each table holding personal data, and let <a href=\"https:\/\/pawa.co.ke\" target=\"_blank\" rel=\"noopener\">software product engineering in Kenya<\/a> review it before an audit rather than during one.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Building_the_In-House_Team_That_Inherits_the_Product\"><\/span>Building the In-House Team That Inherits the Product<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>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.<\/p>\n<p>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.<\/p>\n<p>Hire for judgement, not only framework knowledge, and let <a href=\"https:\/\/pms.co.ke\" target=\"_blank\" rel=\"noopener\">software product engineering in Kenya<\/a> set the interview task. Frameworks change; reasoning about a data model does not.<\/p>\n<p><a href=\"https:\/\/estateadmin.co.ke\" target=\"_blank\" rel=\"noopener\">software product engineering in Kenya<\/a> should give that first hire a clear product owner and a written backlog, or the role becomes firefighting within a quarter.<\/p>\n<p>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.<\/p>\n<p>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.<\/p>\n<p>Set a code review standard and keep it. A team without review learns quickly and learns the wrong things with great confidence.<\/p>\n<p>Keep one external reviewer for architecture decisions. A second opinion twice a year is cheaper than the rewrite it prevents.<\/p>\n<p>Plan the second hire before the first one resigns, and let <a href=\"https:\/\/churchesadmin.com\" target=\"_blank\" rel=\"noopener\">software product engineering in Kenya<\/a> interview for the gap rather than the replacement.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Support_Warranties_and_the_Defect_That_Returns\"><\/span>Support, Warranties and the Defect That Returns<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>Support is a product feature. A bug that returns three times teaches users to stop reporting, and the next complaint arrives as a cancellation.<\/p>\n<p>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.<\/p>\n<p><a href=\"https:\/\/vega.co.ke\" target=\"_blank\" rel=\"noopener\">software product engineering in Kenya<\/a> should include a warranty period after launch, typically thirty to ninety days, covering defects in delivered scope.<\/p>\n<p>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.<\/p>\n<p>Root-cause every repeat defect. The third occurrence is a design problem, and no amount of patching fixes a design problem.<\/p>\n<p>Report support volume monthly. The trend shows whether quality is improving faster than the product grows, which is the only comparison that matters.<\/p>\n<p>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.<\/p>\n<p>Separate defects from change requests in the same queue, or the warranty will quietly pay for new features.<\/p>\n<p><a href=\"https:\/\/dereva.co.ke\" target=\"_blank\" rel=\"noopener\">software product engineering in Kenya<\/a> should publish the response times achieved, not only the targets, so the renewal conversation rests on evidence.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Total_Cost_of_Ownership_Across_Five_Years\"><\/span>Total Cost of Ownership Across Five Years<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>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.<\/p>\n<p>Plan for fifteen to twenty per cent of the build cost each year in maintenance, as <a href=\"https:\/\/jaat.co.ke\" target=\"_blank\" rel=\"noopener\">software product engineering in Kenya<\/a> should state in the proposal. Products that skip it accumulate the debt that forces a rewrite.<\/p>\n<p><a href=\"https:\/\/wito.co.ke\" target=\"_blank\" rel=\"noopener\">software product engineering in Kenya<\/a> should present a five-year model with the assumptions written down, including headcount, hosting growth and integration changes.<\/p>\n<p>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.<\/p>\n<p>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.<\/p>\n<p>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.<\/p>\n<p>Include the cost of the exit. Migration, data extraction and a parallel run belong in the model if the vendor relationship sours.<\/p>\n<p>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.<\/p>\n<p>Review the model annually against actual spend, and let <a href=\"https:\/\/awasam.co.ke\" target=\"_blank\" rel=\"noopener\">software product engineering in Kenya<\/a> explain every variance above ten per cent. A forecast never tested is a rumour.<\/p>\n<h2><span class=\"ez-toc-section\" id=\"Keeping_the_Product_Maintainable_in_Year_Three\"><\/span>Keeping the Product Maintainable in Year Three<span class=\"ez-toc-section-end\"><\/span><\/h2>\n<p>By year three the original team has usually moved on. What remains is the code, the tests and whatever the documentation says.<\/p>\n<p>Upgrade dependencies on a schedule rather than in a panic. A quarterly afternoon is cheaper than a forced migration under a security advisory.<\/p>\n<p>Keep coverage on the paths that matter, even if total coverage is modest. Percentages flatter; critical-path tests protect.<\/p>\n<p><a href=\"https:\/\/saseni.co.ke\" target=\"_blank\" rel=\"noopener\">software product engineering in Kenya<\/a> should maintain a debt register with an owner and a rough cost, reviewed each quarter.<\/p>\n<p>Avoid single-person knowledge. Two people should be able to deploy, and two should understand the billing rules well enough to change them.<\/p>\n<p>Onboarding speed is the best health metric. If a competent developer needs three weeks for a first change, the product is drifting.<\/p>\n<p>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.<\/p>\n<p>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.<\/p>\n<p>Schedule a maintainability review every year, with <a href=\"https:\/\/prim.co.ke\" target=\"_blank\" rel=\"noopener\">software product engineering in Kenya<\/a> asking the same questions a buyer would ask during due diligence.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>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&#8230;<\/p>\n","protected":false},"author":5,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[293,3,11,287,10,9],"tags":[],"class_list":["post-1072","post","type-post","status-publish","format-standard","hentry","category-academic-support","category-ai-automation","category-business-systems","category-product-guides","category-support-service","category-website-development"],"_links":{"self":[{"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/posts\/1072","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/comments?post=1072"}],"version-history":[{"count":1,"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/posts\/1072\/revisions"}],"predecessor-version":[{"id":1075,"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/posts\/1072\/revisions\/1075"}],"wp:attachment":[{"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/media?parent=1072"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/categories?post=1072"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/zamacore.com\/blog\/wp-json\/wp\/v2\/tags?post=1072"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}