I spent the past four months working on a foundational product after pivoting from another foundational product required for Nickel to continue development. This is that story.

TL;DR: Relying solely on Stripe as payment rails for Nickel’s tipping feature made me uncomfortable and that led to the idea of a crypto-powered payment rail but the foundation of all my projects, the database, relied on one that was suddenly no longer in active development. I felt I had no choice but to tackle that and learning a different workflow for an assured lesser developer experience long-term is unacceptable to me. Thus, Disc was born.

Why not Stripe

When I design a website, I want it to look a certain way. When integrating Stripe, Stripe wants you to use their components with their styling. While they offer an appearance API, you’re fighting against the limits of their sandbox. It feels unnecessarily complicated and I get frustrated trying to force my design into their mold. Unfortunately, other payment providers aren’t as open to new business owners, requiring you to fill out forms or set up meetings to make your case for the privilege of being their customer. Or, they’ll have minimum revenue requirements.

While I managed to get Stripe working with Nickel, I can see where the design is compromised and that bothers tf outta me.

Why crypto

HTTP 402 (Payment Required) is an HTTP method that’s been in placeholder mode since the internet’s invention...until Cloudflare and Coinbase got together to create a spec, x402. Designed for LLM agents, their spec makes it trivial (theoretically) for anyone to accept (Ethereum) payments by gating access to a URL or resource on a server/service they control...sounds like a great way to achieve what I want with Nickel.

How I envisioned this new payment rail working with Nickel sounded like another product opportunity (and excellent dogfooding opportunity), while keeping Nickel’s codebase less complicated.

BTW, Bitcoin has their own Lightning-based spec, L402.

WTF database?

I get into this in the write-up I did about Disc’s launch:

In December of last year the developers of my favorite database, Gel, announced they were quitting the project to work for Vercel on building "the best Python cloud in the world." Six years was a good run but it wasn’t enough for them to figure out how to turn a profit after VC money ran out. Alas.

My previous favorite database was RethinkDB, though I discovered it about a year after its creators closed shop. Gel is now in the hands of the community and while there is a "blessed fork," said fork hasn’t seen much activity aside from refactored tests.

Having experienced working with a "dead database" before, I had no interest in revisiting the pain that comes with eventually needing to grow beyond it. What drew me to RethinkDB and Gel was the built-in interface they both come with. I’m not a database whiz and I have zero interest in learning SQL; otherwise I’d use many of the popular ones. I’m a designer turned developer turned whomever I need to be to achieve a goal.

With that in mind, I set out to see if I could build the database I want to use forever.

(You can read the whole thing here: https://blog.webb.page/WM-095)

It took work but I’m satisfied. Disc is at a great place to put into the world under the scrutiny of others and crucially, this allows me to get back to developing my new payments product for Nickel (and, for you)!

Near future

Nickel will be refactored to run on Disc in the near future while I work on this payments thing. It shouldn’t take another four months but we’ll see.

In the past I’ve ended these dispatches with a message about following on platforms and man, I don’t like using Bluesky or LinkedIn much tbh.

If you want to chat about Nickel or give suggestions, feel free to respond to this email or sign up for my forum and post on the Nickel board. I’ll keep those accounts around but they don’t feel right for true communication.

See you in the next dispatch!

— Paul