Choose a tech stack that catches mistakes when you work alone
Four tests: one language, a free start, previews and a required check. Vercel Hobby is non-commercial; GitHub Free gates public repos only.
Senior Full-Stack Engineer- Published
- 7 minReading time
- EntrepreneurCategory
Listen to this post· AI-narrated
0:00 / 8:05Most advice on how to choose a tech stack hands you a list: MERN for real-time apps, Django for data, Laravel when you want one way to do things. Every option assumes a team behind it, with someone to review your pull request and someone to test the release. When you build alone, those people are you, usually at 11 PM, deciding between Next.js and Django, so a tech stack you run alone has to do part of the reviewer's job. It shows you every change on a real URL before users see it, and it refuses a merge that breaks a test. I've built for the web since 2014, and these are the four tests I put a stack through before I build on it alone, plus where the free plans behind them stop.
TL;DR: Choose a tech stack one person can carry: one language from the database to the browser, a free start, a preview deployment for every change, and a required check that blocks a broken merge. Read the plan terms first. Vercel's free Hobby plan is non-commercial, and GitHub Free only protects branches in public repositories.
What makes a tech stack right for a solo developer?
For a solo developer, a stack passes or fails on one thing: whether one person can build it and ship it safely without asking anyone. Four questions test that:
- Can you write every layer in one language?
- Can you start without paying, and do you know the exact day that ends?
- Does every change get its own preview before it reaches users?
- Does something other than your own judgement block a broken deploy?
The usual guides add a question I'd drop for a solo product: how deep the hiring pool is. Full Scale's guide (opens in a new tab), written by a company that staffs engineering teams, puts it near the top, and for a company that plans to hire, it belongs there. When you work alone, the collaborator you're planning for is a coding agent. Full Scale makes the relevant point itself: AI assistants are far better at mainstream, high-training-data languages. TypeScript, Python and PHP pass that test. A niche language you love leaves both you and the agent with fewer answers to draw on.
Why does one language end to end matter when you work alone?
One language, with types that flow from the database schema to the browser, turns a whole class of bugs into build errors. Rename a field in a TypeScript schema, and every component that still reads the old name stops compiling:
// schema: posts now have `headline` instead of `title`
const posts = defineTable({ headline: v.string(), body: v.string() });
// a component you forgot about
<h2>{post.title}</h2>
// error TS2339: Property 'title' does not exist on type
With a Python API and a TypeScript front end, the same rename compiles on both sides and fails in front of a user, unless you also maintain generated types or contract tests between them. A team can staff that seam. Alone, you are the seam.
Dan McKinley made the company-sized version of this argument in his 2015 essay Choose Boring Technology (opens in a new tab): "if we're already using Ruby, adding Python to the mix doesn't feel sensible because the resulting complexity would outweigh Python's marginal utility." A company pays that complexity with a team. You pay it with your evenings.
SQL, CSS and HTML still exist, so "one language" means one language for your logic. TypeScript isn't the only way to get there. A Python developer gets most of it from Django with HTMX, which the solo builder behind solodevstack.com (opens in a new tab) sums up as "One language. One codebase. One deployment." Template typos won't fail the build there, so your tests carry more of the weight. Pick the one you debug fastest.
Is a free tier enough to start a solo product?
Start on free plans, but find where each one stops before you build on it. The limit that bites first usually sits in the terms of use, long before any usage quota.
| Piece | What the free plan covers | Where it stops |
|---|---|---|
| Vercel Hobby | Hosting with preview deployments | "Non-commercial personal use only"; taking payment counts as commercial |
| Convex Free | A backend with preview deployments | Previews are deleted after 5 days and are in beta |
| GitHub Free | Branch protection and required checks | Public repositories only; a private repo needs a paid plan |
Vercel's fair use guidelines (opens in a new tab), updated 14 September 2026, define commercial use as any deployment made for financial gain, starting with "any method of requesting or processing payment from visitors of the site". The day you add a checkout, the hosting plan has to change.
GitHub's limit is easier to miss. Protected branches (opens in a new tab) are available on public repositories with GitHub Free, and on private ones only with GitHub Pro, Team or Enterprise. If your repo is private, the required check described below is a paid feature. Budget for both plans before the product starts charging.
How do you review your own changes without a team?
You review your own changes by looking at each one on a real URL before it merges. Vercel does this by default: it creates a preview deployment (opens in a new tab) for every pull request and every push to a branch that isn't production, each with its own link in the pull request.
The front end is half of it. A preview front end that talks to your production database turns every test click into real data: a test order in the orders table, a fake signup in the user list. The backend needs a preview too. Convex, a hosted backend you write in TypeScript, has preview deployments (opens in a new tab), currently in beta, that create a temporary backend per branch and clean it up after 5 days on the Free plan, or 14 on paid plans. A pull request open longer than that loses its backend, and the next deploy creates a fresh one with empty tables unless you seed it with a function (Convex's --preview-run flag). Whatever backend you choose, check before you commit to it that a pull request gets its own data.
Then use the preview the way a colleague would. Open it on your phone, try the one flow the change touches, and only then merge. That catches what no test covers, like a layout that breaks on a small screen.
What stops a broken deploy when you are the only reviewer?
A required status check stops it. On GitHub, branch protection can require named checks (your test suite, the type check, the build) to pass before anything merges into main, and when production deploys from main, a red check means nothing ships.
One default matters more for a solo developer than for anyone else. GitHub's docs say the restrictions of a branch protection rule "don't apply to people with admin permissions" unless you turn on Do not allow bypassing the above settings. On your own repository, you are the admin. Without that box, the gate you built lets you straight through on the night you're tired enough to need it. Tick it. You can still untick it later, but that takes a trip to the settings page, which is the point.
The same gate covers your coding agent. Tests are the spec agents need: when an agent opens a pull request, the required check holds its work to the same bar as yours. The bar only holds if the agent can't move it, so read any change to the test files before you read the rest of the diff.
The cost is time. Strict checks, GitHub's default, require the branch to be up to date before merging, so more builds run. A gate that takes minutes is still cheaper than a rollback you do alone.
What to do this week
Run your current stack through the four tests:
- Count the languages between the database and the browser. More than one is a token spent.
- Read the commercial-use terms of every free plan you depend on, and note what changes when you charge.
- Open a pull request and check that it gets a preview front end and a preview backend with its own data.
- Add one required check to
mainand turn on Do not allow bypassing the above settings.
Fix whichever test fails before the next feature. More posts on building software alone are on the gabs.app blog. I'm a full-stack engineer and my work is on gabs.app; if you're hiring, the contact form comes straight to me.