DEV Community: Alex Mayhew

111 Tests, 17 PDFs, and a 44-Item Security Checklist: What Production-Ready Should Actually Mean

Alex Mayhew — Thu, 16 Apr 2026 04:47:31 +0000

"Production-ready."

Every SaaS boilerplate on the market uses that phrase. I spent a week reviewing 11 of them. Here's what I found behind the label.

What "Production-Ready" Usually Means

It means the demo runs. It means there's a Stripe integration that processes a test payment. It means there's auth that returns a JWT. Ship it.

What it doesn't mean... in any of the 11 boilerplates I reviewed:

Published test coverage numbers. Not one. Zero out of eleven boilerplates tell you how much of the code is tested before you buy it.
Architecture diagrams. You're supposed to extend this code into a real product. Shouldn't you be able to see how the pieces fit together?
A security checklist. Auth, webhooks, CORS, SQL injection... there's a baseline of security work that every SaaS needs. Nobody documents what's handled and what's left for you.

The assumption seems to be that if it boots and takes a payment, it's production-ready. That's not production-ready. That's demo-ready.

What I Built Instead

When I built The Unsexy Stack... a FastAPI + Next.js 15 SaaS boilerplate... I made a deliberate choice: treat the documentation and tests as product deliverables, not afterthoughts.

Here's what actually shipped:

111 tests across the full stack.

71 backend tests covering auth (JWT validation, JWKS caching, key rotation), webhooks (signature verification, idempotency, race conditions), billing (Stripe subscription lifecycle), CORS, database sessions, and configuration
40 frontend tests covering components, middleware, error boundaries, loading states, and page rendering
Coverage threshold enforced in pyproject.toml at 80%... the CI fails if coverage drops below it

17 PDF documents. Not a README with a few paragraphs. Actual documentation you can read offline, hand to a client, or use as a reference while building:

QuickStart guide
Architecture overview
Configuration reference
Stripe setup walkthrough
Deployment guide (systemd + nginx)
Docker guide
CI/CD pipeline setup
Security checklist
Scaling guide (what to add at 100, 1K, 10K, 100K users)
Customization guides
Client handoff template
Troubleshooting reference
Analytics and monitoring setup
FAQ
Changelog
Philosophy ("Why Unsexy")
Start Here guide

6 architecture diagrams built with D2... not hand-drawn boxes in Figma:

System overview (how FastAPI, Next.js, PostgreSQL, Clerk, and Stripe connect)
Auth flow (JWT validation, JWKS caching, the full request lifecycle)
Payment flow (Stripe Checkout to webhook to database update)
Database ERD (full schema and a Starter-tier variant)
Deployment architecture (nginx, systemd, SSL, the production layout)

A 44-item security checklist split into two parts:

Part 1 covers what's already built into the boilerplate... JWT validation with JWKS caching and asyncio.Lock, RSA key parsing, webhook signature verification, idempotent webhook processing, SQL injection prevention via SQLAlchemy ORM, CORS origin whitelisting, open redirect prevention, rate limiting, security headers, and non-root containers.

Part 2 covers what you need to do before launch... database hardening, Clerk configuration, payment security, infrastructure setup, and monitoring. Each item is marked CRITICAL, HIGH, or RECOMMENDED so you know what to tackle first.

Why This Matters

Here's the practical argument for all of this.

Tests prevent regression. You're going to modify this code. You're going to add models, change the auth flow, customize the billing logic. When you do... the test suite tells you what you broke. Without tests, you're deploying hope.

Documentation prevents ramp-up waste. I've joined projects where the onboarding process was "read the code." On a 50-file codebase that you didn't write... that's days of work that a 10-page architecture doc would eliminate. The diagrams aren't decoration. They're the map you use before touching anything.

The security checklist prevents the breach you don't know is coming. Auth, webhooks, CORS headers... these aren't features you think about until they fail. And when they fail in production with real user data, the cost isn't a bug ticket. It's a breach notification email.

The Real Cost of Skipping This

I'm not trying to shame anyone. Building tests and docs takes real time. Most boilerplate creators are solo developers optimizing for speed... ship the starter kit, get sales, iterate.

But the buyers of these products aren't demo-ing them. They're building real SaaS products on top of them. Products that will handle user data, process payments, and grow into something that needs to be maintained by a team that doesn't include the original developer.

Handing that team a codebase with no tests, no diagrams, and no security documentation isn't saving time. It's transferring risk.

What I'd Check Before Buying Any Boilerplate

If you're evaluating SaaS starters... regardless of stack... here's what I'd ask:

How many tests are there? If the answer is "none" or "I don't know"... that tells you how much the creator trusts their own code.
Is there an architecture diagram? If you can't see how the pieces connect before buying, you're buying blind.
Is there a security baseline? Auth and payment handling have real security implications. What's covered and what's left to you?
Can you read the code and understand it? Clever code is the enemy of maintainable code. The best boilerplate reads like documentation.
What happens when you need to change something? Extending the code should feel natural... not like you're fighting the framework.

These aren't unreasonable expectations. They're the bare minimum for something you're building a business on.

The Unsexy Stack is a FastAPI + Next.js 15 SaaS boilerplate with 111 tests, 17 PDF guides, and a 44-item security checklist. It's available at theunsexystack.com.

FastAPI + Next.js 15: The Full-Stack Nobody's Building

