Running 8 Apps Solo: My Tech Stack Decisions for 2026

I run 8 live web apps in production. All of them are built, deployed, and maintained by one person — me.

No co-founder. No engineering team. No DevOps hire. Just one developer with strong opinions about technology choices and an obsessive need to ship.

This is not a theoretical "what I would use" post. Every decision here comes from running real products with real users and real revenue. Some of these choices saved me hundreds of hours. Others cost me weeks I'll never get back.

Here's exactly what I use, why I chose it, and what I'd do differently if I started over today.

The Portfolio

Before diving into the stack, here's what we're working with:

These range from consumer apps to B2B SaaS to content sites. Some generate revenue. Some are pre-launch. All of them are live, deployed, and maintained simultaneously.

The key insight that makes this possible isn't talent or hustle — it's consistency. When every app shares the same foundation, context-switching costs drop to nearly zero.

The Shared Foundation

Every single one of these apps runs on the same core stack:

• Next.js App Router (versions 14 through 16)
• React 19 + TypeScript
• Tailwind CSS + shadcn/ui (Radix primitives + Lucide icons)
• Vercel for deployment

This is the most important decision I've made as a solo founder. Not which database to use. Not which AI model to pick. The decision to use the same framework for everything.

Why This Matters More Than You Think

When I open any of my 8 codebases, I already know:

• Where the routes live (app/)
• How components are structured (components/ui/ for primitives, feature folders for the rest)
• How styling works (Tailwind utility classes, cn() helper everywhere)
• How deployment works (push to main, Vercel handles the rest)

Context-switching between projects takes seconds, not hours. I can fix a bug in Stayic at 9am, ship a feature for ToonyStory at 10am, and update ChoreSplit's landing page after lunch — without losing any mental momentum.

If you're a solo founder considering "should I use Remix for this one?" or "maybe SvelteKit for that one?" — don't. Pick one framework and go deep. The compound returns of consistency are enormous.

The cn() Utility

One small detail that saves me daily: every repo has the same cn() utility combining clsx and tailwind-merge. It sounds trivial, but having identical patterns across projects means I can copy components between apps without any adaptation.

import { clsx, type ClassValue } from 'clsx'
import { twMerge } from 'tailwind-merge'

export function cn(...inputs: ClassValue[]) {
  return twMerge(clsx(inputs))
}

This is in every single repo. Same file, same import path. Boring? Yes. Effective? Incredibly.

Database Decisions: The Painful Split

Here's where things get interesting — and where I have my biggest regret.

My apps are split across two database solutions:

Neon + Drizzle ORM (newer apps):

• ChoreSplit
• ToonyStory
• LuxeDen Resorts

Supabase (older apps):

• Specway
• LuxeDen Airbnb
• Stayic

File-based / none:

• MorganKotter.com (MDX with Contentlayer)
• Specway CLI (no database)

How This Happened

When I started building in 2023, Supabase was the obvious choice. Great developer experience, built-in auth, real-time subscriptions, generous free tier. I built Specway, LuxeDen Airbnb, and Stayic on it.

Then I discovered Neon + Drizzle ORM in late 2024, and the developer experience blew me away. Drizzle's type-safe schema definitions, automatic migration generation, and the way it maps directly to SQL — it felt like how database tooling should work. Neon's serverless Postgres with branching sealed the deal.

For ChoreSplit, ToonyStory, and LuxeDen Resorts, I went with Neon + Drizzle and never looked back.

What I'd Pick Today

Neon + Drizzle ORM, without question.

Here's why:

1. Type safety end-to-end. Drizzle infers TypeScript types directly from your schema. No codegen step, no separate type definitions to maintain. Change a column, and TypeScript errors immediately show you every place that needs updating.

2. Schema-as-code. Your schema lives in a .ts file. You can review it in a PR, diff it, and understand exactly what changed. Drizzle Kit generates the SQL migrations automatically.

3. Serverless-native. Neon's connection pooling works perfectly with Vercel's serverless functions. No connection limit headaches.

4. Free tier is generous. Most of my apps run entirely within Neon's free tier. For a solo founder watching costs, this matters.

The Lesson

Migration between database providers is painful enough that you should standardize early. I still have three apps on Supabase, and while they work fine, every time I switch between a Drizzle repo and a Supabase repo, there's friction. Different query patterns, different migration workflows, different mental models.

