The Honest Economics of Free SDKs: Why We Give Away 200 MIT Components

You'd be right to be skeptical. A free SDK with roughly 200 MIT-licensed components on npm, plus a paid tier that wraps them — that's either a bait-and-switch with a rug-pull scheduled for next quarter, or a generous bet on distribution. It's the second one. Here's why the line between free and paid sits where it does, and why we think moving it would be a worse business.

What the free SDK actually gives you

Three packages, one mental model.

npm install @otfdashkit/ui @otfdashkit/ui-native @otfdashkit/tokens

That's the entire install. ui for web, ui-native for iOS and Android, tokens for the theme primitives. Same component name, same props, same look on every platform — write <Button> once and the kit ships it everywhere from one codebase.

import { Button, Card, TextField } from "@otfdashkit/ui"

export function Signup() {
  return (
    <Card>
      <TextField label="Email" type="email" />
      <Button intent="primary">Create account</Button>
    </Card>
  )
}

The same file works on web. Swap the import to @otfdashkit/ui-native, the same JSX renders on iOS and Android. No fork, no platform-specific component name, no "this prop only exists on web." Tokens flip one theme across web and mobile, so the component is visually identical everywhere.

The SDK is MIT. Fork it, vendor it, ship it inside a private monorepo — all fine. We don't gate components behind a license check, a telemetry ping, or a build-time flag. The components are the floor, not the funnel.

What the paid kits actually buy

Components are atoms. Kits are buildings. The line isn't generosity — it's where the work is.

A full-stack kit is the same components, wired together with the boring stuff that takes weeks to get right:

• Auth (signup, login, password reset, sessions, OAuth)
• Billing (Stripe checkout, webhook handling, plan upgrades, invoices)
• Database schema and migrations
• Production deploy (custom domain, DNS, TLS, mobile build)
• AI-tool configs (CLAUDE.md, .cursorrules, 20+ tested prompts under ai/prompts/)
• A 24-item design checklist enforced by a script before the kit ships

That's the SaaS Dashboard kit. The Fitness kit is the same shape for mobile-first apps; Booking is the same shape for scheduling. Each one is $99. The Everything Bundle is $149.

// what the SaaS Dashboard kit ships, roughly
app.post("/api/billing/webhook", verifyStripeSignature)
app.post("/api/auth/login", rateLimit({ window: "15m", max: 5 }))
app.post("/api/auth/signup", createUser, sendVerificationEmail)
app.get("/api/me", requireSession, getCurrentUser)

This isn't a UI component. It's a server file with auth and billing wired end-to-end. You didn't write it. You can't generate it in one prompt — the prompts that build it ship inside the kit at ai/prompts/, and the agent extends the kit instead of regenerating it.

Where the line sits, and why it doesn't move

The honest line: atoms free, wiring paid.

Components are commoditized. A Button is a Button. The interesting work is the integration — the auth state machine, the Stripe webhook handler that reconciles subscription state, the DNS+TLS pipeline that takes a custom domain to a signed certificate in one command. That's where the weeks go.

Free SDK earns the right to charge for the kit in three concrete ways:

1. Distribution. A package on npm gets installed. A landing page gets bookmarked. Distribution compounds — every install is a future kit sale that didn't need an ad.
2. Trust. Shipping 200 components under MIT and not rugging them is a credible signal. It's hard to fake. The components stay free because moving them would destroy the trust that funds the paid tier.
3. Onboarding cost. A developer who already wrote their prototype with the free SDK buys the kit at the moment they hit production. That's a natural upgrade path, not a forced one.

The line moves the day we change the SDK license. It doesn't.

What "free forever" means, concretely

Three guarantees baked into how the SDK is shipped:

• New components ship free. We're not gating future work behind a paid plan to drive upgrades.
• The license doesn't change. MIT today, MIT tomorrow.
• No telemetry, no license check, no "free for non-commercial use." The npm install works the same in a hobby project and a Series B startup.

The line is stable because moving it would be the short-term-revenue-maximizing move that kills the long-term business. A bait-and-switch works once. A credible free tier compounds.

What this gets you, day to day

The developer flow looks like this:

1. Install the free SDK. Build a prototype on Saturday. The components are MIT — no anxiety about the rug-pull.
2. Hit production. Real auth, real Stripe, real deploy. Buy the kit.
3. The kit uses the same components. No re-learning. No "we open-sourced a worse version of what you're using."
4. Ship with the deploy script that comes in the kit — point it at your domain, and it wires DNS, issues the TLS certificate, ships the web build, and queues the mobile build.

That script isn't a free feature. It touches DNS providers, certificate authorities, build pipelines, and app store submission flows. It's expensive to maintain, and it's the part you actually need the moment you stop prototyping. The design checklist is the same kind of thing — it's a script that runs before the kit ships, so the 24 items that usually bite you in week six are already handled.

The alternative, and why we didn't pick it

Cursor, Lovable, Bolt, v0 — they all have a similar shape: free preview, paid agent, locked-in flow. The bait is a screenshot of a generated app. The lock is everything you can't take with you when you leave.

We picked the opposite shape. The components are MIT and leave with you. The kit is paid because it's the part that has to be maintained against Stripe API changes, OAuth provider drift, and TLS certificate renewal. We're betting the boring infrastructure is what you actually need, not the demo.

The same principle applies in reverse to the alternatives: their free tier is the demo. Our free tier is the production primitive. Different bets, different lines. The 15 landing templates at $9 each sit on a third axis — page-shaped, not full-stack — and they exist because shipping a marketing page shouldn't require a full-stack kit.

The honest answer to "why free?"

Not because we're generous. Because the components are the right thing to give away — they're commoditized, they're the trust-building surface, and they're the distribution channel for the kit. Charging for them would mean charging for the wrong thing.

The kit is paid because the kit is the building. Auth, billing, deploy, AI configs, the design checklist — that's where the weeks go. The line between "free forever" and "paid" sits exactly there, and it's a stable line.

If you're reading this and you're still skeptical: good. The SDK is on npm. Install it. Ship a prototype. The free tier is what we say it is. When you hit the wall where wiring matters, the kit is there — built from the same components you already know.