Alex Mayhew — Thu, 16 Apr 2026 04:47:05 +0000

Every SaaS boilerplate on the market does one of two things: it's all JavaScript, or it's all Django. The JS-only starters give you Next.js talking to itself. The Python starters give you Django with a React frontend bolted on as an afterthought. Both approaches leave something on the table.

I built a full-stack SaaS boilerplate using FastAPI and Next.js 15... and after comparing it against 11 competitors, I'm convinced this combination fills a gap nobody else is serving.

Why Not Just Use Next.js for Everything?

The "full-stack Next.js" approach is popular because it's simple. One language, one framework, one deployment. ShipFast, Makerkit, Supastarter... they all do this. And for a landing page with auth and Stripe, it works fine.

But the moment you need real backend logic... things get awkward.

Next.js API routes weren't designed to be a production API layer. They don't have dependency injection. They don't have request validation beyond what you manually write. They don't auto-generate OpenAPI documentation. And if you ever need to share your API with a mobile app, a CLI tool, or a third-party integration... you're retrofitting something that was built to serve HTML.

FastAPI was purpose-built for APIs. Every route gets automatic request validation via Pydantic. Every endpoint shows up in auto-generated OpenAPI docs. The dependency injection system handles auth, database sessions, and service layer patterns cleanly. Here's what an actual endpoint looks like:

@router.get("/me", response_model=UserResponse)
async def get_current_user_profile(
    clerk_user: Annotated[ClerkUser, Depends(get_current_user)],
    session: Annotated[AsyncSession, Depends(get_session)],
) -> User:
    result = await session.execute(
        select(User).where(User.clerk_id == clerk_user.clerk_id)
    )
    user = result.scalar_one_or_none()
    # ...

Auth, database session, input validation, response serialization... all handled by the framework. No middleware chains, no manual parsing. The type hints ARE the documentation.

And the Pydantic schema is the API contract:

class UserResponse(BaseModel):
    id: UUID
    clerk_id: str
    email: EmailStr
    tier: str
    created_at: datetime

    model_config = {"from_attributes": True}

That schema validates the response, generates the OpenAPI spec, and maps directly from the SQLAlchemy model. One definition does three jobs.

Why Not Django?

Django's great. SaaS Pegasus has proven there's a real market for Django-based SaaS starters. But Django was designed in 2005 for synchronous, request-response web applications. It's gotten async support over the years, but it's bolted on... not native.

FastAPI is async-first. Every route handler is an async def. The database layer uses SQLAlchemy 2.0's async engine. The auth layer uses asyncio.Lock for JWKS caching. Nothing blocks the event loop because nothing was written to block in the first place.

For SaaS APIs that handle webhook processing, third-party API calls, and concurrent database operations... async isn't a nice-to-have. It's the difference between one request blocking while Stripe's API takes 200ms to respond and that request yielding to handle 50 others in the meantime.

Why Next.js 15 on the Frontend?

Because server-side rendering matters for SaaS, and React 19 is genuinely better than what came before.

Next.js 15 with the App Router gives you:

Server components for the dashboard shell (no JS shipped to the browser for layout chrome)
Client components where you need interactivity (forms, real-time updates)
Middleware for auth redirects before the page even renders
TypeScript everywhere... with strict mode

The frontend talks to FastAPI over REST. Clean separation. The backend doesn't know or care that the frontend is Next.js. The frontend doesn't know or care that the backend is Python. You could swap either side independently.

The AI Angle Nobody's Talking About

Here's the thing that made me most confident about this stack in 2026.

Python is the language of AI/ML. If you're building a SaaS that touches anything AI-adjacent... inference, embeddings, document processing, data pipelines... your backend is probably going to need Python libraries at some point. torch, transformers, langchain, numpy, pandas... they're all Python.

With a FastAPI backend, importing those libraries is just... an import statement. With a Next.js-only stack, you're now maintaining a separate Python microservice, a message queue between them, and deploying two things instead of one.

The entire point of "boring tech" is reducing moving parts. A FastAPI backend that serves your API AND runs your ML inference is one deployment. An Express backend that calls a Python sidecar is two.

What This Looks Like in Practice

Two apps, one server. FastAPI serves the API on port 8000, Next.js serves the frontend on port 3000. In production, nginx sits in front and routes /api to FastAPI and everything else to Next.js.

The SQLAlchemy models use 2.0-style Mapped types:

class User(Base, UUIDMixin, TimestampMixin):
    __tablename__ = "users"

    clerk_id: Mapped[str] = mapped_column(
        String(255), unique=True, index=True, nullable=False,
    )
    email: Mapped[str] = mapped_column(
        String(255), unique=True, index=True, nullable=False,
    )
    tier: Mapped[str] = mapped_column(
        String(50), default=UserTier.FREE.value,
    )

Alembic handles migrations. PostgreSQL handles the data. Clerk handles auth tokens that FastAPI validates via JWKS. Stripe webhooks hit a FastAPI endpoint that verifies signatures and processes events idempotently.

Nothing here is novel. That's the point.

The Market Gap

I looked at every commercial SaaS boilerplate I could find. 11 products. Not one combines FastAPI and Next.js 15 as a cohesive full-stack offering.

The closest is FastSaaS... which does FastAPI + PostgreSQL but doesn't include a modern frontend. And SaaS Pegasus... which does Python + React but uses synchronous Django and treats the frontend as secondary.