If you're starting out: pick one database solution and use it everywhere. The consistency tax you avoid is worth more than any individual feature advantage.

AI Integration: The Multi-Model Approach

I use AI extensively across my apps, and the most important lesson I've learned is: don't lock into one provider.

Here's how AI shows up across the portfolio:

Claude (Anthropic)

My primary tool for code assistance and content generation. Claude Code with custom skills is how I manage all 8 repos simultaneously (more on this in the automation section). For in-app features, Claude handles content generation and natural language processing tasks.

GPT-4o (OpenAI)

Used primarily for CRM integration features in Specway and structured data extraction. OpenAI's function calling is still best-in-class for structured output in production pipelines.

Gemini (Google)

The secret weapon for ToonyStory. Gemini handles image generation for children's storybook illustrations. The quality-to-cost ratio for image generation through Gemini has been exceptional.

Why Multi-Model?

Each provider has genuine strengths:

• Claude excels at nuanced reasoning and code generation
• GPT-4o excels at structured outputs and function calling
• Gemini excels at multimodal tasks and image generation

More importantly, building on multiple providers means no single API outage takes down all your AI features. When OpenAI has a bad day (and they do), my Claude-powered features keep running.

The implementation pattern is simple: wrap each provider behind a service layer with a consistent interface. Swapping models or adding fallbacks becomes a configuration change, not a rewrite.

Payments and Auth: Keep It Simple

Stripe Everywhere

Every app that handles money uses Stripe. Period.

Stripe's reliability is a genuine competitive advantage for solo founders. I've never had a payment fail due to Stripe infrastructure issues. Their documentation is excellent. Their dashboard gives me instant visibility into revenue across all products.

The consistency benefit applies here too — same Stripe patterns, same webhook handling, same subscription management code across every app that needs it.

Custom JWT Auth (No Clerk, No Auth0)

This is a controversial take: I roll my own authentication for most apps. Simple JWT-based auth with email verification.

Why not Clerk or Auth0?

• Cost. Auth providers charge per user. When you're running 8 apps, those per-user costs add up fast — especially during the pre-revenue phase.
• Complexity. For most of my apps, auth is "sign up, log in, verify email." That's 200 lines of code. Adding an auth provider introduces SDK dependencies, webhook integrations, and dashboard management overhead that dwarfs the actual auth logic.
• Vendor lock-in. User data sits in my database, not in a third party's system. If I want to merge user bases or migrate an app, there's no provider to negotiate with.

When I would use an auth provider: If I needed SSO, enterprise SAML, or complex role-based access control. For a solo founder building consumer and SMB products, custom auth is the right call.

The Automation Layer: My Real Co-Founder

This is the section I'm most excited about, because it's the least talked-about advantage of being a solo founder in 2026.

Claude Code + Custom Skills

I've built over 50 custom skills for Claude Code that automate nearly every aspect of managing 8 codebases. This isn't "I use Copilot for autocomplete." This is a comprehensive automation system that acts as my engineering team.

Here's what runs automatically or semi-automatically:

Operations (every 6 hours):

• Health checks across all 8 apps — uptime, git state, open PRs
• Error monitoring for repeating 4xx/5xx patterns
• Deployment status tracking

SEO and Marketing (weekly):

• Technical SEO audits across all domains
• Search Console performance tracking
• Social media content drafts for all brands
• Content calendar generation
• Backlink opportunity identification

Development (on every task):

• Codebase research to understand existing patterns before writing code
• Implementation planning with checkpoints
• Code quality gates (formatting, linting, build checks) before every commit
• Automated PR creation with structured descriptions

Market Intelligence (daily):

• Competitor monitoring
• Content gap analysis
• Feature ideas from market trends
• Distribution channel opportunities

Why This Matters

A traditional founder running 8 apps would need at minimum:

• 2-3 developers
• A DevOps person
• A content marketer
• An SEO specialist

I replace all of those roles with automation. Not perfectly — but well enough to keep 8 apps moving forward simultaneously.

The key insight: automation is not about doing things faster. It's about doing things at all. Without this system, I physically couldn't maintain 8 production apps. With it, I spend most of my time on strategy and product decisions rather than operational work.

