# 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.

Source: https://boringpush.com/blog/makerkit-alternative

## 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.**

```js // 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.**

```md 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.**

```bash
# 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

- [MakerKit vs BoringPush: Subscription vs $199 Once](/blog/makerkit-vs-boringpush) — the head-to-head this math decides
- [requirePaidUser(): One Boolean, Zero Paywall Holes](/blog/requirepaiduser-paywall-one-boolean) — the boolean both posts center
- [Admin Allowlist: Stop Paying Customers Entering Admin](/blog/admin-allowlist-nextjs-saas) — the 5-line admin beside the boolean