If you're a Python developer who wants a production-grade SaaS foundation with a modern React frontend... your options have been: build it yourself, or compromise.

I built The Unsexy Stack to fill that gap. 71 backend tests, 40 frontend tests, 17 PDF guides, 6 architecture diagrams, a 44-item security checklist. The whole thing is designed to be read, understood, and extended... not just cloned and deployed.

If you're curious about the philosophy behind it, I wrote about why boring tech wins and why 74% of startups fail from premature scaling. But that's a whole separate post.

I'm Alex Mayhew, a solo developer on Cape Cod building and shipping products. The Unsexy Stack is available at theunsexystack.com.

I Reviewed 11 SaaS Boilerplates. Here's What Nobody Tells You.

Alex Mayhew — Thu, 16 Apr 2026 04:46:55 +0000

I spent a week reviewing every commercial SaaS boilerplate I could find. 11 products, ranging from $59 to $999. I looked at what's actually in each one... the tech stack, the tests (or lack thereof), the documentation, and the pricing structure.

Here's what I found.

The Market at a Glance

Product	Stack	Entry Price	Tests Published?	Docs Included?
ShipFast	Next.js + MongoDB/Supabase	$199	No	README only
SaaS Pegasus	Django + React/HTMX	$249	No	Online wiki
Makerkit	Next.js + Supabase/Drizzle/Prisma	$299-$349	No	Online (400+ pages)
Divjoy	React (generated)	$299	No	Minimal
Supastarter	Next.js/Nuxt + Prisma	~$100	No	Online docs
SaaSRock	Remix + Prisma	$149	No	Online docs
Shipped.club	Next.js + Supabase	$149	No	README only
Bedrock	Next.js + GraphQL	$149	No	Minimal
LaunchFast	Astro/Next.js/SvelteKit	$99	No	Online docs
Gravity	Node.js + React	~$179	No	Online docs
FastSaaS	FastAPI + PostgreSQL	~$85	No	Minimal

First thing that jumped out: not a single product publishes test coverage numbers. Zero out of eleven. That means you're buying code that the creator hasn't told you how thoroughly they've tested.

Second: almost nobody ships portable documentation. Makerkit has 400+ pages of online docs... which is genuinely impressive. But the rest give you a README, maybe a wiki, and that's it. No architecture diagrams. No security checklists. No PDFs you can hand to a client or reference offline.

The JavaScript Monoculture

9 out of 11 boilerplates are JavaScript-only. The dominant pattern is Next.js doing everything... API routes, server components, database queries, auth, payments. One framework, one language.

This works if JavaScript is your whole world. But there's a growing segment of developers who need Python on the backend... especially anyone touching AI, ML, data processing, or integrations with Python-native libraries. For those developers, the options narrow to:

SaaS Pegasus ($249-$999): Django. Battle-tested, synchronous by default, the React frontend feels secondary.
FastSaaS (~$85): FastAPI + PostgreSQL. Backend-focused, the frontend story is unclear.
The Unsexy Stack ($67-$297): FastAPI + Next.js 15. Full-stack, async-first, the one I built.

That's it. Three Python options across the entire commercial boilerplate market.

What Actually Differentiates These Products

After looking at all 11, the differentiators aren't what you'd expect.

Community vs. Documentation

ShipFast dominates on community. 5,000+ Discord members, 2,300+ reviews, Marc Lou's personal brand generating constant visibility. If you want to buy into an ecosystem with active support and fellow builders... ShipFast is the clear winner.

Makerkit leads on documentation volume with 400+ pages of online content. If you learn by reading comprehensive docs, Makerkit respects your time.

SaaS Pegasus has the longest track record. 5+ years of active development, ~1,000 Slack members, and customers who've built products that crossed $1M ARR. Cory Zue is deeply engaged with his community.

Feature Density vs. Simplicity

SaaSRock packs the most features per dollar. Entity builder, affiliate program, knowledge base, page block builder, email marketing... it's closer to a CMS than a boilerplate. If you need all that, it's a steal. If you need a clean starting point, it's overwhelming.

ShipFast and Shipped.club are on the opposite end... streamlined, focused on getting a landing page + auth + payments live as fast as possible.

Pricing Structure

The range is wide. FastSaaS at ~$85 for a backend-only FastAPI starter. SaaS Pegasus at $249-$999 for a mature Django foundation. Most products cluster around $149-$349 as a single price.

A few use tiers. SaaS Pegasus has 3 ($249/$449/$999 list). The Unsexy Stack has 3 ($67/$147/$297)... the $67 Starter is actually the lowest entry price in the entire market for a full-stack boilerplate. The tier model lets you buy at a lower price and upgrade if you need more.

What Nobody Ships

After reviewing all 11, here's what I noticed missing across the board:

1. Test suites with published metrics. I don't understand this one. If you're selling code that developers will build a business on... shouldn't you be willing to show how thoroughly it's tested? None of the 11 do this. The Unsexy Stack ships 111 tests (71 backend, 40 frontend) with coverage enforcement in CI. I'm not saying that to sell you on it... I'm saying it because the industry norm of "trust me, it works" isn't good enough.

2. Architecture diagrams. You're buying a codebase you didn't write. Understanding how the pieces connect shouldn't require reading every file. D2 diagrams, ERDs, flow charts... these are standard engineering artifacts. Most boilerplates don't include them.

