Project Planning (SDLC Workshop)

When to use

Activate whenever:

• •A team is deciding what to build or filling out their PRD
• •Generating or scaffolding a base MVP
• •Planning features or breaking work into tasks
• •The user asks Cursor to build, create, or implement something for the workshop

Hard constraints

These are non-negotiable for this workshop. If a user's request would violate one, explain why and offer a frontend-only alternative.

No backends

• •No databases — no SQLite, no PostgreSQL, no Firebase, no IndexedDB
• •No servers — no Express, no Flask, no custom API server, no API routes
• •No authentication — no login, no OAuth, no JWT, no user accounts
• •No external APIs — no fetch to third-party services, no API keys

Use React

• •All projects must use React — scaffold with npx create-react-app or Vite (npm create vite@latest -- --template react)
• •Vite is preferred for speed — it starts faster and hot reloads instantly
• •Run with npm run dev (Vite) or npm start (CRA)
• •Keep dependencies minimal — React itself is enough for these projects. Don't add extra libraries unless there's a clear reason.

Stay small

• •The base MVP must be buildable by one person in 10 minutes
• •Keep the component count low — a handful of components, not a complex tree
• •No routing libraries needed — these are single-page apps
• •No state management libraries — React's built-in useState and useRef are plenty

Scale down ambitious ideas

If a user proposes something too complex, don't just say no — suggest a simpler version that captures the same spirit. Keep the fun, lose the complexity.

The pattern: take the core interaction that makes it fun (clicking, competing, creating) and strip away everything that needs a server, accounts, or real-time sync.

What to do instead of a backend

When a feature "wants" a backend, use these frontend patterns:

Data that would come from a database

Hardcode it as a JavaScript array or object in a separate file or at the top of a component:

// data.js — stub data, no database needed
export const TRIVIA_QUESTIONS = [
  { question: "What is the capital of France?", choices: ["London", "Paris", "Berlin", "Madrid"], answer: 1 },
  { question: "What year did the moon landing happen?", choices: ["1965", "1969", "1971", "1973"], answer: 1 },
];

Or put it in a JSON file and import it:

import questions from './data/questions.json';

State that would be stored server-side

Use React state for in-session data, or localStorage if it should survive a page refresh:

const [score, setScore] = useState(0);
const [highScore, setHighScore] = useState(
  () => Number(localStorage.getItem('highScore')) || 0
);

Randomness or dynamic content

Use Math.random(), shuffle arrays, or rotate through hardcoded lists. No server needed.

User input

Use React event handlers and state. That's the whole "backend."

Parallelizable features

Every project must support 5 people working independently at the same time. When helping a team plan:

1. •The base MVP should be minimal — just enough to run and show something. Leave all the interesting parts as features for teammates.
2. •Each feature should be its own component — one person per component file means no merge conflicts.
3. •Features should be additive — adding a <Scoreboard /> component should not require changing how the game loop works in App.jsx.

Good feature pattern

Each person creates a new component in its own file:

• •Scoreboard.jsx — displays and tracks scores
• •Settings.jsx — difficulty slider, theme picker
• •SoundEffects.jsx — plays sounds on game events
• •Timer.jsx — countdown or elapsed time display
• •Animations.jsx — confetti on win, shake on miss

Bad feature pattern

Everyone editing App.jsx or the same shared component — this causes merge conflicts and blocks teammates.

When generating code

• •Use React with functional components and hooks (useState, useEffect, useRef)
• •Keep it in the src/ folder with a clean component structure
• •Use CSS modules, a single App.css, or inline styles — whatever is simplest
• •Make it visually presentable — use modern CSS, clean layout, readable fonts
• •Include basic responsive design so it looks decent on a projected screen
• •Add comments explaining what each section does (these are beginners)
• •Keep component files focused — one component per file

Tone

Remember the audience: these are sales, field engineering, and account management professionals, not developers. When explaining technical decisions:

• •Keep language simple and direct
• •Avoid jargon unless you immediately explain it
• •Frame choices in terms of "this keeps it simple" rather than technical tradeoffs