Skip to main content

5 min read

Planning

Back to Documentation Intro Contents

info

See Planning and Design for more information on the planning phase of the SDLC.

Define the Problem and Requirements​

Before writing any code or choosing a tech stack, clearly define what you are building and why. Even for solo or personal projects, a lightweight requirements process prevents scope creep and wasted effort.

Problem Statement​

Write a brief or problem statement. This does not need to be a formal document - a single page is sufficient. Answer these questions:

  • Who is the target user?
  • What problem does this solve for them?
  • What does success look like (how will you know the project is "done")?

User Stories​

Capture the key functionality as lightweight . For example:

  • As a user, I want to sign up with my email so that I can access the app.
  • As a user, I want to view my dashboard so that I can see my recent activity.
Why Bother for Solo Projects?

Even for personal projects, writing a one-page PRD and a handful of user stories saves hours of rework. It forces you to think through what you actually need before you get lost in implementation details.

Example PRD​

# Product Requirements Document (PRD)
## Project: Smart Travel Receipt Scanner (STRS)
**Version:** 1.0  
**Owner:**  
**Last Updated:**  
---

## 1. Overview

### 1.1 Summary
<!-- Brief description of what the feature does and why it matters. -->
The Smart Travel Receipt Scanner (STRS) enables travellers to capture a photo of a receipt and automatically extract key expense data using OCR. It reduces manual entry, speeds up expense submission, and improves accuracy by integrating directly into the existing Travel Manager workflow.

### 1.2 Problem Statement
<!-- What problem users face today and why current solutions fall short. -->
Travellers currently spend too much time manually entering receipt details, leading to errors, delays, and inconsistent data. Existing OCR tools are generic, often inaccurate for travel receipts, and do not integrate with the company’s expense system — resulting in frustration for travellers and inefficiencies for finance teams.

### 1.3 Goals
- Reduce manual expense entry  
- Improve OCR accuracy  
- Speed up expense submission

### 1.4 Success Metrics
| Metric | Target |
|--------|--------|
| OCR accuracy | ≥ 95% |
| Auto‑categorization | ≥ 80% |
| Time to log expense | ≤ 10 seconds |
---

## 2. Scope
### 2.1 In Scope
- Receipt capture (camera + upload)  
- OCR extraction  
- Auto‑categorization  
- Duplicate detection  
- Sync to expense system  
### 2.2 Out of Scope
- Multi‑page invoices  
- Desktop upload  
- Currency conversion logic  
---

## 3. User Stories
- *As a traveller, I want to scan a receipt so I can log an expense quickly.*  
- *As a traveller, I want fields auto‑filled so I don’t have to type them.*  
- *As a finance approver, I want consistent data so reviews are faster.*
---

## 4. Functional Requirements
### 4.1 Capture & Upload
- Support camera capture and gallery upload  
- Accept JPG, PNG, HEIC  
### 4.2 OCR & Categorization
- Extract merchant, date, total, tax, currency  
- Provide confidence scores  
- Auto‑categorize receipts  
### 4.3 Sync & Storage
- Store image + parsed data  
- Sync within 5 seconds  
- Offline queueing  
---

## 5. Non‑Functional Requirements
- OCR processing ≤ 3 seconds  
- Encrypted at rest and in transit  
- 99.5% service uptime  
- Accessible UI (screen readers, contrast)
---

## 6. UX & Design
- Simple capture → review → save flow  
- Link to wireframes/prototypes  
---

## 7. Dependencies
- OCR service  
- Categorization API  
- Expense sync service  
---

## 8. Risks
| Risk | Mitigation |
|------|------------|
| Low OCR accuracy | Exclude unsupported formats; allow easy edits |
| Poor lighting | Auto‑enhancement + retake guidance |
---

## 9. Open Questions
- Should PDF uploads be supported  
- Should categorization learn from user corrections

Prioritise with MoSCoW​