3. Security baselines. Auth and payment handling have real security implications. JWT validation, webhook signature verification, CORS configuration, SQL injection prevention... what's handled? What's left for you? The answers should be documented before you buy. They almost never are.

4. Offline documentation. Online wikis and READMEs are fine for reference. But if you're handing this project to a client, onboarding a contractor, or working on a plane... you need portable docs. PDF guides with architecture overviews, deployment walkthroughs, and configuration references.

Which One Should You Buy?

Depends on what you need.

If you want the fastest path to a launched product and JavaScript is your stack: ShipFast. The community alone is worth it. 5,000 people who've built with the same starter you're using is a support network that no documentation can replace.

If you're a Python developer who wants a mature, full-featured Django foundation: SaaS Pegasus. It's expensive, but it's been refined over 5+ years and has a real track record of customers building successful products.

If you want the most comprehensive online documentation in a Next.js starter: Makerkit. 400+ pages is no joke.

If you need a Python backend with a modern React frontend, full test coverage, and documentation you can hand to a client: That's the gap I built The Unsexy Stack to fill. FastAPI + Next.js 15, 111 tests, 17 PDF guides, 6 architecture diagrams, 44-item security checklist. Starting at $67.

If you want maximum features for minimum cost in Remix: SaaSRock.

If you need a multi-framework option with broad payment provider support: Supastarter.

There's no universal "best." There's the best fit for your stack, your team, your project, and what you value in a foundation.

The Uncomfortable Truth

Most SaaS boilerplates are marketing products first and engineering products second. The sales page has more polish than the codebase. The testimonials are louder than the test suite.

That doesn't make them bad. ShipFast has clearly helped thousands of people ship products. SaaS Pegasus has customers with real revenue. These are successful products that deliver value.

But as a buyer, you should ask harder questions before handing over $149-$999 for code you're going to build a business on. How many tests? What's the security baseline? Can I see how the architecture works before I buy? If the answer is "just trust me"... at least know what you're trusting.

I built The Unsexy Stack because I wanted a boilerplate that treated tests and documentation as first-class deliverables. It's a FastAPI + Next.js 15 SaaS starter available at theunsexystack.com.

The $500K Architecture Mistake I Helped a Startup Avoid

Alex Mayhew — Thu, 09 Apr 2026 02:08:46 +0000

TL;DR

A fintech startup with 8 engineers and $3M ARR was planning a 6-month microservices migration. The "problems" they were solving... deployment coupling, scaling issues, team autonomy... had simpler solutions. We implemented those instead: feature flags, database read replicas, and team-based code ownership. Total time: 3 weeks. They're at $12M ARR now, still on the monolith, shipping features 4x faster than competitors who went microservices.

The Call That Started It

The CTO reached out after reading my piece on boring technology. His engineering team had convinced the board that microservices were necessary for the next phase of growth.

"We're planning a 6-month architecture overhaul," he said. "Before we commit, I want a second opinion."

The plan: decompose their Python/Django monolith into 12 services. Payment processing. User management. Notifications. Analytics. The works.

The justification:

"Deployments are too risky... one change affects everything"
"We can't scale specific parts of the system"
"Teams step on each other's toes"
"It's industry best practice"

I asked one question: "What's the actual problem you're solving?"

Silence. Then: "All of the above?"

The Real Problems

After two days of code review and team interviews, the picture was clearer.

Problem 1: Deployment Fear

They deployed weekly because deployments were scary. One bad merge had caused a 4-hour outage three months prior. The team was traumatized.

Root cause: No feature flags. No gradual rollout. All-or-nothing deployments.

Microservices solution: Isolate services so a bad deploy only affects one domain.

Simpler solution: Feature flags + deployment automation. Deploy daily, roll back in seconds.

Problem 2: Database Bottleneck

Their analytics queries were slow. The main PostgreSQL database was hitting CPU limits during business hours.

Root cause: Heavy reporting queries running against the transactional database.

Microservices solution: Separate analytics service with its own database.

Simpler solution: Read replica for analytics. Takes an afternoon to set up.

Problem 3: Team Conflicts

Two teams kept breaking each other's code. The payments team would change a shared model, and the onboarding team's tests would fail.

Root cause: No clear ownership boundaries. Shared models with unclear contracts.

Microservices solution: Separate services with explicit APIs.

Simpler solution: Module boundaries within the monolith. Interface contracts. Code ownership files.

Problem 4: "Best Practice"

They'd read about how Netflix, Uber, and Amazon use microservices.

Root cause: Pattern matching to companies 1000x their size.

Reality: Netflix has 2000+ engineers. They have 8.

The Math That Changed Their Mind

I walked through the real cost of the microservices migration.

Engineering Time

Task	Estimated Weeks	Engineers
Service decomposition	8	4
API design and implementation	4	3
Data migration and sync	6	2
Infrastructure (K8s, service mesh)	6	2
Testing and validation	4	4
Total	28 engineer-weeks

At their burn rate, 28 engineer-weeks is roughly $250-300K in salary alone. Plus opportunity cost...6 months of features not shipped.

Ongoing Overhead

Microservices aren't free to maintain:

New Requirement	Monthly Cost
Kubernetes cluster	$2-5K
Service mesh (Istio/Linkerd)	Engineering time
Distributed tracing	$500-2K
Log aggregation (12 services)	$1-3K
On-call complexity	Burnout

