Web Stack Options for a Solo Learner. A Build Next Stack field guide for learners shipping small projects.
What solo-learner stack actually means
A solo-learner web stack is the smallest set of tools that lets one person go from idea to HTTPS URL without a dedicated DevOps teammate. It includes: a language/runtime, a way to render HTML or JSON, a deploy path, and optional data storage. It explicitly excludes tools your project does not need yet—Kubernetes, microservices, event buses—no matter how often they appear on conference slides.
Your stack should match learning bandwidth. If you have six hours per week, a stack with five config files before hello world is a stack you will abandon. Prefer boring defaults you can explain aloud in ninety seconds.
Solo does not mean simple project. It means operational surface area stays small enough that when something breaks at 10 p.m., you can trace the failure through layers you actually understand.
Document your stack in three bullets: runtime, host, data store. If a fourth bullet appears, ask whether it serves this month’s milestone or a hypothetical conference talk. Solo stacks rot when upgrade chores exceed feature chores for three weeks straight.
Three stack shapes compared
Shape A — Static site + serverless functions: HTML/CSS/JS (or a static generator) on object storage; small API endpoints as cloud functions. Ops low, cost low, cold starts and vendor limits are the tradeoffs. Fits contact forms, landing pages, read-heavy tools.
Shape B — Monolith on a PaaS: One Node, Python, or Ruby app serving pages and API together on Render, Fly.io, Railway, or similar. Mental model easy; monthly bill creeps if you leave workers idling. Fits CRUD apps, auth experiments, admin dashboards.
Shape C — SPA + separate API: React/Vue/Svelte front end talking to a REST or GraphQL backend. Flexible, but two deployables and CORS/debug split-brain hurt solo learners. Fits when UI complexity clearly dominates and you accept double repos or a monorepo tool.
Most first projects that think they need Shape C ship faster as Shape B with server-rendered pages, then split later if pain proves real.
When comparing shapes, estimate debug paths not feature lists. Shape A debugging is browser network tab plus function logs. Shape B is one application log stream. Shape C is two repos and CORS—a tax every week, not only on deploy day.
Learners who document one bug fix per shape in a small log build intuition faster than learners who re-architect every Sunday.
Anti-pattern: copying a startup production diagram
Architecture diagrams from funded teams include message queues because they had traffic spikes last Black Friday—not because a feedback form needs RabbitMQ. Copying that diagram as a learner teaches you YAML, not your users.
Another anti-pattern is framework maximalism: Next.js + tRPC + Prisma + Tailwind + auth library before validating the core idea. Each layer adds upgrade chores. Stack depth should track user count, not aspiration count.
Red flag phrase: I am setting up the foundation. Week one foundation is one deployed page that does the job badly but visibly.
Also watch local-only stacks that never reach HTTPS: Docker Compose on localhost teaches containers, not users. Deploy early—even a broken staging URL forces you to learn env vars and build commands while motivation is high.
Worked example: feedback form in one weekend
Goal: collect structured feedback on a landing page. Solo stack choice: Shape A. Static page on Netlify or Cloudflare Pages; form POST to a single serverless function that validates input and sends email or appends to a Google Sheet via API.
Saturday: HTML form + client-side required fields. Sunday morning: function with rate limiting stub; Sunday afternoon: custom domain and spam honeypot field. No database, no React, no Docker. You learned HTTP POST, env vars for secrets, and deploy hooks—skills that transfer when the project grows.
If you had started with Shape C, Sunday night might still be webpack errors. Match stack shape to weekend scope.
After launch, log what felt heavy: cold start latency, spam submissions, missing HTTPS redirect. That list becomes your upgrade backlog ranked by user pain, not by blog posts about microservices.
Where each stack shape breaks for beginners
Static + functions: breaks when you need authenticated sessions with server-side state every request—workarounds get hacky. Upgrade path: add a tiny BaaS or move to Shape B.
Monolith PaaS: breaks when asset pipeline and API release cycles fight—front-end devs waiting on back-end deploys. Upgrade path: extract API or adopt monorepo scripts.
SPA + API: breaks when solo you must fix a bug spanning auth cookie and client router—two logs, two deploy rollbacks. Upgrade path: server-render critical paths only.
Knowing break points early prevents shame when you outgrow a shape—it was appropriate stage one, not a mistake.
Pick-one checklist for this month
Choose Shape A if: mostly read-only content, fewer than three form endpoints, traffic unpredictable but low. Choose Shape B if: users log in, you mutate shared data, you want one git push to update everything. Choose Shape C if: UI has dense client interactivity (drag-drop boards, offline-first) and you already shipped something simpler once.
Write your choice in the project README with upgrade trigger notes: e.g., move to B when we need user accounts. Triggers turn rewrites into planned migrations.
Cap dependencies: one UI framework OR none, one host, one database if needed. Extra tools require a sentence justification in README.
Revisit shape choice after ten external users or four weeks—whichever comes first. Until then, resist stack tweets that make your working deploy feel obsolete.
Ship one shape before debating microservices
Sketch your project on one index card: who visits, what they submit, what must persist. Map that card to Shape A, B, or C, deploy a ugly v0 this week, and log what felt heavy—that log is your stack roadmap.
Questions about which shape matched your build? [email protected] — include your project one-liner and what broke first.