Running a Real Software Company on Free Tiers in 2026

There's a version of "we run on free tiers" that's a humblebrag, and there's a version that's an actual operating strategy with real edges you learn by hitting them. I want to write the second one. We're a five-engineer studio running eight products, and a genuinely large fraction of our infrastructure bill is still zero — not because we're scrappy heroes, but because the free tiers on the tools we already needed are wide enough that paying would be premature for where we are.

Here's the honest audit, tier by tier, including the part where we nearly ran out.

Where free is still free

Vercel hosts our marketing site and the frontend for most of our web products. The Hobby tier's bandwidth and build-minute limits haven't been the constraint for us — our traffic is real but not viral, and static-heavy pages plus Next.js's caching keep us comfortably inside the free ceiling. We pay for Vercel on exactly one product, the one with genuine production traffic and a team that needs the collaboration features, and everything else rides free.

Convex runs the backend for four products — Wryte, OurTrail, envpilot.dev, and LUMO's companion. This is the one we came closest to actually breaking, and it's worth being specific: we hit our free-tier Database I/O quota mid-year, not from user traffic, but from our own development pattern — a shared dev deployment across products with schema-heavy features under active build, plus queries that weren't paginated and were rescanning more than they needed to. The fix wasn't "upgrade to Pro," it was "stop wasting I/O" — indexed queries instead of table scans, store-backed feature gates instead of re-fetching the tier config on every check, cron jobs with sane floors instead of polling constantly. We haven't upgraded yet. We might this year, on genuine production usage rather than our own carelessness, which is the distinction that actually matters when you're deciding whether a free tier is "too small" or you're just using it wrong.

Resend handles transactional email — signup confirmations, invite links, notifications — at 3,000 emails a month on the free tier. We've never come close to that ceiling across four products with real users, because transactional email volume tracks active-user actions, not total users, and our active-user counts are still small enough that 3,000 is comfortable headroom, not a tight fit.

Loops runs marketing and lifecycle email — onboarding sequences, product updates — at 1,000 contacts free. This one we're closer to outgrowing on our largest list, and it's the free tier I'd bet moves to paid first among the email tools, because contact-list growth compounds in a way transactional-volume growth doesn't; every new signup is a contact forever, but not every signup triggers many transactional sends.

Cloudflare handles DNS and email routing — forwarding hello@ and a handful of role addresses to real inboxes without running a mail server — across every domain we own, entirely free. This is the one that surprised me most going in: I expected DNS-and-email-routing to be a paid utility eventually, the way registrars upsell you on "professional email." Cloudflare's free tier has just... kept being free, for a use case (routing, not hosting mailboxes) that a lot of teams don't realize doesn't need a paid mail provider at all.

The 12 days that nearly burned GitHub Actions

This is the story worth telling in full, because it's the sharpest lesson in the whole audit.

GitHub gives every account 2,000 free Actions minutes a month. We'd never come close to that limit in two years of normal usage — a monorepo with reasonably tight CI, a handful of pushes a day, nothing exotic. Then, over a roughly two-week stretch, we watched the usage graph climb in a way that didn't match our push volume, and by day 12 we'd burned through most of the monthly allotment with weeks still left on the clock.

The cause, once we dug in: it wasn't the web app's CI. It was our end-to-end Playwright suite, which at the time was wired to run against a cloud Convex dev deployment for every push to certain branches, including branches that got pushed to constantly during active feature work. Every e2e run was spinning up real Convex function calls against a real cloud deployment, and the Actions minutes for orchestrating that suite — not the Convex I/O itself, a separate quota we'd already gotten burned on once — were climbing because the suite itself had gotten slower and heavier as we added coverage, and it was running more often than it needed to on branches that weren't near merge-ready.

The fix was blunt and, in hindsight, obviously correct: we paused the e2e gate in CI entirely. It's hard-disabled in the workflow file right now, and the full Playwright suite runs locally, by a human, before every merge — the only gate of record while it's off. That's a real tradeoff — CI no longer catches an e2e regression automatically before a human looks at it — and we've accepted it deliberately rather than let the Actions bill or the Convex quota become a recurring surprise. The permanent fix, which we've scoped but not yet built, is running e2e against a self-hosted local Convex backend inside the CI runner instead of a cloud deployment — zero cloud quota, because the whole point of a self-hosted backend for CI is that it's disposable infrastructure that lives and dies with the job.

The lesson that generalizes past our specific mistake: a free tier's stated limit (2,000 minutes) and the limit you actually hit are different things when a piece of your pipeline scales with something other than your obvious usage pattern. We were budgeting "minutes per push." The real driver was "minutes per e2e run times how often e2e runs," which had crept upward independently of push volume as the suite grew, and nobody was watching that number until it was most of the way to the ceiling.

Where free tiers genuinely end

Being specific about this matters more than the "we're scrappy" version of this story, because the honest limits are useful and the vague ones aren't.

Free tiers end at real production traffic with real users depending on uptime. Every free tier we use has a fair-use ceiling that's generous for a small team's own usage plus a modest user base, and none of them are built for a product that's actually succeeding. The plan, explicitly, is: the day a product's free-tier usage is driven by paying customers rather than our own development traffic, we upgrade that specific product's specific dependency, not the whole stack at once. We've done this exactly once, for Vercel, on exactly the one product where it made sense.

Free tiers end at team-collaboration features, not usage volume, surprisingly often. Several of the tools in our stack have a usage ceiling we'll never hit and a seat or feature ceiling — SSO, audit logs, priority support — that's the actual reason to pay. That's a different upgrade trigger than "we ran out of quota," and worth distinguishing, because it means "free tier" and "small team" aren't quite the same axis; you can be well within usage limits and still need to pay for a capability the free tier deliberately withholds.

Free tiers end at operational risk you're not willing to carry, even inside the limit. This is the Convex and GitHub Actions story. We were technically inside the free ceiling until we weren't, with less warning than the stated limits implied, because the thing that consumed the quota wasn't the thing we were watching. The lesson wasn't "upgrade sooner." It was "instrument the actual driver of usage, not the proxy metric you assumed was the driver."

Advice for an indie founder reading this

Start on free tiers, genuinely, for everything — not as a badge of scrappiness but because premature infrastructure spend is one of the more common ways early-stage teams burn runway on capacity they don't have users to justify yet. But watch the usage dashboards, not just the invoice. The invoice tells you what you're already paying for. The usage dashboard tells you what's about to become a problem, two weeks before it does, if you're actually looking.

And when a free tier surprises you — ours did, twice, in the same year — treat it as a signal to fix the underlying waste before reaching for the credit card. Both times, the actual fix was "stop being wasteful," not "pay more," and both fixes made the product better independent of the bill. That's usually the case. Free tiers are strict enough to force good habits; that's arguably their real value, more than the money.

---

Syntax Lab Technology runs eight products on a stack that's still mostly free tier, two years in. The one exception costs less than a single senior engineer's daily rate, per month.