They'd be spending $5-10K/month on infrastructure they didn't need, plus significant engineering overhead.

The Hidden Cost: Velocity

Here's what microservices advocates don't mention: cross-service features are slower to ship.

Monolith feature: Change database schema, update model, update API, deploy. One PR, one review, one deploy.

Microservices feature: Change schema in service A, update service A API, update service B to call new API, update service C to consume event, deploy all three in order, hope nothing breaks in between.

For a team of 8, this overhead dominates. Every feature touching multiple domains takes 2-3x longer.

What We Did Instead

Week 1: Feature Flags and Deployment Safety

We implemented LaunchDarkly (could have been self-hosted, but speed mattered).

# Before: All-or-nothing feature deployment
def process_payment(user, amount):
    # New payment flow - deployed to everyone or no one
    return new_payment_processor.charge(user, amount)

# After: Gradual rollout with instant rollback
def process_payment(user, amount):
    if feature_flags.is_enabled('new_payment_flow', user_id=user.id):
        return new_payment_processor.charge(user, amount)
    return legacy_payment_processor.charge(user, amount)

Result: Deploy daily. Roll back a feature in seconds. No more deployment fear.

Week 1: Read Replica for Analytics

We spun up a PostgreSQL read replica and pointed all reporting queries at it.

# Database router for Django
class AnalyticsRouter:
    def db_for_read(self, model, **hints):
        if model._meta.app_label == 'analytics':
            return 'replica'
        return 'default'

    def db_for_write(self, model, **hints):
        return 'default'

Cost: $200/month for the replica.

Result: Analytics queries no longer impacted transactional performance. P99 latency on the main database dropped 40%.

Week 2: Module Boundaries

We drew boundaries within the monolith. No code changes... just documentation and ownership.

app/
├── payments/           # Team: Payments
│   ├── models.py
│   ├── services.py     # Public interface
│   └── internal/       # Don't import from outside
├── onboarding/         # Team: Growth
│   ├── models.py
│   ├── services.py
│   └── internal/
├── shared/             # Explicit shared code
│   ├── models.py       # Shared models (minimal)
│   └── interfaces.py   # Contracts between modules
└── CODEOWNERS          # GitHub ownership file

Rules:

Import only from services.py or shared/
Never import from another module's internal/
Shared models require approval from both teams
CODEOWNERS enforces reviews

# CODEOWNERS
/app/payments/    @payments-team
/app/onboarding/  @growth-team
/app/shared/      @payments-team @growth-team

Result: Team conflicts dropped to near-zero. Clear ownership. PR reviews enforced by GitHub.

Week 3: Interface Contracts

For the few places where modules truly needed to communicate, we defined explicit contracts.

# app/shared/interfaces.py
from abc import ABC, abstractmethod
from dataclasses import dataclass

@dataclass
class PaymentResult:
    success: bool
    transaction_id: str | None
    error_message: str | None

class PaymentServiceInterface(ABC):
    @abstractmethod
    def charge(self, user_id: str, amount_cents: int) -> PaymentResult:
        """Charge a user. Returns PaymentResult."""
        pass

# app/payments/services.py
class PaymentService(PaymentServiceInterface):
    def charge(self, user_id: str, amount_cents: int) -> PaymentResult:
        # Implementation
        ...

# app/onboarding/services.py
from app.shared.interfaces import PaymentServiceInterface

class OnboardingService:
    def __init__(self, payment_service: PaymentServiceInterface):
        self._payment = payment_service

    def complete_signup(self, user_id: str, plan_id: str):
        # Use the interface, not the implementation
        plan = self._plans.get(plan_id)
        result = self._payment.charge(user_id, plan.price_cents)
        if not result.success:
            raise PaymentFailedError(result.error_message)

This is the microservices benefit (explicit contracts, independent development) without the overhead (network calls, deployment coordination, infrastructure).

Six Months Later

The results speak for themselves.

Deployment Frequency

Before: Weekly (scared)
After: Daily (confident)

Incident Rate

Before: 1-2 outages/month
After: 1 outage in 6 months (unrelated to architecture)

Feature Velocity

Before: 2-3 features/sprint
After: 5-6 features/sprint

Infrastructure Cost

Before: $8K/month
After: $8.5K/month (+$500 for read replica and feature flags)

Engineering Headcount

Before: 8 engineers
After: 8 engineers (no infrastructure team needed)

Revenue

Before: $3M ARR
After: $12M ARR (12 months later)

They didn't need microservices. They needed discipline.

When Microservices Actually Make Sense

I'm not anti-microservices. I'm anti-premature-microservices.

Microservices make sense when:

1. You have 50+ engineers

At that scale, communication overhead dominates. Microservices let teams work independently. Below 50, the overhead isn't worth it.

2. Services have genuinely different scaling requirements

If your payment processing needs 10x the compute of user management, separate services make sense. But "might need to scale differently someday" isn't a reason.

3. You need different technology stacks

If your ML team needs Python and your API team needs Go, microservices let them coexist. But if everyone uses Python, a monolith is simpler.

4. You have dedicated platform engineering

Microservices require infrastructure: service discovery, distributed tracing, log aggregation, deployment orchestration. Someone has to build and maintain that. If you don't have a platform team, you're signing your product engineers up for infrastructure work.

5. You're breaking up a genuinely problematic monolith

