I built a gateway to bypass Vercel limits (and save $20/mo)
Hey Indie Hackers,
I wanted to share a project I've been scratching my own itch with.
The Problem:
I love Vercel for the DX, but I hate the "Success Tax." I have a few side projects that get sporadic viral traffic. They make $0, but they occasionally hit the Serverless Function limit, which bumps me into the $20/mo Pro tier per team.
It felt unnecessary to pay enterprise prices for hobby traffic just because of a few spikes.
The Solution:
I didn't want to move to a VPS and manage Docker containers, so I built a middle-ground.
I wrote a lightweight API Gateway in Go (called Crate) that sits on a cheap bare-metal server.
- It tracks my bandwidth/requests in Redis.
- It acts as a load balancer, round-robin routing traffic across multiple free-tier accounts (Vercel/Netlify/DigitalOcean/GCP/AWS you pick your poison).
- It allows me to split traffic 50/50 between Serverless and a cheap VPS.
- I can also rate limit traffic to my endpoints to help reduce overall traffic from going crazy
The Result:
I can now handle about 3x the traffic volume on the free tier before paying a cent. I'm effectively using it as a "pre-firewall" for my Vercel bills.
Where I'm at:
I just launched it as a SaaS for $5/mo (grandfathered pricing) to cover the server costs. I'm looking for a few other developers who are tired of watching their usage meters to test it out.
I'd love feedback on the landing page or the pricing model. Is $5/mo a no-brainer to save $20, or does adding a middleware layer scare you off?
Check it out: https://crate.cc
Update #3: Just rolled out the AI Shield.
A few founders mentioned they were getting hammered by LLM scrapers (GPTBot, etc.) and it was eating up their bandwidth.
I added a 1-click toggle to block them at the gateway. If you're running on a free tier (like Vercel/Netlify/DigitalOcean), this is the easiest way to ensure bots don't eat your monthly quota.
Update 2 : Speaking of "Safety" features... I actually accidentally stress-tested the new Alerting Engine last night. 😅
I was coding late and didn't realize my local auth token had expired. My frontend didn't handle the rejection gracefully and ended up firing off a loop of API requests trying to refresh data that wasn't there.
The good news: The system works. My phone buzzed 30 seconds later with a "High Volume of 401 Errors" alert.
The bad news: I had to fix a bug in my frontend logic before breakfast.
Nothing beats dogfooding your own tool to find the edge cases!
Is this against Vercel's terms of service? I'm just wondering if I can do something similar...
I haven't specifically checked their ToS but if they have terms blocking you from using other providers I'd find that pretty sketchy on their part.
I'm not recommending creating 2 vercel accounts and hosting the same app that ways. More like hosting the same app on various providers: vercel, GCP, digital ocean. Then splitting the traffic between them.
I'm also currently working on an update to allow waterfall routing so you can max out traffic to one before routing to the next without going over any limits at all. Then you can guarantee you never hit a bill.
💯
Update: The feedback here was super clear—'Safety' is the #1 priority. So, I spent Sunday building an Alerting Engine. It's live now (Spikes, Dips, and Error Rates). Thanks for shaping the roadmap!
This is really interesting because it’s the same pattern I noticed from the user side.
The platform overhead becomes bigger than the actual work you’re trying to do.
I’m tackling this from the tiny-task/tool angle, and you’re tackling it from infra/dev cost — but the root problem feels identical: modern stacks add friction where it’s not needed.
You nailed it. That phrase—'Platform overhead becomes bigger than the actual work'—is exactly why I started building this.
Serverless was supposed to be the holy grail for 'tiny tasks' (just write the function and ship!), but somehow we ended up with 5 different consoles, confusing billing meters, and 'YAML hell' just to run a simple API.
It feels like we need to strip the complexity back out so we can actually focus on the code again.
I'd love to see the tool you're building on the tiny-task side—are you tackling the UI/workflow side of things?
Yes — I’m looking at it from the UI/workflow side. I noticed the same thing for end users: the task is tiny, but the system around it is huge. So I’m experimenting with tools where the interface “gets out of the way” and lets people just open → do → close. Different layer, same goal: removing overhead so the actual work feels lighter.
That sounds super interesting.
I took a look at the landing page the tech is solid, but I think the main objection shows up before the performance pitch.
As a buyer, my first question isn’t “is this fast?” , it’s “what happens if Crate goes down?”
You already solved this with the fail-open architecture, but it’s buried. If that guarantee was in the hero section, the $5 feels almost risk-free.
Happy to help you reframe the hero + first section around “safety first, savings second” if useful.
Thank you for the insight, that is a fair point. I suppose saftey net is a good angle.
I'm open to all suggestions! I've been an engineer for over a decade so building things that work well comes easy to me but this is my first real attempt at trying to market anything.
Thanks for being open! Based on what you said, the key shift for the hero could be leading with safety first, then savings. A few angles you could test:
“Even if Crate goes down, your traffic keeps flowing. Save $20/mo on Vercel limits safely.”
“Protect your hobby projects from surprise serverless bills—$5/mo with zero downtime.”
“Safe, fail-open API gateway for bootstrappers—keep traffic flowing and costs low.”
Each of these puts the visitor’s main concern front and center before the tech details. The goal is just to make the $5 feel almost risk-free right away.
If you want, I can suggest a simple tweak for the subline that reinforces this without touching the tech section—just a small nudge that usually improves clarity.
These are great, thank you!
I like the second one. I just need to be careful with the fail open aspect.
It is a clustered system so if nodes fail traffic keeps going but it is technically part of infrastructure so like any other gateway even large companies like AWS, if the gateway failed the system goes down. For clarity it's setup so that if the admin system goes down it doesn't stop any of the traffic, even my database could go down without stopping traffic. But if the gateway itself were to completely fail traffic would stop.
That makes total sense and you’re right to be careful there. Over-claiming safety is worse than under-selling it.
I think the nuance you just explained is actually the strength, it just needs cleaner framing.
Instead of positioning it as “nothing can ever go down,” the angle could be:
Crate doesn’t add new fragility to your stack.
Something like:
“Your traffic isn’t dependent on a dashboard, database, or control plane staying online.”
That way you’re clearly saying:
– infra can fail (because reality)
– but Crate removes the extra failure points people worry about when adding middleware
It keeps trust intact while still answering the buyer’s real fear:
“Am I making things riskier by adding this?”
If you want, I’m happy to help tighten that wording so it’s technically accurate and reassuring without sounding like a guarantee you can’t stand behind.
Thanks, as always, I'm open to feedback.
I made some adjustments to the content this morning based on your previous comments to try and make things a little more clear.
Nice updates! The “Autonomous Data Plane” section really nails the safety message. visitors will immediately see that Crate reduces extra failure points without overpromising.
If you want, I can take a quick pass on the hero + subline to see if there’s a small tweak that makes that “safety first” angle click even faster for new visitors. Usually just a minor wording adjustment can make a big difference in clarity and trust perception.
sure
Awesome! I’ve drafted a ready-to-paste hero + subline copy that puts safety first, then savings, while keeping it simple and clear. It’s designed to grab attention immediately and reassure visitors without overpromising.
Here’s the copy you can plug directly into your landing page:
Hero:
Keep your API traffic flowing even if parts of your stack fail.
Subline:
Crate safely distributes traffic across multiple backends, caps serverless costs, and protects your stack—all starting at $5/mo.
Optional one-liner under subline for extra clarity:
Your dashboard or database can go offline — your traffic won’t stop.
And here is why it works:
Immediately answers the “what if it fails?” question visitors have.
Keeps the savings visible but secondary to safety.
Short, clear, and easy to scan — perfect for the hero section.
The "Success Tax" framing is perfect. Paying $20/mo for a project making $0 just because of traffic spikes is a real pain point for side project builders.
The multi-provider load balancing angle is clever. Most people would think "move to a VPS" — but keeping the serverless DX while distributing across free tiers is a nice middle ground.
A few questions:
Latency overhead — How much does routing through the gateway add? For API endpoints where every ms counts, this could be a concern.
Provider detection — Do any of the platforms (Vercel, Netlify, etc.) actively detect and block traffic from known proxy IPs? This feels like a gray area that could break at any time.
Positioning — "$5 to save $20" is an easy ROI pitch, but the real value might be "peace of mind during viral spikes." Have you considered usage-based pricing instead of flat rate?
The landing page is clean. One suggestion: showing a real before/after cost comparison (e.g., "Project X: $60/mo on Vercel → $5/mo with Crate") would make the value more tangible.
Thank you for this feedback, it's very helpful.
I enjoy working with serverless functions on most of my projects so a solution like this actually solves a few problems for me. Ie: easy to route a nice neat API endpoint to the ugly urls functions get most of the time, easier rate limiting to help fight spikes, easy to deploy multi cloud and avoid any down time I'm the event of an outage (looking at the AWS outage a few months ago)
As long as it's deployed close to the project the latency is pretty minimal because I built it to load all all the routing rules into memory, the actual lookups are pretty much o(1). A little may be added for any transformations or rate limiting. But even fir rate limits my redis instance is on the same machine so again pretty negligible.
I haven't had any issues with blocking proxy ips yet, probably because I'm just not big enough to trigger anything. But I'd assume companies like Kong or tyke would potentially have the same issue, I'll have to cross that bridge when I get there.
I'd love to go pure usage based, and I may some day if I can get enough revenue. I mean $5 for 1tb seems like a good deal for almost endless traffic for a side project. And overages is just $0.01/GB that's 9x cheaper than AWS. To be frank the only reason I didn't go usage based from the start is payment processors don't do micro transactions and I can't afford to subsidize traffic until a bill gets high enough that I don't loose money on the deal, so $5 seemed high enough to make a profit and low enough to not kill the budget for most people.
Thanks for the detailed breakdown. The O(1) lookups with in-memory routing rules makes sense — that's the right approach for minimizing overhead.
The $5 flat rate rationale is interesting. Payment processor fees eating into micro-transactions is a real problem that doesn't get talked about enough. Usage-based sounds better in theory, but the economics don't work until you hit critical mass.
Good luck with the launch. The "safety net for serverless bills" positioning seems to be resonating well based on the feedback in this thread.
Thank you. I've been thinking about this problem for several years and slowly implementing it for my own systems. Then all the pieces fell into place the last couple months for me to be able to focus on it.
Alot of improvements planed the next couple weeks to bring my feature set into line with the bigger players. So hoping I can start to get some design partners to help fully flush it out.
Makes sense that the pieces came together after years of solving it for yourself — that's usually where the best tools come from.
Design partners at this stage are smart. Real usage patterns will surface things no amount of solo testing would. The alerting engine dogfooding story from your update is a good example — edge cases show up when the tool is actually load-bearing.
Good luck with the next few weeks of feature work.
Thank you!