Build vs buy: the API integration question every startup gets wrong

Where this comes from

I'm 23. I spent two years working at a product-based SaaS company, and I'm currently transitioning to a German startup as my main job while building VedaStack on the side. So no, I haven't scaled ten companies to Series B. But I've worked on enough full-stack projects and seen enough codebases to have a pretty clear picture of where engineering time gets wasted.

The most common waste I've seen: teams building things that have already been solved, for free, by someone else. Auth systems, billing modules, custom email servers. All of it built from scratch, all of it a distraction from the actual product.

This post is my honest take on what to buy and what to build, at different stages of a product. It's not comprehensive. It's just what I'd do.

Auth: just buy it, Clerk is free

I'll keep this short because there's not much to debate. Clerk gives you login, signup, password reset, OAuth providers, MFA, session management, and a user management dashboard, all with pre-built UI components and clean SDKs for React, Next.js, and most backend frameworks. The free tier covers you comfortably through early traction.

They also now have Clerk Billing, which handles subscriptions and paywalling features directly inside your auth layer. It's newer but worth knowing about if you want auth and billing in one place.

Even Turso uses Clerk. These are people who write database internals for fun, and they didn't build their own auth. That's really the only case you need.

The only reason to reconsider Clerk is if you're at serious scale with specific compliance requirements, SOC2, HIPAA, that kind of thing, and you need an on-prem solution. That's not a startup problem. Deal with it when you get there.

Billing: Stripe, no debate

Building payments yourself means dealing with PCI compliance, card tokenisation, webhook idempotency, failed payment retries, proration logic for plan changes, dunning management, invoice generation, and tax. This is genuinely months of engineering time done properly.

Stripe charges 2.9% + 30¢ per transaction. That is not a cost worth optimising at early stage. It becomes negotiable at serious revenue volumes. Until then, every hour you spend building billing is an hour you're not building your product.

I've seen a team spend four months building a custom billing system to save on Stripe fees. By launch they'd spent more in salary than three years of Stripe fees would have cost. The maths never works out.

Stripe Billing handles subscriptions and trials. Stripe Tax handles global tax. Stripe Radar handles fraud. Use them.

The database question

This is where I'll push back on the "just buy managed services" crowd. My position is straightforward: don't pay for a managed database until you genuinely have to.

Early stage: Turso

Turso is a SQLite-based distributed database with a free tier that's actually usable, 100 databases, 5GB storage, 500 million row reads per month, 10 million row writes per month. For a startup in its first year that's more than enough. It's fast, has clean SDKs, and runs on libSQL which is open-source, so you're not locked in if things change.

One thing I've learned from actually using Turso: index your tables properly from day one. I'm not joking, a missing index on a table that grows fast will eat through your free read quota faster than you'd expect. Speaking from experience here. Add indexes early, thank yourself later.

Growing stage: self-host PostgreSQL

Once you have consistent traction, get a VPS and run PostgreSQL yourself. A Hetzner or Vultr instance costs a fraction of what managed services like AWS RDS or Supabase charge at scale. Postgres on a VPS barely needs managing day to day. Set up backups to S3 with a cron job or pgBackRest, add basic monitoring, and you're done.

The "we don't have to manage it" argument for managed databases sounds nice until you see the bill. I've watched teams pay $400/month for a managed Postgres instance that would run for $20/month on a VPS with better I/O performance. Self-hosting Postgres is not scary. It's just Postgres.

Notifications and email: build these yourself

Notifications and transactional email are two of the easiest things to build and two of the most overpriced managed services out there. Build them.

For email, use Resend or Mailgun as the SMTP relay for delivery, but write your own templates, your own queue, your own retry logic. That's maybe 200 lines of code. The platforms charging $200/month for "email infrastructure" are billing you for abstractions you don't need.

For in-app notifications, a database table, a Go worker processing a queue, and a WebSocket or SSE endpoint is genuinely all you need in the early stages. Novu is worth knowing about when things get complex, it's open-source and self-hostable. But most products don't need it until they're well past MVP.

For mobile push notifications, use Firebase Cloud Messaging directly. It's free, reliable, and the SDK is well-maintained. Don't pay another service to wrap it.

Infrastructure: serverless until 5k MAU, then VPS and Go

Before 5,000 monthly active users, serverless is a reasonable default. Vercel for the frontend and API routes, Cloudflare Workers for edge logic if you need it. Zero ops overhead while you're figuring out if the product works is genuinely worth something.

Past 5k MAU, get a 2-core VPS and run your backend in Go. A Hetzner CX22 is about €4.5/month. A Go binary on that machine will handle thousands of concurrent requests without much complaint. I covered why in the previous post on Golang vs Node.js, but the short version is that goroutines are cheap and Go's memory usage under load is very predictable. Put Caddy in front of it for automatic TLS and deploy with GitHub Actions. That's really the whole setup.

The inflection point that teams miss: they hit 5k users, the Vercel bill starts climbing, and they keep paying it because migration sounds scary. It takes maybe two hours to set up properly and the cost difference is immediate.

What we're doing at VedaStack right now

We're currently building an image optimisation and caching service at VedaStack. It's early, but it's real, and it's a good example of how this framework actually plays out in practice.

For auth and billing we're using Clerk, including their new billing product to handle subscriptions. For the database we're on Turso (and yes, I've already learned the hard way about indexing on a read-heavy table). The image processing API runs in Go on Vultr, which has been a good fit for the workload since image processing is CPU-bound and Go handles that concurrency well.

Could we have built our own auth? Yes. Would it have been a good use of time while also building the actual product, transitioning jobs, and trying to get early users? Absolutely not. That's the whole point of this post.

The decision table by stage

Yes, zero. A properly structured early-stage product can run its entire infrastructure on free tiers while generating revenue through Stripe. The moment you're paying transaction fees, you're making money, and at that point 2.9% is not a problem worth solving.

The rule I keep coming back to: buy anything that is not your core product, build anything that is. Auth is not your product. Billing is not your product. The database engine is not your product. These are table stakes, and they're solved. Spend your time on the thing only you can build.