Sometimes monoliths become unmaintainable. But "unmaintainable" means: deploy takes hours, tests take hours, no one understands the full system. Not: "we have some merge conflicts."

Signs you don't need microservices:

Team size under 30
Deploy takes under 30 minutes
Single business domain
No dedicated platform engineering
Scaling is handled by vertical scaling or read replicas
Problems can be solved with feature flags, better testing, or code organization

The Conversation I Have Too Often

Here's how the microservices conversation usually goes:

Startup: "We need to migrate to microservices."

Me: "Why?"

Startup: "Deployments are risky."

Me: "Have you tried feature flags?"

Startup: "No, but microservices would..."

Me: "Have you tried feature flags?"

Startup: "... No."

Me: "Let's try feature flags."

Two weeks later, the "problem" is solved. Six months of engineering time saved.

The same conversation happens with:

"We need Kubernetes" → Have you tried a managed container service?
"We need event sourcing" → Have you tried a transaction log?
"We need GraphQL" → Have you tried REST with sparse fieldsets?

The pattern: complex solutions to simple problems.

The $500K They Didn't Spend

Let's total it up:

Avoided Cost	Amount
Engineering time (6 months × 4 engineers)	$300K
Infrastructure overhead (12 months)	$60-120K
Opportunity cost (features not shipped)	$100K+
Total saved	$460-520K+

And that's conservative. The real cost of shipping 4x slower for a year is incalculable in a competitive market.

The Lesson

The best architecture is the simplest one that solves your actual problems.

Not the problems you might have at 10x scale. Not the problems Netflix has. Not the problems the conference speaker had.

Your actual problems. Today.

When I work with startups, the first question is always: "What problem are we actually solving?" The second question is: "What's the simplest solution that solves it?"

Usually, the answer isn't a 6-month migration. It's a 3-week improvement to what you already have.

This post is part of my SaaS Architecture Decision Framework series. More in the series: Boring Technology Wins, Tech Stack as Capital Allocation, Zero to 10K MRR SaaS Playbook.

I'm Alex Mayhew, a solo developer on Cape Cod. I write about architecture decisions at alexmayhew.dev. Find me on LinkedIn and GitHub.

74% of Startups Fail From Premature Scaling. Your Tech Stack Might Be the Problem.

Alex Mayhew — Thu, 09 Apr 2026 01:26:28 +0000

In 2011, Startup Genome partnered with Berkeley and Stanford to study 3,200 startups. They wanted to know why most fail.

The answer wasn't bad ideas. It wasn't lack of funding. It wasn't competition.

74% of startups that failed did so because of premature scaling. Adding complexity... infrastructure, features, team size, process... before finding product-market fit. The same study found that failed startups wrote 3.4x more code before product-market fit than successful ones.

Let that sit for a second. The teams that survived wrote less code and used simpler architectures. The ones that failed were busy building platforms.

The Conference Talk Problem

Every conference talk, every trending repo, every "modern stack" blog post pushes you toward complexity. GraphQL. Microservices. Event-driven architecture. Server components nested inside client components wrapped in suspense boundaries.

Most of it is engineering for problems you don't have yet.

Dan McKinley... former principal engineer at Etsy... wrote about this in 2015, and the framework has only aged better. Every engineering team gets roughly three "innovation tokens." Chances to use new, unproven technology. Spend them on your product differentiator... not on your web framework, your database, or your deployment pipeline.

If your product's innovation is a novel AI feature, that's where the token goes. Your REST API doesn't need one.

Companies That Started Boring

These aren't hypotheticals.

Shopify runs a Rails modular monolith. In 2024, it handled 173 billion requests on Black Friday weekend. Not microservices. Not a custom framework. Rails. They've refined the architecture over 18 years, but the foundation never changed.

GitHub ran a Rails monolith for 12 years. They didn't start extracting services until they had 1,000 engineers in 2020. One thousand engineers and they were still on a monolith. When they finally extracted services, they did it selectively... not because the monolith couldn't scale, but because the team couldn't coordinate within it anymore.

That's the actual scaling problem: people, not servers.

Stack Overflow ran on 9 on-premise servers for over a decade... a .NET monolith with SQL Server serving billions of page views. They were transparent about this because it contradicted everything the industry said about scaling. In 2025, they migrated to the cloud when their data center contract ended... but the architecture that got them there was deliberately boring for 15+ years.

WhatsApp handled 450 million active users with 32 engineers when Facebook acquired them for $19 billion. The entire engineering team was smaller than most Series A startups.

The Boring Stack Formula

If you're a solo developer or a small team building a SaaS product... here's what "boring" looks like in practice:

One server, two apps. A backend API and a frontend client. Not a service mesh. Not a message queue. Two processes talking over HTTP on the same machine.

A relational database. Your data is almost certainly relational. Users have organizations. Organizations have subscriptions. Subscriptions have invoices. PostgreSQL has handled this reliably for 25+ years. It supports JSON columns for the 5% of your data that's actually document-shaped.

Auth you didn't build yourself. Authentication is a solved problem. It's also one of the most dangerous things to roll your own. Session management, token rotation, OAuth flows, MFA, password hashing... every one of these has security implications that take years to get right. Use Clerk, or Auth0, or Supabase Auth. Your job is to build your product.

Not microservices. You don't have the team for microservices. Microservices are an organizational scaling pattern, not a technical one. They let large teams (50+ engineers) deploy independently. If your team fits in a room, microservices add network calls, deployment complexity, and distributed debugging without giving you anything in return.

