Skip to main content

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.

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

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.

  1. Ask AI to recommend an architecture with justification - see the Obsidian note on AI Prompts here
  2. 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​

Estimation​

Before starting development, estimate the effort involved so you can set realistic expectations and deadlines for yourself.

T-Shirt Sizing​

Use to get a rough sense of effort for each feature or user story:

SizeMeaningExample
SA few hours of workAdd a static page, tweak styling
M1-2 days of workBuild a form with validation, integrate a simple API
L3-5 days of workAuthentication flow, complex data dashboard
XL1-2 weeks of workFull CRUD feature with backend, real-time functionality
Timebox Your Discovery

Do not spend weeks in planning. Timebox your planning phase (1-2 days for a solo project is typically sufficient) and get feedback through working software instead. The goal is to plan enough to start building with confidence, not to predict every detail upfront.