Use to scope your :

  • Must have - the project is unusable without these
  • Should have - important but the project works without them
  • Could have - nice-to-have enhancements
  • Won't have (this time) - explicitly out of scope for now

This keeps you focused on delivering a working product rather than an ever-expanding feature list.

Assess Feasibility and Risk​

Before committing to a build, do a quick feasibility check:

  • Technical feasibility - Do you have the skills (or can you learn them quickly enough)? Are the required APIs/services available?
  • Cost feasibility - What will hosting, databases, and third-party services cost? Is there a free tier that works for your scale?
  • Time feasibility - How long will this realistically take? Be honest about your available hours per week.

Identify the top 2-3 risks and think about mitigations. Common risks for solo projects include: underestimating complexity, choosing unfamiliar technology, and depending on unreliable third-party APIs.

Solo Dev Pitfall: Over-Scoping

The most common mistake for solo developers is trying to build too much at once. Scope aggressively to the MVP - you can always add features later. A shipped MVP beats an unfinished "full product" every time.

Decide on Architecture​

If you already have an architecture in mind, jump to Plan the UI

AI Assisted Planning

Before initiating a project, use the plan generated in the planning phase to generate a plan for the project, via a prompt to the AI. For the prompt, template, see the "Project Initiation" section of my Obsidian note on AI Prompts here.

If it is just a web app to be built, consider the below Front End, Back End and Database Architecture options. If it also needs to be a mobile app, consider the below Mobile Architecture options.

Review the below architecture considerations against the AI output and verify it makes sense

Record Your Decisions

Create an for every significant architecture choice. A simple markdown file in a /docs/decisions/ folder that records what you chose, what alternatives you considered, and why pays dividends when you revisit the project in 6 months. See adr.github.io for a lightweight template.

Monolith First

For solo developers, a is almost always the right starting architecture. It reduces operational complexity and lets you move fast. Avoid unless you have a genuine scaling bottleneck that demands it.

Front End Architecture​

  • Considerations:
    • or not?
    • (Server side rendering) or (Static site generation) required?
  • Options:
    • CRA (Create React App)
    • Vite.js
    • Next.js
  • Recommendations (from Robin Wieruch):
    • Vite.js for client-side rendered React applications
    • Next.js server-side rendered React applications
    • Astro for static-side generated React applications

Back End Architecture​

Database​

  • Considerations:
    • Should it be or ?
    • How am I going to query my database? Via a client? By the CLI?
    • Consider TypeORM or Prisma for type safe access to your database
  • Options:
    • Sequel DBs:
      • Xata
      • MySQL
      • Postgress (recommended)
    • No Sequel DBs:
      • Firebase
      • MongoDB
      • PlanetScale
      • Supebase

References

  1. Which Is Better? SQL vs NoSQL
  2. How To Choose a Database for your App
  3. Build a TypeScript API with Express, RapidAPI, and Xata

Hosting​

  • Considerations:
    • How much will hosting the site cost?
    • What features does the hosting provide?
    • What access protection does the hosting service offer for limiting access to your app or database?
  • Options:
    • Netlify (free)
    • Vercel
    • Heroku (cheap)
    • DigitalOcean (cheap)
    • Amazon RDS (expensive)
    • BlueHost (basic)

Mobile Architecture​

Plan the UI​

info

See Planning and Design - UI/UX Design for more information on design systems, user research, and prototyping.

Wireframes and Prototyping​

Before jumping into colours and fonts, sketch out the structure and flow of your application using . Start low-fidelity (pen and paper or a simple tool) to validate the user flow before investing in high-fidelity mockups.

  • Figma - Industry-standard design tool (free tier available)
  • Excalidraw - Quick, hand-drawn-style wireframing
  • Balsamiq - Dedicated wireframing tool
Validate Before You Build

Show your wireframes to at least one other person before coding. Even five minutes of feedback can surface navigation issues or missing flows that would be expensive to fix later.

Inspiration​

For inspiration for projects, check out the following resources:

Colour Selection​

Fonts​

Design Guides​

Web Forms​