REST, not GraphQL. GraphQL is a fine technology for large organizations with multiple frontend clients consuming the same API. If you have one frontend... REST endpoints with clear request/response contracts are simpler to build, simpler to debug, and simpler to cache. You can always add GraphQL later if you actually need it.

When You'll Outgrow This

You will. That's fine.

A single server running FastAPI and PostgreSQL handles 10,000+ concurrent users without straining. The bottleneck, when it comes, will be database queries... not the framework, not the architecture.

Add indexes. Add caching. Optimize the queries showing up in your slow query log. These are straightforward problems with straightforward solutions.

If you reach the point where a single server isn't enough... that's a good problem. It means your product works. People are using it. And by then, you'll have revenue, data, and context to make informed architecture decisions instead of guesses.

The 2026 Bonus

Here's something the Startup Genome study couldn't have predicted in 2011.

Well-documented, widely-used frameworks produce measurably better results with AI coding tools. Cursor, Copilot, and Claude Code all perform better with FastAPI than with a framework that shipped six months ago. The training data is deeper. The patterns are more consistent. The suggestions are more accurate.

Boring tech isn't just safer. In 2026, it's faster to build with.

Now Go Build Something

Your idea is the interesting part. Your users, your market, your product... that's where the interesting decisions live.

The database schema, the API framework, the deployment pipeline... those should be solved problems so you can focus on the unsolved ones.

I built The Unsexy Stack around this philosophy. FastAPI + Next.js 15 + PostgreSQL. Two apps, one server, 111 tests, 17 PDF guides. The foundation that gets out of your way so you can build the thing that matters.

But you don't need my boilerplate to apply this thinking. Pick the boring option. Write less code. Ship sooner. Your architecture doesn't need to be interesting. Your product does.

I'm Alex Mayhew, a solo developer on Cape Cod. I write about engineering decisions that prioritize shipping over impressing. Find me on LinkedIn and GitHub.

AI-Assisted Development: Navigating the Generative Debt Crisis

Alex Mayhew — Thu, 26 Feb 2026 01:55:27 +0000

TL;DR

AI accelerates creation by 55%
AI increases defects by 23.7%
80% of AI code violated architectural patterns
AI code is legacy code on day one

The Productivity Paradox

GitHub's research shows developers complete tasks 55% faster with Copilot.

But velocity isn't productivity. Productivity is value delivered per unit of time.

GitClear analyzed 150+ million lines of changed code:

Projects with heavy AI assistance show 23.7% higher bug-fix ratio
Code "churn" (rewritten within two weeks) increased significantly
Copy/paste code increased 8% year-over-year

Developers write more code faster, then spend more time fixing it.

The Generative Debt Taxonomy

Structural Debt

Code that's technically correct but architecturally wrong.

// AI generated - works but violates architecture
async function getUser(id: string) {
  const response = await fetch(`/api/users/${id}`);
  return response.json();
}

// Your architecture uses a service layer
import { userService } from '@/services/user';
const user = await userService.getById(id);

AI doesn't know your architecture. It generates plausible code based on training data, not your codebase conventions.

Hallucinated Dependencies

AI sometimes suggests libraries that don't exist. For seniors, this is caught immediately. For juniors, it might survive to production.

I worked with a team where a junior used Copilot to generate a validation function. The AI suggested a library that sounded reasonable but didn't exist. The junior created stub functions and moved on.

The code "worked" in development. In production, the validation validated nothing. Cleanup took two weeks.

The Verification-First Workflow

Treat AI code as untrusted input
Review AI suggestions like junior developer PRs
Verify against YOUR architecture, not training data
Test edge cases the AI doesn't know about

Seniors ship 2.5x more AI-assisted code than juniors—not because they use it more, but because they can validate the output.

Key Takeaways

AI is a powerful tool, but tools require skill to use safely
96% of devs don't trust AI output, but 50%+ don't review it carefully
Establish who's responsible for reviewing AI-generated code on your team
AI code is legacy code on day one

Originally published on alexmayhew.dev

Choosing Your Tech Stack: A Capital Allocation Framework

Alex Mayhew — Tue, 17 Feb 2026 14:00:00 +0000

TL;DR

Labor costs = 50-70% of engineering opex
Your stack determines your hiring pool
Rust premium: $175K-195K (15-20% above baseline)
Seed stage: optimize for speed. Growth: optimize for scale. Enterprise: optimize for efficiency.

The Stack as Investment Thesis

Your technology stack is a capital asset with three measurable properties:

Total Cost of Ownership (TCO): Hiring costs, infrastructure, maintenance
Liquidity Profile: How easily can you hire? How quickly do they ramp?
Depreciation Schedule: How fast does technical debt accumulate?

CFOs evaluate capital assets on these dimensions. CTOs should evaluate stacks the same way.

The Hiring Liquidity Matrix

Ecosystem	Pool Depth	Time-to-Hire	Seniority Profile
JavaScript/TypeScript	Deep	30-40 days	Mixed, high junior volume
Python	Deep	35-45 days	Data science skewed
Go	Moderate	40-50 days	Cloud-native focus
Rust	Constrained	45-60+ days	Senior specialists

For a Series A with 10 engineers, choosing Rust over Python implies $300K-500K extra annual payroll. That capital could extend runway by months.

