Building a Stablecoin from Scratch

I wish I could go back to when I started building sometimes. I understand this doesn’t quite add up, because lessons don’t really stick unless you figure things out yourself, but I still feel like I could’ve used a couple of pointers. I wouldn’t show myself a roadmap. I wouldn’t drop in with a list of tools, frameworks, or investor contacts. I’d most likely ignore myself if I did. But I’d maybe sit across from my younger self and ask a few quiet questions.

That sounds abstract. But if you’re in the early days, you probably already know how much noise surrounds you: the hype, the tech stack debates, the pressure to raise, the pressure to ship. It’s easy to confuse movement with direction. So this is less a playbook and more a few things I wish I’d internalized earlier, as I reflect on the building of Quill, one of the more interesting products I’ve worked on recently.

Quill is the Scroll Network’s native stablecoin protocol and solution, which our team has built from scratch. You can find the product here.

It took me too long to realize that starting something doesn’t mean pretending you’re further along. You don’t need to look like a company before you are one. You don’t need to manufacture momentum. If you’re one person with a loose idea and a day job, that’s the reality. Start from there.

The best builders I know began with small, sharp questions. What pain am I feeling every day? What do I wish existed? They weren’t asking: “How do I turn this into a business?” on day one. They were simply paying close attention.

That attention is underrated, and it served us well while building Quill. Did we need to reinvent stablecoins or did we need to understand the ecosystem we were building in? Did we need to create an independent company to operate this product or could we handle it ourselves? Reflecting on those questions and figuring out the path was instrumental.

It’s easy to romanticize abundance. More time, more money, more hands on deck. But when I look back, the most generative periods were the ones where I was stretched. Not enough time. No budget. Pressure to deliver.

That kind of tension forces clarity. You stop trying to do everything.

You have to ask better questions.

It becomes obvious that a perfect product no one uses is useless, and a scrappy product that solves something real will grow on its own terms.

The temptation is always to over-engineer, to overthink. But when you have five hours a week and zero margin for fluff, you move differently. You focus on the essence. That’s an advantage. When you’re building in Web3, and products aren’t always as impressive as the hype around them, that can be even more true.

The first time you get interest—from users, from partners, from investors—the instinct is to say yes to everything. You want to prove yourself. You want to keep the momentum alive. But most early decisions are not about what to say yes to. They’re about what you’re willing to leave out.

Every feature you don’t build, every email you don’t answer, every meeting you decline—these are bets on your focus. If you don’t protect it early, you lose the plot before you know you had one.

This isn’t about being precious. It’s about being deliberate. You can always expand. You can’t always rewind.

Did I mention this already? Let me reinforce the message. When I started, I thought building was about answers. Find the right stack. Build the right UI. Say the right thing. But most of the work is actually just framing the problem well.

What exactly am I solving? Why is this painful? Who cares enough to use this today? Why hasn’t this been solved already?

If you’re not careful, you end up polishing a solution for a problem no one feels. So take your time on the problem space. Sit with it. Talk to real people, not just your peers. Let yourself be wrong. When we were building Quill, we knew what the technology could look like, thanks to Liquity V2, but we didn’t actually know what the Scroll ecosystem needed from this product.

That’s what we had to figure out.

The myth is that speed comes from shortcuts. But real speed comes from intention. From making fewer, better decisions. From building foundations you don’t have to rip out six months later.

I’m not saying you need to plan everything. I’m saying you need to resist the rush. You need to be okay sitting in the quiet parts: the half-formed ideas, the awkward prototypes, the uncomfortable silences in user interviews.

Moving fast and breaking things might get you somewhere, and I’m not against a little breakage time and again. But I do question people if this is all they put emphasis on. Has anyone truly built anything worth using by just moving fast and breaking things? Surely not. Moving deliberately and listening deeply will have to take centre stage at some point, even if you’re doing it in the rubble.

You probably got into this because something lit a fire in you. Don’t trade that for validation. Don’t let the dopamine loops of Twitter or product hunt launches steer your energy.

There’s a different kind of confidence that comes from ignoring the noise. From building in silence. From letting your product speak before you do.

If I could sit with my younger self, I’d tell him: trust the questions more than the answers. Trust the work more than the performance. And trust that if you’re honest about what you’re trying to solve, someone else out there is waiting for it.

That’s enough of a reason to build.