Building Solenoid: The First 90 Days

Three months ago, Solenoid was a notes document with four API ideas. Today it’s four products in production, real users, and actual revenue.

This is what happened between those two points.

The Idea Stack

I kept running into the same infrastructure problems across projects:

Metering: Every SaaS with usage limits needs credit tracking. I’d built this three times. Redis + Lua scripts + cleanup crons. Each time slightly different, each time annoying.

Webhooks: Scheduled HTTP callbacks seem simple until you need reliability. Job queues, retry logic, dead letter handling. More infrastructure than the feature was worth.

Feature flags: I wanted simple on/off toggles, not a targeting rules engine. Every existing tool was overkill.

Audit logs: Compliance kept asking for tamper-proof logs. Blockchain was absurd. Hash chains were obvious but nobody offered them as a service.

Four problems. Each too small to be a company. Together? Maybe something.

Week 1-2: Validation

I posted on Indie Hackers describing the concept: single-purpose edge APIs, unified billing, minimal design. Asked if anyone would pay for this.

The response was mixed. Some people got it immediately. Others wanted to know why they wouldn’t just build it themselves.

Fair question. The answer: you could, but you’d spend a week on each, then maintain them forever. I wanted to make that someone else’s problem.

A few people said they’d pay $20/month. That was enough.

Week 3-4: First Product (Meter)

Meter came first because I needed it most urgently for another project. Durable Objects for per-user credit tracking. Atomic operations. Simple API.

The architecture decisions made here shaped everything after:

• Cloudflare Workers for compute
• Durable Objects for consistent state
• KV for simple key-value storage
• Hono for routing

Building on Cloudflare meant low latency globally without managing regions. The tradeoff: learning their primitives.

Meter worked within two weeks. Rough edges, but functional.

Week 5-6: Second Product (Gate)

Gate was easiest. Feature flags are simple. I deliberately kept it minimal—booleans only.

The controversial choice: no dashboard. API-only. Create flags with curl or your own tooling.

Some early feedback was negative. “How do non-technical people manage flags?” My answer: they don’t. Gate is for engineering teams who want flags without the baggage. Non-technical flag management isn’t the problem I’m solving.

Shipped in a week.

Week 7-8: Third Product (Relay)

Relay was the most interesting to build. Each webhook gets its own Durable Object. The timer and delivery logic live together. No coordination, no job queue.

I added HMAC verification because webhook security is consistently neglected. Every Relay delivery includes a signature. Recipients can verify authenticity.

The retry logic was tricky. DO alarms handle scheduling, but deciding when to retry vs. give up required thought. 5xx = retry, 4xx = stop. Simple heuristic that covers most cases.

Shipped in two weeks.

Week 9-10: Fourth Product (Witness)

Witness was the riskiest. Hash chains and digital signatures—correct implementation matters. Get the crypto wrong and the whole thing is useless.

I spent more time on verification than creation. The signing was straightforward. Ensuring anyone could verify independently, without calling the API, took iteration.

ECDSA P-256 for signatures. SHA-256 for hashes. Standard, boring, well-audited primitives. No exotic cryptography.

Shipped in two weeks.

Week 11-12: Launch Prep

Four products working. Now the actual work: documentation, marketing site, billing integration.

The site took longer than any individual product. Copy is hard. Explaining what something does without jargon, without slides, in a way that makes people want it—that’s a skill I don’t have naturally.

Stripe integration was straightforward. Usage-based billing requires metering your own usage, which was ironic and useful. Meter tracking Meter usage.

Launched on a Tuesday. Tweeted about it. Posted to Indie Hackers, Hacker News, and the Cloudflare Discord.

What Went Right

Edge architecture from day one. Every product benefits from low latency. I didn’t have to migrate later.

Unified API key. One signup gets access to all products. Reduced friction for trying additional services.

Minimal scope per product. Gate doesn’t have targeting. Relay doesn’t have complex retry configuration. Less to build, less to maintain, less to explain.

Building on Cloudflare. Their primitives (Workers, DOs, KV) handle scaling. I haven’t thought about servers.

What Went Wrong

Documentation debt. I launched with minimal docs. Early users had questions I should have answered preemptively.

No monitoring from the start. Errors in week one went unnoticed until users reported them. Embarrassing.

Underpriced initially. Started at $9.99/month for the lowest tier. Should have been $19.99. Raised it after a month; nobody complained.

Blog content was implementation-focused. I wrote about how I built things, not why you’d use them. Wrong audience for marketing.

The Numbers (So Far)

Being transparent because I wish others would:

• Signups: ~400 free tier
• Paid customers: 23
• MRR: ~$800
• Primary product: Meter (45% of revenue)
• Support tickets: 0.3/day average
• Downtime: One 4-minute incident (my fault, bad deploy)

Not impressive. Not failure. Growth is slow but consistent. Each month is higher than the last.

What I’d Do Differently

Start with better content. The blog should explain problems, not implementations. SEO takes months; I should have started earlier.

Built in public more consistently. Sporadic updates aren’t engaging. Weekly notes would have built more audience.

Talk to users before building Witness. It’s the least-used product. Maybe the market is smaller than I thought. Maybe the positioning is wrong. Should have validated harder.

Charge more from day one. $19.99 isn’t expensive for infrastructure. I was nervous about pricing for no reason.

What’s Next

Honestly? More content. The product is solid. The growth is about distribution now.

I’m writing this blog series you’re reading. Comparison posts, use-case tutorials, the content types that actually convert.

Considering a CLI tool that wraps all four products. Make local development easier.

Maybe a fifth product if I find another problem worth solving. Or maybe four is enough and I should focus.

If you’ve built something similar, or you’re considering it, reach out. I’ll tell you whatever you want to know. Building in public means actually being public.