TLDR: Built a cookie consent tool for indie hackers. 1KB loader, 60-second setup, free tier with unlimited page views. Sharing the story and what I learned.
Read full summary
A solo developer's journey building GetCookies for the indie hacker community. Covers the problem, technical decisions, lessons learned, and real usage numbers.
*Summary by Claude AI*
## I Spent 3 Days Building Cookie Consent for My Side Project. Then I Decided to Just Build It Right.
*Originally posted on r/SideProject and r/indiehackers*
Last year I was 2 hours from launching a side project. Everything was ready. Domain, Stripe, landing page, the works.
Then I thought: "Wait, I have Google Analytics. I'm selling to Europe. Do I need cookie consent?"
I Googled it. The answer was yes. Very yes.
So I spent the next 3 days:
- Reading GDPR documentation
- Learning about Google Consent Mode v2
- Trying to understand what "ad_user_data" signals mean
- Implementing a consent banner
- Debugging why my analytics broke
- Questioning whether shipping software was worth it
After 3 days, I had something that probably worked. Maybe. I wasn't entirely sure.
Then I launched another side project. Same problem. Another 3 days.
After the third time, I decided: never again. I'll build this once, properly, and use it on everything.
That became GetCookies.
## Why Existing Solutions Didn't Work
### OneTrust
Googled "cookie consent tool." First result was OneTrust. Clicked through. Big enterprise site. Clicked pricing. "Contact Sales."
I'm one person. I don't have a sales team to contact sales. Pass.
### Cookiebot
€12/month minimum. For my side project with 100 visitors. That's more than my hosting costs. Also pass.
### DIY
I tried. I really tried. But cookie consent in 2024 requires:
- Google Consent Mode v2 (4 different signals)
- A registered CMP Developer ID with Google
- Third-party pixel integration (Meta, TikTok, etc.)
- Script blocking until consent
- Proper consent logging for audits
It's not "just show a banner."
### "Just ignore it"
GDPR fines are up to €20M or 4% of annual revenue. For a side project that might make €100/month, the risk isn't worth it.
## What I Built
One script tag. Works on everything.
```html
```
That's the entire implementation. Add it to your ``. Done.
### What It Actually Does
1. **Shows a cookie consent banner** - Customizable, looks decent by default
2. **Blocks tracking until consent** - Respects user choice
3. **Handles Google Consent Mode v2** - All 4 signals, set before GTM loads
4. **Notifies third-party pixels** - Meta, TikTok, Pinterest automatically
5. **Logs consent for audits** - If someone asks, you have proof
### The Free Tier
Because I'm an indie hacker building for indie hackers:
- 1 domain
- Unlimited page views (no 100-page limit like some competitors)
- All core features
- No credit card required
- No "upgrade or we remove your banner" pressure
I'm not going to nickel and dime you on page views. That's annoying.
## Numbers (Transparency)
Since I know this sub likes real numbers:
- **Launched:** ~6 months ago
- **Domains using it:** ~800
- **Monthly consent events:** ~3M
- **Paid customers:** ~40
- **MRR:** ~$500
- **Downtime:** 0 (so far, knock on wood)
Not getting rich, but it's sustainable and growing. More importantly, it solves my own problem on every new project.
## Technical Decisions (For the Nerds)
### Why 1KB?
The first version was 40KB. I looked at competitors—they were all 30-150KB. This seemed wrong for showing a banner and tracking yes/no.
I rewrote it as:
- 1KB synchronous loader (sets consent defaults immediately)
- Async widget load (banner UI, not blocking)
Result: Zero impact on Core Web Vitals.
### Why Python/FastAPI?
I know Python. I ship fast with Python. The backend is simple—accept consent events, store them, serve configs. Doesn't need to be rocket science.
### Why Preact for the widget?
React is 42KB. Preact is 3KB with the same API. For a consent banner that needs to load fast, every KB matters.
### Why Railway for hosting?
Easy deployment, fair pricing, good DX. I tried Vercel first but hit serverless cold start issues for the API. Railway just runs the container.
## Lessons Learned
### 1. Solve your own problem first
I built this for myself. Every feature decision was "would I use this?" That made product decisions easy.
### 2. Bundle size is a feature
Developers care about performance. When I tell them it's 1KB, they immediately trust it more than competitors. Tiny bundle = fast site = happy users.
### 3. Free tiers should be useful
A free tier with 100 page views is useless for testing. Unlimited page views means people can actually try it on their side project without worrying.
### 4. The "boring" parts are the hardest
The banner UI was easy. Google Consent Mode v2 compliance was hard. Third-party pixel integration was hard. Consent logging for audits was hard. The invisible work is most of the work.
### 5. Marketing is still hard
I'm a developer, not a marketer. Getting the word out is the challenging part. This Reddit post is my marketing budget.
## The Stack
For the curious:
| Layer | Tech |
|-------|------|
| Backend | Python / FastAPI |
| Frontend | TypeScript / Preact |
| Database | PostgreSQL |
| Hosting | Railway |
| CDN | Cloudflare |
| Payments | Stripe |
Nothing fancy. Just works.
## What's Next
Based on user feedback:
- [ ] More banner customization
- [ ] Better analytics dashboard
- [ ] A/B testing for consent rates
- [ ] More framework-specific guides
- [ ] Whatever users actually ask for
## Try It
If you have a side project that needs cookie consent:
1. Go to [getcookies.co](https://getcookies.co)
2. Sign up (Google = fastest)
3. Add your domain
4. Copy the script tag
5. Add to your site
6. Done
Takes about 60 seconds. Free tier has no time limit or page limits.
## Questions?
Happy to answer anything about:
- Technical implementation
- GDPR/compliance details
- Building as a solo dev
- Why I made specific decisions
- Whether something is actually compliant
I'm not a lawyer, but I've read more GDPR documentation than any human should.
---
*Built by an indie hacker, for indie hackers. Because enterprise tools for enterprise problems shouldn't cost enterprise budgets.*