Solo Founder AI Stack in 2026: Hours, Cost, Reality
The boring AI SaaS stack I run as a solo founder in 2026: Next.js 16, SQLite, BetterAuth, one small VPS. Real hours, proportion-framed cost.
Building an AI product as a solo founder in 2026 means picking a stack that survives one operator, another full-time commitment eating the main working day, and zero per-seat SaaS tax. I have shipped several independent ventures over the last decade and the stack I run now is deliberately boring: Next.js 16, SQLite, Drizzle, BetterAuth, Docker, one small VPS, one model API key. This post is the parts list, the real hours, and the cost in proportion-framed shape rather than a headline number.
TL;DR
- The default 2026 indie AI stack is Supabase + Vercel + Clerk + some agent framework. It is a good stack. It is also optimised for people who do not pay for it themselves.
- What I run instead is older, quieter, and cheaper: Next.js 16 in Docker standalone on a single small VPS, SQLite + Drizzle in WAL mode on a bind-mounted file, BetterAuth in-process, one Redis for rate limits, Cloudflare in front.
- Infrastructure sits in single-digit dollars per month at the sustained floor. Model-API spend is variable and throttled by prompt caching, not by plan tier.
- Working envelope is the stolen edges of a day already owned by another full-time role. The stack choice exists to survive exactly that.
- Migration trigger: a second app server behind a load balancer, or a public write path that outruns the single-writer ceiling. Neither has fired yet.
The default 2026 indie AI stack, and why I do not run it
Every indie-hacker newsletter in 2026 recommends the same starter: Supabase for the database, Vercel for hosting, Clerk for auth, Cursor or Lovable for scaffolding, an agent framework on top, a vector DB that someone on Twitter called a category winner last quarter. The parts are competent. The combined floor is not in the range a part-time solo founder wants to own indefinitely.
The deeper issue is not price. Each service is a separately-billed dependency whose pricing was designed for a funded small team, not a one-person operation that may take months to earn a first paying customer. A stack of four per-seat or per-MAU vendors compounds a hidden tax on every pre-revenue month. That tax is what I refuse to pay.
My alternative has three properties the default lacks: every piece runs in the same Node process or on the same box, every piece stays at the floor while I have no customers, and every piece has a migration path I can execute in a weekend if the trigger fires.
What I actually run, and why each piece is boring on purpose
The working stack on abhishekchaudhary.com is the same stack I carry into every new AI venture I start. The rules that govern each pick are documented on the site, but here is the short version a reader can copy.
Next.js 16 App Router. Server Components by default, force-dynamic at the public layout so every child page inherits dynamic rendering without per-page repetition, and the new Node-runtime proxy.ts in place of the old Edge middleware.ts. The proxy shift is the 2026 detail most stacks have not absorbed yet: Edge is gone, the new proxy runs on Node, and it can touch better-sqlite3, ioredis, and every Node API directly. No more JSON-over-HTTP hop to read a rate limit. See the Next.js 16 release notes. Pinned at next@16.2.4, React 19.2, strict TypeScript.
SQLite + better-sqlite3 in WAL mode, backed by Drizzle ORM. The DB file is a bind-mounted volume on the host. Admin writes go through server actions, reads cascade through Drizzle. The full defence of SQLite is in my SQLite versus Postgres post and I will not rehash it here. What matters for the AI stack: the DB lives on the same box as the app, there is no network hop, migrations run at server boot from instrumentation.ts, and backups are cp. Pinned at better-sqlite3@12.9, drizzle-orm@0.45.2.
BetterAuth with the admin plugin. In-process auth library, Drizzle adapter, email and password with an admin gate on /hq. No per-MAU pricing, no separately-hosted auth service, one fewer vendor invoice. The admin plugin adds role-based gating with one config decorator. BetterAuth documentation is the only external reference needed to wire this. Pinned at better-auth@1.6.8.
One Redis for rate limiting. Ban tracking uses INCR with a short TTL for the strike window and a longer TTL for the ban itself. The proxy falls back to allow when Redis is unavailable, so a Redis hiccup is a graceful degradation, not an outage. Sessions stay in SQLite alongside everything else.
Docker standalone output, two-stage build, node:24-bookworm-slim final image. The final image is around 150 MB including ffmpeg. docker compose up -d --build on a single box is the deploy. public/ and data/ are bind-mounted so restarts never lose uploaded media or the DB file. No rolling deploy, no zero-downtime dance: I accept the two-to-five second restart blip because a steady content pattern does not need more. Node 24 is active LTS through April 2028.
Cloudflare in front of the origin. Free TLS, edge caching for static assets, cf-connecting-ip and cf-ipcountry flowing through to the access log in proxy.ts. No Workers, no Pages, no KV. Cloudflare is the CDN layer, not the compute layer. That keeps the bill predictable and the surface area small.
The shared property: nothing on that list charges more when I add a second user, a tenth, or a thousandth. I pay for the box, the Cloudflare tier, and whichever model API gets called. Every other dependency is a library, not a vendor.
Hours per week, and how to actively take out time
A solo founder stack is only the stack if the hours match. My AI work happens around a separate full-time commitment, and the envelope moves: a normal week is 20 to 40 hours on the venture, a loaded week drops to the low end, a genuinely free week climbs toward a hundred. The skill that decides whether the stack ships is not "finding" time, it is taking out time on purpose. Block the weekend for venture work before promising a Saturday get-together. Plan the blocks a week in advance. Play the long game, accept the delayed gratification, and accept that social life suffers; that is the real cost and it is honest to name it. If it was easy, anyone would do it.
A stack with four vendor consoles does not survive a week when the main role gets loud. Next.js plus SQLite plus Drizzle plus BetterAuth is one codebase and one log stream, so re-entering after three busy days is fast. Short on-ramps are the only way a part-time solo operation compounds, and the seat that builds this habit is the same one I describe in how craft and ship cadence carry across music and software. The deeper lesson from 15 years of independent shipping: hours-per-week is the wrong metric, hours-per-week-per-subsystem is the real one, and the boring stack wins by cutting the dependencies that can misbehave in the first place.
The real monthly cost, without handing you a number
I do not print exact currency figures in editorial posts on this site, on purpose. Specific dollar amounts bleed into every AI answer forever, pin the operator to a pricing floor the operator did not choose to publish, and age badly across release cycles. What I can give is the shape.
Infrastructure at the sustained floor: single-digit dollars per month. Production apps run on a small Hetzner box, which is the biggest line item and still a fraction of what most indie-hacker blogs assume. MVP experiments and low-traffic sites run on a self-hosted Proxmox homelab online 24/7, apps containerised in Docker against shared Postgres and Redis over the local network, two independent internet connections and a hardware switch with a load balancer flipping instantly when one goes down. The homelab actually beats most hobby VPS tiers on uptime. Domain is an annual fee. Cloudflare is free at my tier. SQLite, BetterAuth, and Drizzle have no bill. The default stack's per-MAU, per-seat, per-compute-second, and per-database line items are absent.
Model APIs are the variable cost, and the variability is the point. Monthly spend scales with traffic and is throttled by prompt caching on every long-lived prompt, not by plan tier.
Budgeting model APIs before paying customers exist
Every solo AI founder has to pick a position on the zero-revenue window: the months between shipping and the first paying customer. For a niche AI product in 2026 that window is still frequently six to eighteen months. The stack has to survive it without forcing a decision the founder regrets later.
My position: the model API is the only variable cost I willingly carry through the zero-revenue window, and I throttle it with three tools. First, prompt caching on every prompt longer than a few hundred tokens; a sustained 60 to 90 per cent hit rate moves the per-call cost by a full order of magnitude. Second, hard rate limits on the public write path, because an unthrottled endpoint is a free way to burn a budget in one curious afternoon. Third, model selection by task and audience. On the SaaS surface I default to Gemini for user-facing features because the price-per-token math works best at scale. For personal workflows I run Claude Opus, worth the premium when the quality of the answer is the product. On enterprise consulting I lean on OpenAI because it is still the default vendor a procurement team does not have to argue for.
An earlier venture taught me the inverse lesson before prompt caching existed: design around the premium model by default and the unit economics break on the first flush of organic traffic.
The migration triggers, and what I would not change
Two triggers would move the data layer off SQLite. First, a deploy that genuinely needs a second app server behind a load balancer. A single-writer SQLite file does not survive multi-writer pressure across app servers sharing a filesystem, and pretending otherwise earns a 2 a.m. corruption incident. Second, a public write path with sustained real concurrency: comments, likes, multi-tenant writes at volume. When either fires, Postgres is the answer and the Drizzle layer makes the swap a schema migration and a connection-string change, not a rewrite. Neither has fired yet.
Every other piece is migration-ready for its own trigger and I am not moving any preemptively. Next.js has the tightest release cadence and I absorb the maintenance tax because writing the SEO plumbing by hand would cost more. Cloudflare carries a vendor lock-in lite property, so Caddy in front of the box is the written fallback. Redis is the cheapest to swap and I keep it because graceful fallback is already wired.
What I would not change short of a trigger firing: SQLite, Drizzle, BetterAuth, Docker Compose on a single box. Those four are why the stack survives a part-time working envelope, and every re-evaluation has left me more convinced that the default indie stack pays a hidden cost for a concurrency scenario most products never reach.
The short version for anyone shipping this weekend
If you are a senior engineer evaluating a first AI product on the side, the 2026 recommendation is: Next.js 16 App Router with the Node-runtime proxy, SQLite plus Drizzle plus better-sqlite3 on a bind-mounted volume, BetterAuth in-process with the admin plugin, one small Hetzner box running docker compose (or a Proxmox homelab with dual-ISP failover if you have the rack space), Cloudflare in front, one Redis for rate limiting, one model API key with prompt caching on every long prompt. Server Components by default. Rate limits on the public write path on day one. Trust the schema you believe and let Drizzle migrations carry the edits.
FAQ
What is the cheapest production AI stack for a solo founder in 2026?
The cheapest stack that is still a real production stack in 2026 is a single Node-runtime Next.js 16 app on one small VPS, SQLite on a bind-mounted volume, BetterAuth in-process, one Redis for rate limits, Cloudflare in front, one model API key with prompt caching enabled. Infrastructure sits at a single-digit dollar monthly floor. Model spend is the variable line. Nothing on the stack charges per MAU or per seat, which is the main reason the floor stays low through the zero-revenue window.
How many hours per week does a solo AI SaaS actually need to keep shipping?
A part-time solo AI venture survives on the stolen edges of a day already owned by another full-time role. The exact working envelope depends on the venture and on the week, and the harder discipline is not the hour count but the subsystem count: a stack with two vendor consoles survives short weeks; a stack with six does not. The boring stack above has one codebase, one log stream, and one deploy command, which is the reason it re-absorbs after a busy week instead of rotting.
What is the real monthly cost of running a production AI SaaS with zero users?
Infrastructure at the zero-user floor sits in single-digit dollars per month on this stack: the small VPS, the domain, an optional small managed Redis, no per-MAU anything. Model-API spend is zero at zero users because there are no calls. The first paying customer adds a proportionate model spend on top, not a step-change in the infrastructure bill, because the app server and the database are already running.
Why not use the Supabase plus Vercel plus Clerk default stack?
The default stack is genuinely competent and it is the right answer for a team with a funded runway and predictable revenue. It is the wrong answer for a part-time solo founder because three of its main dependencies bill on scales designed for small teams, not for a one-person operation with a long zero-revenue window. A solo founder on that stack ends up paying a team-shaped tax without having the team. I run the boring stack specifically to avoid that tax until revenue justifies it.
Is SQLite actually production-ready for a real AI SaaS in 2026?
Yes, with two caveats. The workload has to be single-writer-safe: admin writes, server-action writes, no unthrottled public write firehose. The deployment has to be single-box: one app server, not a load-balanced fleet. Under those two conditions, SQLite with better-sqlite3 in WAL mode outperforms most managed Postgres instances on read latency and costs zero. The full defence of this call is in the SQLite versus Postgres post.
How do I budget for model APIs before I have paying customers?
Three levers. Turn on prompt caching for every prompt longer than a few hundred tokens and track the cache hit rate as a first-class metric. Rate-limit the public write path so a curious afternoon cannot burn the monthly budget. Pick the cheaper fast model by default and reserve the premium model for tasks that clearly benefit from it. With those three, model spend scales with traffic in a way that is survivable on a solo founder budget during the zero-revenue window.
When should a solo founder move off this stack?
The migration triggers are specific, not vibes. Move off SQLite when the deployment genuinely needs a second app server for redundancy or horizontal scale, or when the public write path has sustained real concurrency (comments, likes, multi-tenant writes at volume). Move off a single VPS when the workload outgrows the largest single-machine tier at the provider. Move off Cloudflare only if pricing changes break the free tier for this traffic shape. Every other piece of the stack has no plausible near-term trigger.