The Innovation Tokens Framework

Organizations have limited capacity for technical novelty—roughly three "innovation tokens."

Good token spend: An AI startup uses a novel model architecture. The model IS the product.

Bad token spend: An AI startup uses novel models AND a beta database AND an experimental framework AND bespoke deployment. Four tokens spent, three on non-differentiation.

When Postgres fails, Stack Overflow has the answer. When your six-month-old vector database fails, you're on your own.

The CTO Decision Matrix by Stage

Seed (0-10 Engineers): Optimize for Speed

Stack: Python/Django, Rails, or Next.js
Architecture: Monolith
Goal: Product-market fit

Growth (20-50 Engineers): Optimize for Scale

Introduce Go/Rust for specific bottlenecks
Profile first, optimize second

Enterprise (100+): Optimize for Efficiency

Polyglot architecture
Kubernetes or hybrid for cost control

Key Takeaways

Stop asking "what's the best stack?"
Start asking "what stack minimizes TCO at our current stage?"
The answer is almost always more boring than you'd expect

Originally published on alexmayhew.dev

The Senior Developer Paradox: Why Expensive Talent Saves Money

Alex Mayhew — Wed, 11 Feb 2026 00:00:47 +0000

TL;DR

Junior at $30/hr with 50% rework = $90/hr actual cost
Senior at $150/hr with 10% rework = $175/hr actual cost
Bug fix costs: $100 (design) → $1,000 (coding) → $10,000 (QA) → $100,000+ (production)
Seniors ship 2.5x more AI-assisted code than juniors

The Sticker Price Fallacy

The calculation most finance teams run:

Option	Hourly Rate	Annual Cost
Offshore Junior	$30/hr	$60,000
US Senior	$150/hr	$300,000

Five developers for the price of one, right?

Wrong. This ignores the Hidden Ledger: rework, bug fixes, architectural mistakes, and management overhead.

The actual calculation:

Factor	Junior	Senior
Nominal Rate	$30/hr	$150/hr
Time Fixing Own Bugs	50%	10%
Effective Rate	$60/hr	$166/hr
Management Overhead	+25%	+5%
Actual Cost	$90-100/hr	$175/hr

The gap narrows considerably.

The Rule of 100

Barry Boehm's research established that defect costs increase exponentially through the development lifecycle:

Stage	Cost to Fix
Requirements/Design	~$100
Coding/Unit Testing	~$1,000
Integration/QA	~$10,000
Production	~$100,000+

Senior developers don't just write better code. They "fix" bugs before writing them.

The AI Paradox

A 2025 Fastly survey found senior developers ship 2.5x more AI-assisted code than juniors.

Why? Seniors can validate AI output. They spot when AI hallucinates an API that doesn't exist or generates code with subtle security vulnerabilities.

Juniors either don't trust AI (underutilizing it) or trust it too much (shipping bugs they can't diagnose).

AI makes senior developers more valuable, not less.

Key Takeaways

Stop optimizing for hourly rate; optimize for cost per unit of delivered value
The $2.41 trillion annual cost of poor software quality isn't hourly rate differentials—it's architectural decisions that burden teams for years
Expensive talent often costs less in total cost of ownership
AI amplifies the senior-junior gap, not closes it

Originally published on alexmayhew.dev

Why Boring Technology Wins: Lessons from Unicorn Migrations

Alex Mayhew — Tue, 03 Feb 2026 14:00:00 +0000

TL;DR

Segment: 140 microservices → monolith (velocity recovered)
Prime Video: serverless → monolith (90% cost reduction)
Instagram: 14M users with 3 engineers on PostgreSQL + Python
Pattern: start boring, migrate when you have proof

The Known Failure Modes Principle

When Postgres fails, Stack Overflow has the answer. When your custom database fails, you're on your own.

Boring technology—mature, widely-adopted, battle-tested—has a decisive advantage: its failure modes are documented. Thousands of engineers have hit the same problems and shared solutions.

Novel technology offers no such safety net. When things break, you're pioneering the debugging.

Case Study: Segment's Microservices Retreat

Segment adopted microservices early. The architecture grew to 140 distinct services.

What happened: A change to a shared library required redeploying all services. Testing became a nightmare. Local development required spinning up dozens of containers.

The reversal: They consolidated back to a monolith. Simplified testing, recovered engineering velocity, reduced operational complexity.

The lesson: Microservices solve organizational problems, not technical problems. For teams under 50 engineers, a modular monolith is almost always right.

Case Study: Amazon Prime Video

Prime Video's audio/video monitoring service was built on Lambda and Step Functions.

The problem: Data transfer between distributed components became expensive. They hit scalability ceilings.

The pivot: Refactored to a single monolith on ECS.

The result: 90% infrastructure cost reduction.

The Counter-Intuitive Truth

Company	Initial Stack	Scale Achieved
Instagram	PostgreSQL + Python	14M users with 3 engineers
Shopify	Ruby on Rails	From launch through IPO
GitHub	Ruby on Rails	The world's code repository

These companies chose boring technology because developers were immediately productive, hiring was easy, and they could focus on product instead of infrastructure.

Key Takeaways

Start with boring, migrate when you have data proving you need to
Microservices are for organizational scaling, not technical scaling
The cost of debugging novel technology compounds faster than its benefits
Instagram scaled to 14M users with PostgreSQL—your startup can too

Originally published on alexmayhew.dev