What I'd Change

Honesty time. Here's what I'd do differently:

1. Standardize on One Database from Day One

My biggest regret. The Supabase/Neon split creates ongoing friction. If I could start over, everything would be Neon + Drizzle from the beginning. The migration cost to unify them now is high enough that I'm living with the split.

2. Build a Shared Component Library Earlier

Each app has its own copy of common components — data tables, form patterns, modal dialogs. They're similar but not identical, which is the worst state to be in. You can't copy-paste because the APIs differ slightly, but you can't share a package because they were never designed for it.

I should have extracted a shared component package after the second app, not the fifth.

3. Skip Building Auth from Scratch (Maybe)

I stand by the decision for simple consumer apps. But for Stayic (multi-tenant SaaS with role-based access), I ended up building a mini auth framework that took weeks. A provider would have saved time there. The lesson: evaluate complexity per-app, not as a blanket policy.

4. Invest in Monitoring Earlier

For the first year, my "monitoring" was checking each app manually. Setting up automated health checks and error tracking earlier would have caught issues before users reported them.

Cost Breakdown: 8 Apps for Under $50/Month

This is the number that surprises people most. Here's what it actually costs to run 8 production web apps:

The Vercel Pro plan at $20/month is the only fixed cost. Everything else runs within free tiers or charges based on usage.

This is possible because of serverless architecture. There are no servers to maintain, no containers to manage, no infrastructure to scale. Vercel handles deployment, Neon and Supabase handle databases, and Stripe handles payments. I handle the code.

For solo founders watching their runway: your infrastructure costs should be nearly zero until you have meaningful traffic. If you're spending hundreds per month on infrastructure before product-market fit, something is wrong.

Advice for Solo Founders

After building and maintaining 8 apps simultaneously, here are my top lessons:

1. Reuse Everything Aggressively

Don't just reuse code — reuse decisions. Same framework, same database, same deployment platform, same payment provider, same patterns. Every unique choice is a context-switch tax you'll pay forever.

I literally copy files between repos. Same cn() utility. Same Stripe webhook handler structure. Same API route patterns. It's not elegant, but it's fast.

2. Ship Fast, Iterate Later

None of my apps launched "finished." ChoreSplit's first version was embarrassingly simple. ToonyStory generated terrible stories for the first month. Specway pivoted its entire product focus after launch.

The apps that succeeded weren't the ones that launched perfectly — they were the ones that launched at all. Get it live, get it in front of users, and iterate based on feedback. Perfectionism is the enemy of a solo founder.

3. Automation Is Your Co-Founder

If you're doing something manually more than three times, automate it. I've invested heavily in Claude Code skills, automated SEO audits, social content generation, and ops monitoring.

This isn't a luxury — it's a requirement. You cannot manually operate 8 apps. You can automate the operation of 8 apps and focus on the decisions that actually matter.

4. Choose Boring Technology

Next.js, React, TypeScript, Postgres, Stripe — none of these are exciting or trendy. They're proven, well-documented, and predictable. That's exactly what you want when you're the entire engineering team.

I don't have time to debug bleeding-edge framework issues or work around ORM limitations. I need tools that work reliably so I can focus on product.

Save the experimentation for side projects. Production apps get boring technology.

5. Your Personal Brand Connects Everything

This site — morgankotter.com — ties all 8 apps together. It's where I write about the technical decisions behind them (like this post), share what I've learned, and build the credibility that drives traffic to all my products.

Your personal brand is the common thread. Products come and go. Your reputation and expertise compound forever. Invest in it.

Check out my projects page to see all the apps, read more about my tools and setup, or learn more about me.

Wrapping Up

Running 8 apps solo in 2026 is possible, but only with extreme discipline around consistency and automation. The tech stack matters less than you think — what matters is picking a stack and going deep with it.

If you're a solo founder or thinking about becoming one, start with the foundation: one framework, one database, one deployment platform. Build your automation layer early. Ship fast. Iterate relentlessly.

The tools have never been better for solo founders. The question isn't whether one person can build and maintain multiple products. It's whether you're willing to make the boring, consistent, compounding decisions that make it possible.

Have questions about running multiple apps solo? Want to compare tech stack notes? Reach out — I'm always happy to talk shop with fellow indie hackers and solo founders.