The perfect solution that never shipped (and learning to work with legends)

4/22/2025 · 6 min

See the related case study: Web3 Faucet Service

Momentum from earlier wins (see Origin & Strategy) set the stage for tackling the faucet bounty.

Simple enough, I thought. Despite having zero experience with OpenZeppelin Defender or relay infrastructure, I was eager to please and confident I could learn. I had velocity. I was moving. I was becoming ubiquitous.

The irony of what happened next still makes me laugh.

The challenge that seemed straightforward

New bounty hunters were hitting a wall at the moment of their first success. They’d complete a task, earn their reward, but couldn’t claim it because they lacked xDAI for gas on Gnosis Chain. “Not enough gas to claim” became the most frustrating error message in the onboarding flow.

The solution seemed obvious: build a faucet that would subsidize new users with just enough gas to make their first transaction. Validate them against the database, check they haven’t been subsidized before, send a tiny amount of xDAI. Problem solved.

I dove into OpenZeppelin Defender, learned about relay infrastructure, figured out Cloudflare Workers constraints, and built something I was genuinely proud of:

const userBal = await relayer.call("eth_getBalance", [ethAddress, "latest"]);
if (userBal.result > env.CLAIM_FEE) {
  return makeRpcResponse({ error: { code: -32000, message: "Hunter has enough gas" } }, 400);
}

const relay_ = await relayer.getRelayer();
const relayBal = await relayer.call("eth_getBalance", [relay_.address, "latest"]);
if (relayBal.result < env.CLAIM_FEE) {
  return makeRpcResponse({ error: { code: -32000, message: "Faucet has no funds" } }, 400);
}

const tx = await relayer.sendTransaction({
  to: ethAddress,
  value: toHex(env.CLAIM_FEE),
  speed: "fast",
  gasLimit: 21000,
});

Clean validation, intelligent preflight checks, abuse resistance via database lookups, zero private key custody. It worked perfectly. QA scenarios passed. On-chain transactions verified. The code was production-ready.

Working with a legend

Throughout this project, I was collaborating closely with rndquu—the maintainer who’d become my unofficial mentor. His style was… unique. Clint Eastwood meets senior engineer. Man of few words, but every word counted.

At first, his approach was tough to get used to. No small talk, no ego-stroking, no hand-holding. Just direct, insightful feedback that cut straight to the heart of the matter. He’d review code with surgical precision, catching edge cases I’d missed and suggesting improvements that made the solution twice as robust.

What became clear: when he praised something, it meant something. When he said “looks good,” you knew you’d actually built something good. No filler, no politics. Just direct technical communication from someone who’d seen enough code to know the difference between “works” and “works well.”

I had tremendous respect for the guy. Every interaction taught me something—about code, about systems thinking, about the difference between clever and robust. He was the kind of engineer I aspired to become: capable, direct, and uncompromising about quality.

The praise that felt hollow

The faucet passed review with flying colors. The implementation was solid, the architecture was clean, the edge cases were handled. I’d successfully learned a new technology stack (OpenZeppelin Defender), solved a real user problem, and delivered something that worked exactly as specified.

The praise felt good. The merge felt better. Another successful contribution to my growing portfolio.

Then nothing happened.

The reality of startup priorities

Weeks passed. The faucet sat in production, ready to deploy, solving a real problem that was blocking real users. But it never went live.

I kept expecting someone to flip the switch, to integrate it into the onboarding flow, to actually deploy the solution. The infrastructure was there. The problem was still there. The solution was proven and ready.

But priorities had shifted. Plans had changed. The macro strategy had evolved in ways that made micro solutions fall through the cracks.

Maybe it fit better into future plans than immediate needs. Maybe the infrastructure wasn’t in place to support it properly. Maybe there were too many conflicting ideas about how to move forward at the organizational level. Maybe it was just typical startup behavior—things move fast, priorities change daily, and not every good idea survives the sprint.

I chalked it up to startup life and moved on.

The merged code remained unactivated in production due to shifting priority focus and integration bandwidth. That divergence became the core lesson: deployment context matters as much as technical readiness.

The lessons hidden in the gap

Looking back, this project taught me something crucial about the difference between building solutions and solving problems. I’d built a perfect technical solution to a real user problem, but I hadn’t built it within the context of organizational readiness to deploy and maintain it.

The code was flawless. The architecture was sound. The problem was real. But the timing, the organizational priorities, the integration requirements—those were the variables I hadn’t optimized for.

It was a masterclass in the reality that perfect code doesn’t automatically translate to shipped features. Context matters. Timing matters. Organizational bandwidth matters. Sometimes the best technical solution is the one that never sees the light of day.

What I gained anyway

Despite never reaching production, the faucet project was far from wasted effort. I’d learned OpenZeppelin infrastructure inside and out—knowledge that would prove valuable in future projects. I’d gotten comfortable with Cloudflare Workers and edge deployment patterns. I’d deepened my understanding of Web3 onboarding challenges.

Most importantly, I’d continued building my reputation as someone who could deliver quality solutions on time. Even unused, the faucet demonstrated technical competence and problem-solving ability. It was another data point in my growing credibility at Ubiquity.

And working closely with rndquu had been invaluable. His direct, no-nonsense approach had pushed me to write better code, think more systematically, and care more about robustness than cleverness. Those lessons would carry through everything I built afterward.

The bigger picture

The faucet was a single thread in a larger tapestry I was weaving. While this particular solution never shipped, it was part of my strategic plan to embed myself deeply into all three critical components of the Ubiquity ecosystem. Each contribution, used or unused, was building toward the goal of becoming truly ubiquitous.

Sometimes the most valuable projects are the ones that teach you about reality rather than the ones that ship to production. The faucet taught me that startup life is messy, priorities shift constantly, and perfect solutions don’t always find perfect timing.

But it also taught me that consistent delivery—even of unused solutions—builds trust and credibility. And that working with engineers like rndquu, even on projects that never ship, can teach you more about quality than a dozen successful deployments.

The best mentors don’t coddle you—they hold you to standards you didn’t know you could meet.

See also

• Next chapter — The day I solved what the senior engineer couldn’t
• Previous chapter — The merge that changed everything