Vertical Slice Development — Solo Dev Strategy

Build one complete feature at a time (model → endpoint → frontend component) rather than separating backend and frontend phases. The correct approach for solo developers with a known spec.

Why / When to Use

When you are one developer building a full-stack product with a known spec — and you want to maintain momentum across a multi-week project without motivation collapse or backend/frontend drift.

Core Concept

Three approaches compared:

Vertical slice flow per feature:

Model → Migration → Endpoint → Frontend component

Each slice delivers something visible and testable end-to-end in 1–2 weeks.

Why all-backend-first fails for solo dev

With a team, all-backend-first makes sense because backend and frontend teams work in parallel — it’s just a coordination artifact.

One developer means sequential work:

All backend first:
You → backend → backend → backend → [N weeks] → frontend

Vertical slices:
You → backend+frontend → backend+frontend → backend+frontend
     (feature A)          (feature B)         (feature C)

After N weeks of invisible backend work, context is lost, motivation collapses, and the frontend inevitably reveals API shape gaps that require backend rework anyway.

The one valid argument for all-backend-first — and how to handle it

“If the data model is wrong, it’s cheaper to fix before the frontend is built on top of it.”

True — but the solution is not 13 weeks of delay. It is hardening the data model early before building either side of a feature:

• Phase 0–1: Foundation + Auth → locks the core data model (User, JWT, tenancy) before any feature-specific code
• Phase 2: Shell (pure frontend, zero data dependency) → safe while models are still settling
• Phase 3+: Feature by feature → model locked per feature before frontend starts

Key Options / Variants

Phase structure for a solo Django + Next.js project:

Phase 0–1  Foundation + Auth
           → CustomUser, JWT, tenant models (data model hardened here)

Phase 2    Shell
           → Next.js layout, nav, auth pages (no feature data yet)

Phase 3+   Feature vertical slices
           → For each feature: Django model → migration → DRF endpoint
             → Next.js component consuming real API

Gotchas

• The presence of a Jira plan or sprint structure does not change the rule — each sprint ticket should still be a vertical slice (model + endpoint + page), not backend tickets in one sprint and frontend tickets in another.
• API shape drift is the main failure mode of all-backend-first: the mail endpoint response doesn’t fit the 3-panel UI you design 13 weeks later. Vertical slices prevent this by building UI against each endpoint immediately.

Source

Conversation “Django vs Next.js frontend choice” — 2026-05-26 (Django + Next.js SaaS project, 21-week solo plan)

Weekly Summary — 2026-W22

Appeared: Tue 26 May (note created this week) Key developments this week:

• Settled the all-backend-first vs vertical-slice debate for the ongoing Django + Next.js SaaS project. Vertical slices confirmed as the correct strategy for solo development with a known spec.
• Confirmed that the existing Jira plan already structures work as vertical slices — no reordering needed. Phase 0–1 (Foundation + Auth) locks the core data model before any feature-specific work begins, which is the correct handling of the one legitimate concern with early frontend work.

New things learned:

• The root cause of all-backend-first failure for solo devs is sequential work eliminating the parallelism that makes all-backend-first rational for teams.
• API shape drift (endpoint output doesn’t fit the UI you design 13 weeks later) is the main technical failure mode of all-backend-first. Vertical slices prevent this by building UI against each endpoint immediately after the endpoint is written.

Open questions / next steps:

• Run Phase 1 Vuexy audit in Claude Code (the 12 claude-docs/ prompt)