# The Integration Tax: What a Kit Should Pre-Wire for Solo Builders > Explore the hidden costs of integrating essential services and how a pre-wired kit can simplify the process for solo developers. > By Dave · 2026-07-19 > Source: https://otf-kit.dev/blog/the-solo-builder-tech-stack-tax A dozen accounts before the first user logs in. That's what "just add auth, payments, and email" actually means in 2026 — auth, DB, payments, email, analytics, error tracking, deploy, storage, background jobs, feature flags, support chat, uptime monitoring. Each is a separate signup, a separate "Getting Started" doc, a separate API key in `.env.local`, a separate webhook URL, a separate pricing page you'll revisit the day your traffic spikes. This is the integration tax. It's the actual cost of shipping a real product as a solo builder — not the framework, not the database, the integrations. This post is about the line between what a kit should pre-wire for you and what it should leave alone, and where OTF draws that line on purpose. ![a stack of vendor tabs in a browser, the solo builder's desk](https://cdn.otf-kit.dev/blog/the-solo-builder-tech-stack-tax/inline-1.png) ## What "pre-wired" actually means A pre-wired kit is not "we picked a vendor for you." It's "the wires are already soldered." When a kit pre-wires Stripe, it means: - The webhook endpoint exists at `/api/stripe/webhook` and the signature is verified. - The customer record is created on checkout. - Subscription state is mirrored to a `subscriptions` table on `customer.subscription.created`, `updated`, `deleted`. - The env vars have stable names: `STRIPE_SECRET_KEY`, `STRIPE_WEBHOOK_SECRET`, `STRIPE_PRICE_ID_*`. - A button in the user dashboard opens the Stripe customer portal. What pre-wired is NOT: - A folder called `integrations/` with a file called `stripe.tsx` containing `// TODO: your code here`. - A README that says "just plug in your Stripe key." - A vendor SDK copied into `vendor/` that you'll fork on day one. A kit that hands you a folder of stubs is not saving you time. It's billing you for the stubs at the same rate you'd pay for the real thing, with extra setup steps. ## The four things OTF ships wired In the SaaS Dashboard kit, four things come out of the box with the wires already soldered. **Auth.** Sign-up, login, session, password reset, email verification, OAuth. The session check is server-side — not a client redirect that a determined user can bypass: ```ts // Server-side gate, not a client redirect export async function requireUser() { const session = await getSession() if (!session?.userId) redirect('/login') return session } ``` **Billing (Stripe).** Subscription create, webhook handler with signature verification, customer portal link from the dashboard. The webhook handler is the load-bearing piece — without it, your DB drifts from Stripe's truth and you find out the day a charge fails. ```ts // Verify the signature before trusting the body export async function POST(req: Request) { const sig = req.headers.get('stripe-signature') const body = await req.text() const event = stripe.webhooks.constructEvent( body, sig!, process.env.STRIPE_WEBHOOK_SECRET! ) switch (event.type) { case 'customer.subscription.created': case 'customer.subscription.updated': await syncSubscription(event.data.object) break case 'customer.subscription.deleted': await cancelSubscription(event.data.object) break } return new Response(null, { status: 200 }) } ``` **DB.** Schema, migrations, query helpers. Opinionated enough that the common SaaS shapes (users, workspaces, subscriptions, audit log) are already there — plain SQL you can extend, not a black box you can't debug. **Deploy.** One script wires a custom domain + DNS + TLS + a mobile build. You run it once. It does not become your weekend. ![pre-wired by OTF vs your call](https://cdn.otf-kit.dev/blog/the-solo-builder-tech-stack-tax/inline-2.png) ## The four things OTF deliberately leaves to you These are not oversights. They are decisions. **Analytics.** PostHog, Plausible, Umami, Fathom, Google Analytics, a self-hosted Countly instance — they encode different philosophies about cookies, retention, data ownership, and pricing cliffs. The right answer for a privacy-first B2C tool is not the right answer for a sales-led B2B SaaS. OTF leaves analytics to you because the choice is data-philosophy, not plumbing. **Error tracking.** Sentry's free tier has a hard event cap; Rollbar's pricing is per-user; Highlight is generous on events but young; GlitchTip is self-host-and-pray. Most side projects don't need this on day 1, and a kit that ships Sentry wired is signalling "you must need this," which is the wrong default. Add it when you have users to lose. **Email.** Resend, Postmark, SendGrid, AWS SES for transactional; ConvertKit, Loops, Beehiiv for marketing. Deliverability for password resets is not the same game as deliverability for a newsletter. A kit that pre-wires "email" has either picked the wrong vendor for half the use cases or written an abstraction so leaky it's worse than just picking one. Pick your transactional provider on day 1, pick your marketing provider when you have a list. **Uptime monitoring / status pages.** Better Stack, UptimeRobot, Cronitor, Oh Dear. Most are 10-minute setups with their own dashboard — they don't need to live in your codebase. A status page is a thing your users visit, not a thing you import. The pattern in all four: the choice is a function of your project, not your framework. A good kit stays out of the way. ## The rule of thumb for what gets wired A kit should pre-wire an integration when both conditions hold: 1. **Every project needs it the same way.** Auth is auth. Billing is billing. The shape doesn't change based on your idea. 2. **The kit can stay vendor-neutral.** Stripe is a vendor, but the kit only depends on Stripe's webhook shape, not Stripe's UI. Sentry is a vendor, and Sentry's SDK shape leaks into your call sites — so a kit that pre-wires Sentry has made a vendor call, not a vendor-neutral abstraction. A kit should leave it alone when: - The right vendor depends on data philosophy (analytics, marketing email). - The right time to add it depends on your stage (error tracking, monitoring, feature flags). - The choice is a marketing call (support chat tool, pricing page tool). - It's already a 10-minute setup with its own dashboard (uptime monitoring). ## What this gets you Clone the SaaS Dashboard kit. Set `STRIPE_SECRET_KEY`, `STRIPE_WEBHOOK_SECRET`, and the price IDs. Run the deploy script. By Sunday evening the four hardest pre-wired pieces are running; you spend the week on the thing that actually differentiates your product. And because the kit's billing module talks to Stripe only at the webhook boundary, swapping Resend for Postmark or PostHog for Plausible later is a config change, not a refactor. The kit doesn't lock you into the choices it makes for you — it just refuses to make the choices that should be yours. ![request flow for a Stripe webhook — checkout → Stripe → /api/stripe/webhook → signature ve](https://cdn.otf-kit.dev/blog/the-solo-builder-tech-stack-tax/inline-3.png) The integration tax is real. It's the most boring reason side projects stall out — not because the idea was bad, but because the builder ran out of Saturday wiring the same half-dozen things every SaaS needs. Pre-wire what every project needs the same way. Leave the rest to the person who knows the project best: you.