alternative · comparison · tutorial

MakerKit Bills Teams. Solos Pay Anyway.

Team-shaped kits tax solo founders with seats and structure. The solo math plus the bridge quarter when hiring starts. Inside.

An 1882 engraving of a street musician with a drum on his back, pan pipes on his chin and a mandolin, facing a small boy holding out his cap
An 1882 engraving of a street musician with a drum on his back, pan pipes on his chin and a mandolin, facing a small boy holding out his cap · Photo: G. Wahlbom, public domain, via Wikimedia Commons

An org chart bought for one employee

Solo, buying the team-shaped kit: roles tables never filled, invitation flows with one invitee (twice), per-seat pricing for seats occupied by aliases. The structure sat there — maintained, updated, paid for — serving an organization of one with the efficiency of a stadium for jogging.

Worse: every feature built navigated team abstractions (tenant contexts, permission checks, seat validations) that added code without users. Solo apps carry team-shaped weight in every request, every review, every debug session.

Makerkit alternative thinking: buy the org chart the quarter it forms, never before. Until then, every seat-shaped dollar is optional burn.

Team-shaped vs solo-shaped costs

Cost Team kit (solo user) Solo kit
Upfront price Tiered (teams plans) $199 once
Per-seat meters Running (your aliases!) $0 (no seats exist)
Code weight per request Tenant + roles + checks Paywall boolean
Debug surface Permission matrices One guard
Hiring readiness Day one (unused) Bridge quarter (when real)

Three details make premature structure rot:

  1. Seats meter ghosts. Per-seat pricing counts invitations, service accounts, and your own test aliases — the meter runs on org-chart theater, not humans. Solo founders routinely pay team prices for audiences of one. Seats should follow hiring, never precede it.
  2. Abstractions tax every feature. Tenant scoping, role checks, invitation states — each adds branches to code one human reads and debugs. Complexity unmaintained becomes vulnerability wearing process; unneeded complexity becomes both slower. Simple code reviewed beats structured code assumed.
  3. Readiness rusts unused. Roles designed pre-hire fossilize around imagined workflows; real hiring brings real needs the imagined structure never matched. Prepared structures get replaced anyway — readiness without requirements is speculation with maintenance costs. Build org shape from hiring reality, not kit defaults.

The vs-post ran the head-to-head. This is the solo math that decides it.

Makerkit alternative solo path

Flat solo now, bridge deliberately at hiring, never pay for ghosts.

Step 1 — Run solo-shaped: boolean paywall, zero seats.

// access model (entire file, conceptually):
// one paid-access check → 401/403/access. No roles, no tenants, no invitations.
// admin: email allowlist (5 lines). Teams: absent (correctly — no team exists).

One boolean gates everything; allowlist guards admin; nothing else exists to maintain, debug, or bill. Features ship without navigating org abstractions (no tenant context threading, no permission matrices). Solo code reads like solo thinking: direct, complete, fast. Absence of structure is a feature until hiring.

Step 2 — Price the hiring quarter before it arrives.

bridge budget (known upfront, executed on hire-one signs):
month 1: roles table + middleware (column + guard, days not weeks)
month 2: invitations (token emails, magic-link plumbing reused)
month 3: audit trails (money paths first), review queues (where pain felt)

Bounded, sequenced, calm — the bridge quarter converts solo to team-shaped deliberately, each step landing on thin routes without disturbing the rest. Knowing the price upfront defuses FOMO buying (team kits sell fear of future migrations; the bridge costs days, planned). Fear priced is fear defused.

Step 3 — Migrate patterns, not platforms, if switching.

# MakerKit → solo-shaped (or reverse): routes copy per thin-file shape,
# billing verbs map 1:1 (Stripe-centric both), auth sessions re-link by email
# weekend migration, tested per route, paywall verified per surface

Thin files migrate weekends; tangled platforms migrate quarters. Either direction costs days because both shapes share the underlying primitives (routes, providers, guards). Direction changes are preferences with price tags, not marriages with lawyers. Switch on evidence (hiring happened / didn't), never anxiety.

Simple as that — org charts on demand, never in advance.

Solo math, year one

Year solo Team-shaped kit Solo-shaped kit
Stack spend Tiered ($300+?) $199 once
Seat meters Running (ghosts!) $0
Feature code weight Tenant-aware everywhere Direct
Debug hours on permissions Real (unused system!) Zero (no system)
Hiring readiness Rusting Bridge quarter, planned

To be straight about it: solo-shaped hits a wall at hire two (roles needed yesterday, bridge takes weeks) — teams forming fast feel the gap acutely.

BoringPush prices the wall against years of ghost-free soloing: bridge quarters are planned projects, ghost seats are permanent bleed.

Flat until hiring, structured at hiring, never before.

FAQ

Is makerkit alternative just "cheaper" framed as philosophy?

No — cheaper is the side effect; shape-fit is the argument (solo code without team weight, meters without seats, reviews without matrices). A free team kit would still cost complexity, debugging, and billing ghosts. Price matters less than fit: right-shaped code at any price beats wrong-shaped at zero. Fit first, invoice second.

What if I hire within months — still start solo?

Yes, unless offer letters are signed: "might hire" has funded infinite premature structure, while bridge quarters handle actual hiring in weeks. Probability-weighted: likely-hire-soon still favors solo-start (bridge cost < ghost cost over the gap). Start solo, bridge on signature, never on maybe. Signatures trigger structure; speculation triggers waste.

Do investors prefer team-shaped codebases ("scalable")?

Investors prefer traction (revenue beats architecture in every diligence room). Solo-shaped code shipping beats team-shaped code configuring — demos close rounds, permission matrices don't. Scale shape at Series A with Series A headcount; pre-seed structure is costume. Shipments persuade; scaffolding merely suggests.

How do roles actually retrofit onto boolean paywalls?

Column plus guard (roles table, middleware check) → invitations (token emails) → audit trails (money first) — the bridge quarter sequenced, each step days on thin routes. Boolean remains the base (paid?), roles layer above (which seat?). Layered, not replaced: additive structure, same law as migrations. Retrofit by addition, never rewrite.

Should cofounder pairs start team-shaped?

Two humans: still solo-shaped (pair ≠ org — no HR, no roles matrix, shared everything). Past ~3 humans with distinct duties: reassess (access differences emerging?). Headcount three is the honest inflection, not two. Pairs ship fastest on solo rails; orgs form later than founders fear, earlier than code admits.

When is team-shaped from day one correct?

Funded teams hiring immediately (offer letters signed, roles defined, day-one headcount 3+): structure serves real humans from the start, no ghosts involved. Funded-and-hiring is the only pre-hire structure case — money plus bodies plus duties, all present. Everyone else: solo rails until the org chart has names, not hopes.

Keep reading

+ all the boring stuff (analytics, auth, SQLite ↔ Supabase, full marketplace, webhooks)

The Agent-First Shipping Kit

Command from your phone.

Built so autonomous AI agents build what you want without breaking what's already paying you.

$199

Get BoringPush

One-time payment · Lifetime updates · Unlimited projects.

Keep reading