Planning an app: requirements, user stories, MVP and data

Most failed apps fail before any code is written: nobody agreed what the app must do, the scope kept growing, or it solved a problem nobody had. An hour of planning saves weeks of rework. We'll plan a real example: "Duka Connect", an app for small shops to record sales and stock and let regular customers order.

1. The problem statement

One or two sentences everyone agrees on:

Small shop owners in Kenyan towns lose money because they don't know what's selling, what's running out, or which customers owe them. Duka Connect lets them record sales, track stock and credit, and take orders from regular customers on their phone.

2. Users and their goals

3. User stories

User stories describe features from the user's side: As a [user], I want [action] so that [benefit].

• As an attendant, I want to record a sale by tapping products, so that sales are quick even when the shop is busy.
• As an owner, I want an alert when stock is low, so that I reorder before running out.
• As an owner, I want to record credit sales and see who owes what, so that I can follow up.
• As a customer, I want to pay by M-Pesa in the app, so that I don't need cash.

Each story gets acceptance criteria: "Given stock of 3 and a low-stock level of 5, when the owner opens the app, then a low-stock badge shows the product."

4. MoSCoW: what goes in version 1

The MVP (minimum viable product) is only the Must have column. Launch it, get real users, then build the rest based on what they actually use.

5. Screens and flow

List screens and how users move between them (draw boxes and arrows on paper or in Figma):

Login → Home (today's total, low stock, quick actions)
         ├── Sell → choose products → confirm → receipt
         ├── Stock → product list → add / edit product
         ├── Debts → customer → record payment
         └── Settings

6. The data model

What information must be stored, and how it connects:

Practise designing and querying tables like these in the SQL subject. Getting the data model right early makes everything else easier.

7. Non-functional requirements

Not features, but qualities the app must have:

• Works on cheap Android phones (2 GB RAM, Android 8+).
• Recording a sale works offline and syncs later.
• Each screen loads in under 2 seconds on 3G.
• Data is backed up daily; personal data handled under the Data Protection Act.
• Available in English and Kiswahili.

8. Estimate and plan the work

Break the MVP into tasks of half a day to two days each, estimate them, and add 30% buffer for the unexpected. Plan in 1 to 2 week sprints, each ending with something the client can try.

Planning template

App name:
Problem statement:
Users and goals:
User stories (with acceptance criteria):
MVP (Must have):
Later (Should / Could):
Screens and flow:
Data model:
Non-functional requirements:
Tech stack:
Timeline and budget:

Why planning saves projects

Many app projects fail not because of bad code but because nobody agreed what to build: features keep growing, budgets run out, and the client is unhappy with something different from what they imagined. A short, clear plan aligns everyone, makes estimates realistic and helps you say "that's for version 2" politely. Product managers, freelance developers, agency teams and startup founders all use these planning tools.

Discovery questions to ask the client

Record the answers in a shared document and send a summary for the client to confirm.

Writing good user stories

As a parent, I want to see my child's fee balance, so that I can pay the right amount.
   Acceptance criteria:
   - Balance shows the latest payment within 5 minutes of the M-Pesa confirmation
   - Shows the date and receipt of the last payment
   - Works on a 4.7-inch screen on a slow connection

Acceptance criteria describe exactly when a story is "done", which prevents arguments later.

An MVP example: a school fees app

Launching the MVP gets real feedback quickly; later versions add features people actually ask for.

Data model example

Parent (id, name, phone, email)
Student (id, admission_no, name, class, parent_id → Parent)
FeeItem (id, term, class, description, amount)
Invoice (id, student_id → Student, term, total, balance)
Payment (id, invoice_id → Invoice, amount, mpesa_receipt UNIQUE, paid_at, status)

Drawing the data model early reveals questions: Can one parent have several children? Can a payment cover two terms? What happens with overpayments?

Screen list and flows

Splash → Login (phone) → Enter OTP → Home (children list)
Home → Child details (balance, history) → Pay → Enter amount → STK prompt → Waiting → Success/Failure
Home → Profile → Settings / Logout

Sketch each screen on paper first, then create clickable wireframes (Figma) for the client to try before development.

Estimating realistically

1. Break features into tasks small enough to estimate (half a day to two days each).
2. Estimate each task, including testing and fixes.
3. Add time for: setup, design, integrations (payments often take longer than expected), deployment, store review, project communication.
4. Add a buffer (20–30%) for unknowns.
5. Group tasks into milestones with deliverables the client can see.

Managing scope changes

Change is normal; uncontrolled change is the problem.

• Keep a change log: each new request gets a description, estimate and decision.
• Explain the impact: "Adding chat adds about two weeks and KSh X. We can add it after launch."
• Get written approval before starting extra work.

Planning tools

Practice

1. Write 10 user stories with acceptance criteria for a salon booking app.
2. Sort them into MoSCoW and define the MVP.
3. Draw the data model and the main screen flow.
4. Estimate the MVP tasks, add a 25% buffer, and group them into milestones.
5. Write a one-page project summary a client could approve.