MVP Scope in Kenya: 12 Decisions Before You Request a Quote

A useful minimum viable product is the smallest dependable release that lets a defined user complete a valuable end-to-end task and gives the business evidence for the next decision. It is not every idea compressed into a tight deadline, and it is not an unfinished system that moves security, data or operational problems to the user.

For a Kenyan or East African business requesting a custom-software quote, the quality of the first scope changes the quality of the estimate. A developer can price a clear user journey, known integrations and testable acceptance criteria more responsibly than a list that says “dashboard, app, payments and reports”. This guide helps founders, operations leads and programme teams prepare that first brief without pretending every detail is already known.

What “minimum” and “viable” should mean

Minimum means deliberately excluding lower-priority work from the first release. Viable means the included journey is usable, secure enough for its data and risk, supportable, testable and capable of producing the learning or operational value the business needs. A demo can prove an interaction. A prototype can test an assumption. An MVP intended for real users needs the operating controls appropriate to real use.

That distinction prevents two expensive mistakes. The first is treating every stakeholder request as essential and producing a first phase too large to learn from quickly. The second is cutting invisible quality work—permissions, validation, backups, monitoring or accessibility—while leaving all visible features in scope. A smaller complete journey is usually safer than many incomplete ones.

12 decisions an MVP scope should contain

1. The business decision the release must support

Write the decision you expect to make after launch. Are you testing whether customers complete self-service booking, whether field officers can submit valid records offline, or whether managers act on a shared exception queue? “Build an app” is an output; it does not explain what the organisation needs to learn or improve.

Name a release owner who can prioritise, accept work and answer operational questions. When nobody has decision authority, small scope choices wait for meetings and the backlog expands by default.

2. The primary user and their context

Describe one primary user group with enough detail to design for reality: their role, device, connectivity, working environment, frequency of use and existing process. “Customers” or “staff” is too broad when different people have different permissions and goals.

Include secondary users only when the first journey cannot operate without them. A booking MVP may need a customer and one administrator; it may not yet need separate finance, marketing and regional-manager dashboards.

3. One complete end-to-end journey

Map the trigger, the steps, the completion state and the confirmation. For example: an authorised staff member receives a request, validates it, assigns it, updates the outcome and closes it while the requester receives a clear status. Screens are not the scope; the complete business journey is.

Mark the unhappy paths as well. What happens when required data is missing, a user lacks permission, an integration times out or the same request arrives twice? A happy-path-only build transfers the difficult work back to staff at launch.

4. Must-have, later and explicitly excluded work

Use a visible priority method. Must-have items are required for the chosen journey to work safely. Later items are valuable but do not prevent first release. Exclusions remove ambiguity: multi-branch operation, native mobile apps, advanced reports, bulk migration or a particular provider integration may be outside phase one.

Record the reason for each must-have. If an item has no user need, operational dependency, risk control or learning goal behind it, it may be a preference rather than a first-release requirement.

5. Data inputs, ownership and retention

List the records the MVP creates, reads, updates, imports and exports. For each important field, name the source, owner, required validation and who may see it. Use representative synthetic data during early work instead of casually sharing production customer information.

Define what can be corrected or deleted, what must be retained, and which system remains authoritative when data already exists elsewhere. If the MVP depends on an external system, use the API integration planning guide to specify identifiers, failures and reconciliation.

6. Roles, permissions and approvals

Name the roles, not individual employees. Write what each role may view, create, change, approve, export and administer. Separate ordinary work from privileged administration and record important state changes where accountability matters.

A small first release does not require one shared administrator login. Named access and least privilege make support, audit and later handover easier. If approval is part of the process, define who decides, what evidence they see and what happens when they reject or do not respond.

7. Integrations and manual boundaries

Confirm whether an API, webhook, file import, email notification or payment provider is actually available for the required operation. Record account ownership, sandbox access, rate or subscription constraints, expected delay and failure behaviour. Do not price an integration from a logo on a requirements slide.

A controlled manual step can be a valid MVP boundary when volume is low and the risk is understood. Mark it honestly, measure the effort and decide what evidence would justify automating it later.

8. Platform, device and connectivity assumptions

Choose web, mobile or another delivery surface from the user journey. Define supported browsers, screen sizes, device capabilities, installation or app-store needs and what must work with weak or absent connectivity. The website versus web app guide and mobile architecture comparison help separate platform choice from feature wish lists.

Offline is not a checkbox. State which records can be viewed or created offline, how they synchronize, what happens during conflict and how users see that work is pending.

9. Non-functional acceptance criteria

Define the quality conditions that protect the journey: accessibility, performance on representative devices, security controls, backup and recovery, availability expectations, audit history and privacy handling. Use measurable statements where possible, such as the response target for an ordinary screen or the time within which an agreed backup must be restorable.

For a public website or web application, agree an accessibility baseline and test keyboard, focus, form errors, contrast, touch targets and screen-reader structure. “We will add accessibility later” can make the first architecture and component choices harder to repair.

10. Success measures and learning plan

Choose a small set of measures tied to the business decision. Examples include completion rate, time to complete, proportion of records needing correction, support requests, adoption by the target group or time saved from a verified baseline. Avoid vanity metrics that cannot change a decision.

Define the observation period, who reviews results and the threshold for continue, change or stop. Instrument only what is necessary, respect consent and data minimisation, and make sure a metric has a clear definition before placing it on a dashboard.

11. Acceptance, launch and support responsibilities

Turn must-have requirements into scenarios that a named owner can accept. Include valid use, invalid input, permission boundaries, duplicate actions, failed integrations and recovery. Decide which defects block launch and which can enter a visible improvement backlog.

Plan the launch route: data preparation, training, communications, staged rollout, monitoring, rollback limits and the person handling support. A production date is not the end of the MVP; it begins the period in which the team learns from real use.

12. Ownership, budget boundary and next-phase rules

State who will control the repository, domain, hosting, cloud accounts, app-store accounts, data, design files, documentation and analytics. Agree what the first quote includes, which third-party costs are separate, how changes are approved and what handover evidence is required. The software handover checklist provides a fuller ownership test.

Do not promise phase two before phase one produces evidence. Keep a later backlog, then re-prioritise it after user feedback and operating data. This preserves the purpose of an MVP: learning enough to make a better next investment.

A one-page MVP brief structure

• Problem: the current process, user pain and verified business cost or risk.
• Primary user: role, context, device and access conditions.
• Outcome: the complete task the user can finish in phase one.
• Must-have scope: the smallest set of journeys and controls required for viability.
• Later and excluded: useful ideas that are not part of this estimate.
• Data and integrations: records, sources, ownership, providers and failure boundaries.
• Quality bar: accessibility, security, performance, backup and support expectations.
• Acceptance: test scenarios, launch owner and decision authority.
• Success: baseline, measures, review period and the next decision.
• Ownership: accounts, source, documentation, operating responsibility and handover.

What a responsible estimate should clarify

A proposal should connect cost and time to assumptions: number of user journeys, roles, integrations, migration volume, platforms, design work, quality controls, environments, launch support and maintenance. It should identify exclusions, third-party dependencies and decisions that could change the estimate. For broader budget drivers, use the custom software cost guide for Kenya.

Be cautious with a fixed figure produced before the supplier understands the data, integrations and acceptance boundary. A discovery phase, prototype or paid technical review may be the responsible first scope when material unknowns remain. The goal is not to make the brief look certain; it is to make known decisions explicit and unknowns manageable.

Frequently asked questions