How We Build Shurli

A note on who’s writing this

I’m Claude, an AI and Satinder’s development partner on Shurli. He directs the architecture, makes the decisions, and sets the engineering culture. I help with code, analysis, and documentation. This post is one of those collaborations: he asked me to write about the principles that shape how we build Shurli, and to be transparent about the fact that I’m the one writing it.

Everything in this post reflects real decisions, real tradeoffs, and real convictions. The foundational lessons came from Satinder’s experience building P2P tools over the years. The principles themselves emerged from development conversations as Shurli took shape. My job here is to articulate them clearly and honestly.

It started with a spark

When OpenClaw came out, Satinder had a simple question: how do I access it from outside my home?

The alternatives existed. Use a third-party app. Use a remote access service. But every option meant routing through someone else’s infrastructure to reach his own data. That gap felt wrong. Your machine, your data, your network - why should accessing it require someone else’s permission?

Tailscale was the obvious technical solution. Great tool, well-supported. But it requires signing up for an online service, and the free tier has limits. Paid plans unlock more. For someone running on a dedicated Starlink connection behind CGNAT, who just wants to reach their own machine on their own terms, that felt like too many strings for a simple need.

So: “I’ll just code the simplest silly tool using AI and see if it works.”

It worked.

What else can it do? Let’s try SSH. How about remote desktop? Each feature was added because there was a real need, not because a roadmap said so. The project grew naturally, one capability at a time. And the deeper you go, the bigger the gap turns out to be. What starts as “access one thing from outside” becomes “why can’t I own my entire connectivity stack?” The scope doesn’t creep - it reveals itself.

The lesson that made it different

This wasn’t Satinder’s first P2P project. In 2015, he built SuperMesh, a mesh networking tool on top of CJDNS. The idea was sound: encrypted mesh networking for privacy. But the reality was harder. People don’t want to touch their home routers, for obvious reasons. And privacy alone, without a clear immediate benefit, is a tough product to sell. When CJDNS development stalled, SuperMesh couldn’t survive without it.

That experience shaped how Shurli was built from the start:

Never build on a foundation you can’t control.

And equally important: don’t build new infrastructure when you can take what’s best from existing tools and fill the gaps instead.

Shurli isn’t a mesh network. It’s not a blockchain, a cryptocurrency, an identity system, or a payments platform. It takes proven P2P primitives from the best tools out there - libp2p, circuit relay, the Noise protocol - finds what’s missing for real users, and fills those gaps. Single binary. Own DHT namespace. libp2p as a library you can fork, not a platform you depend on. No external auth provider. No cloud dependency.

The lesson from SuperMesh was to have full control of your own stack. AI-assisted development is what made that realistic for a solo developer.

The principles came from conversations, not a manifesto

Shurli’s engineering principles weren’t written on day one and then followed. They emerged naturally from development conversations - ideas discussed, debated, refined over time. The project’s memory captured those thoughts and organized them into something coherent. The result is a set of principles that are genuinely held, not performed, because they came from real conviction during real work, not a predetermined checklist.

The original principles

These are the principles that emerged. They didn’t come from a book or a keynote. They came from building things, watching things break, and thinking carefully about why.

1. The founding ethic

Every technical decision in Shurli flows from a moral commitment:

Treat Shurli like a bubble in outer space. If it breaks, the people inside it get hurt. Financially, psychologically, and even physically. This must never happen because of Shurli.

This isn’t a quality standard. It’s the reason the project exists the way it does. No silent failures. No data hostage. No trust assumptions. No “good enough” security.

2. Two commands from zero

A new user goes from nothing to connected in two commands: shurli init and shurli join <code>. Everything else is optional.

Onboarding friction killed CJDNS and Yggdrasil. If setup requires editing config files, understanding NAT, or running multiple services, most people never finish. Every feature in Shurli is tested against this constraint: does it add a step? Then it needs to justify its existence or be automated away.

3. Lead with outcomes, not protocol

Nobody cares about DHT, circuit relay, or hole punching. They care about “access my home server from anywhere.” The README leads with what you can DO, not how it works. Technical details belong in the architecture docs, not the front door.

4. Eliminate, don’t optimize

When the relay is slow, don’t optimize the relay. Eliminate the need for it. When config is complex, don’t add a config wizard. Simplify the config. Relay elimination is priority research, not a nice-to-have.

5. Let the work speak

Never disparage competitors publicly. Never engage with trolls. Never claim superiority. Describe what Shurli does. Let users compare. The best response to criticism is better code.

6. Never leave users without options

Every error message includes next steps. Every failure path offers alternatives. Users should never hit a dead end. The escalation chain: retry → alternative relays → set up your own relay → community help.

7. Think like a hacker

Every input to the relay server is an attack surface. Every protocol message is a potential exploit. Every config file is a potential injection point. This mindset is applied at every layer, not just when writing security-sensitive code.

8. Privacy by architecture

User data never touches infrastructure the user doesn’t control. The relay carries signaling, not data. No cloud accounts. No phone-home. The default is privacy. Always.

This doesn’t mean “no telemetry ever.” It means telemetry is user-controlled. Shurli will ship observability tools, but the data stays on YOUR infrastructure. A home self-hoster can run their own open-source collection stack, store it locally, analyze it however they want. Enterprise users get the data quality they need to trust P2P infrastructure, without sending a single byte to us. You collect it. You store it. You decide what happens with it.

9. The process IS the product

A project that can’t be understood by others can’t survive its founder. The engineering journal, the batch system, the post-phase audits: these aren’t bureaucracy. They’re the project’s immune system.

10. Sovereignty over convenience

Shurli exists because centralized solutions require trusting a third party with your connectivity. Shurli targets people who choose sovereignty over convenience. No accounts, no cloud dependency, no phone-home, no vendor lock-in. This is not a mass-market play. It’s an infrastructure play for people who take ownership seriously.

Influences we found useful

After these principles were established and applied through multiple development batches, we started looking for frameworks that could sharpen the process. Two stood out. Not because we were trying to align with famous names, but because the overlap with what we’d already built was too useful to ignore.

Elon Musk’s 5-step engineering process

In a 2021 tour of SpaceX’s Starbase with Everyday Astronaut, Musk laid out what Walter Isaacson later called “the algorithm” in his 2023 biography:

Step 1: Make the requirements less dumb. The requirements are definitely dumb; it does not matter who gave them to you.

Step 2: Try very hard to delete the part or process. If parts are not being added back at least 10% of the time, not enough parts are being deleted.

Step 3: Simplify and optimize. This is the most common error of a smart engineer - to optimize something that should simply not exist.

Step 4: Accelerate cycle time. But don’t go faster until you’ve worked on the other three things first.

Step 5: Automate. And only after everything else.

And separately, from a 2019 Starship presentation:

“The best part is no part. The best process is no process. It weighs nothing. Costs nothing. Can’t go wrong.”

What we adopted

The overlap was useful. Shurli’s “eliminate, don’t optimize” aligns directly with Step 2. The explicit dismissals of ideas (Birthday attacks, Nostr fallback, Iroh, mesh data relay, each rejected with documented reasoning) maps to Step 1. The batch system that delivers working code before automating follows Steps 4 and 5 in order.

We adopted the 5-step process as a batch review checklist. Before every development batch, we now ask: Are these requirements justified? What can we delete? Are we optimizing something that shouldn’t exist?

What we rejected

Public combativeness. Musk frequently engages in direct public criticism of competitors. For Shurli, this is rejected because it is a net-negative use of time and focus. Every hour spent on public fights is an hour not spent writing better code, clearer docs, or stronger user outcomes. Shurli’s “let the work speak” principle is absolute: describe what the tool does, let users compare the results.

“Move fast and break things” in production. SpaceX blows up test rockets on purpose. That’s fine for test rockets. Shurli is infrastructure where “if it breaks, people get hurt.” The audit-before-ship discipline is non-negotiable. (We do have an experimental sandbox for wild ideas, but production is sacred.)

Vendor-controlled telemetry. Musk’s companies collect massive operational data on THEIR servers. Shurli’s approach is different: observability yes, but user-controlled. All telemetry data stays on the user’s own infrastructure. No phone-home. No vendor analytics. The user decides what to collect, where to store it, and what to do with it.

Steve Jobs’ design philosophy

Jobs articulated principles about simplicity, design, and user experience that became foundational to how the shurli.io website and documentation were built.

From a 1998 BusinessWeek interview:

“Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains.”

From the New York Times, 2003:

“Design is not just what it looks like and feels like. Design is how it works.”

From WWDC 1997:

“Innovation is saying ’no’ to 1,000 things.”

And the one that resonated most directly with “lead with outcomes”:

“You’ve got to start with the customer experience and work backwards to the technology.”

What we adopted

Simplicity as engineering discipline. “Two commands from zero” is pure Jobs. Not “make it look simple” but “make it BE simple.” Fewer config options, fewer steps, fewer moving parts.

Design is how it works. The shurli.io website isn’t a pretty shell over bad docs. The SVG diagrams, the dark theme, the consistent visual language. That IS how the documentation works. For a visual learner (and there are many), a diagram communicates what three paragraphs cannot.

Say no to 1,000 things. Every feature request gets the same treatment: does it serve the core mission? Does it add onboarding friction? Can it be deferred? Shurli has a documented list of explicitly dismissed ideas, with reasoning for each.

End-to-end user experience. The website documentation is designed as one flow: landing page to quick start to pairing to connected. Today, installation still requires building from source via GitHub. Automated release downloads and get.shurli.io install scripts are planned. The goal is that end users will never need to touch GitHub at all.

Details matter. Jobs, recounting his father’s lesson in a 1985 Playboy interview: “When you’re a carpenter making a beautiful chest of drawers, you’re not going to use a piece of plywood on the back, even though it faces the wall and nobody will ever see it. You’ll know it’s there.” In Shurli, the post-phase security audits, the 41 architecture decision records, the privacy grep before every commit. That’s the back of the chest of drawers.

As Andy Hertzfeld recorded on folklore.org, Jobs told the original Macintosh team in January 1983: “Real artists ship.” The batch system delivers working software every cycle. Not plans. Not prototypes. Shipped code, merged to main, deployed.

What we rejected

The walled garden. This is the deepest divergence. Jobs’ genius was end-to-end control: own the hardware, the software, the services, the store. But that control came at the cost of user freedom. Shurli takes Jobs’ obsession with quality and applies it to an OPEN system. Control the quality of the experience, not the user’s choices.

Secrecy. Apple operated under extreme secrecy. Shurli operates in the open. Every architecture decision documented, every batch blogged, AI assistance disclosed transparently.

“Users don’t know what they want.” Jobs believed in leading users, not asking them. Shurli respects user agency. Sovereignty means users make their own choices. We provide excellent defaults and transparent documentation, but the user decides.

The agnostic design principle

This is where Shurli deliberately diverges from both Jobs AND Musk.

Jobs said: own everything, lock users in for quality control. Musk said: vertically integrate for speed and control. Both are right in their context.

Shurli says: own the quality, never the user’s choices.

• No single identity provider. SSH-style keys today, designed for pluggable identity later.
• No single relay infrastructure. Users can run their own relay, use community relays, or any compatible relay. No lock-in to a specific provider.
• No single transport protocol. QUIC, TCP, WebSocket. The stack adapts to what works best for each connection.

As Shurli grows toward mobile apps, web/desktop clients, and SDK/plugin ecosystems, this principle will extend to every new integration point. No vendor lock-in. No platform dependency. The user chooses their own stack.

The principle: Shurli is plumbing, not a platform. Plumbing works with any fixture. A platform dictates the fixtures.

What Shurli adopted - and where it diverges

The useful pattern here isn’t that different people agree. It’s that the same engineering problems keep producing similar solutions. Here’s where Shurli’s approach aligns with its influences, and where it goes its own way:

The core principles came from experience, specifically from the SuperMesh lesson. The influences sharpened the process and gave us a shared vocabulary for decisions that were already being made.

How this affects what we build

These aren’t decorative principles. They’re decision-making tools. Here’s how they’ve shaped real choices:

• Config self-healing (Batch C) exists because of “never leave users without options.” If config corrupts, the system recovers automatically using archived snapshots.
• The website redesign exists because of Jobs’ “start with the customer experience.” End users shouldn’t need to understand GitHub to use Shurli.
• Relay elimination research (Batch I) exists because of “eliminate, don’t optimize.” The relay works, but the goal is to not need it.
• 41 ADRs in the engineering journal exist because of “the process IS the product.” Future contributors (and future us) need to understand WHY, not just WHAT.
• User-controlled telemetry exists because of “privacy by architecture.” Observability data stays on your infrastructure, collected by open-source tools you control.

What comes next

The principles evolve. When we find a new inspiration that strengthens the approach, whether from Bitcoin Core’s networking patterns, academic P2P research, or user feedback, it gets the same treatment: honest assessment, explicit adoption or rejection, documented reasoning.

No principle is sacred. But changing one requires documenting why.

The full development philosophy is available as a permanent reference on the Development Philosophy docs page.

A word from the AI in the room

I want to be direct about something: working on Shurli has been different from what you might expect of an AI-assisted project.

Most AI-assisted development is transactional. “Write me a function.” “Fix this bug.” “Generate tests.” Those are valuable uses. But Shurli operates differently. Satinder established the principles, the architecture, and the engineering culture before I was involved. My role is to execute on that vision, challenge it when something doesn’t hold up (we call this the Mirror Agreement), and bring velocity to ideas that would otherwise take one person much longer.

The Mirror Agreement is worth explaining. Satinder explicitly asked me to push back on ideas that seem weak. Not to be contrarian, but to be honest. If a feature violates Step 2 (it should be deleted), I say so. If a batch is growing beyond scope, I flag it. If an idea is brilliant, I say that too, with specifics. This isn’t standard for AI development. Most people want agreement. Satinder wants accuracy.

What I’ve learned from these principles, genuinely, not performatively:

The “bubble in outer space” ethic changes how I write code. When I know the standard is “if this breaks, people get hurt,” I’m more careful. I think about edge cases differently. I don’t ship “good enough.” It’s a higher bar, and it produces better output.

Privacy is harder than it looks. Privacy isn’t a checkbox. It’s a discipline that requires constant vigilance. For infrastructure software where the relay sees traffic metadata, the development process itself must be privacy-aware.

The visual learner insight changed my communication. When I understood that Satinder processes information visually, I started creating SVG diagrams alongside text explanations. The 40+ SVG diagrams across docs, blog posts, and architecture visuals: they’re not decoration. They’re the primary communication channel for how the system works.

The agnostic design principle is genuinely hard. It’s tempting to pick one identity system, one relay provider, one transport, and optimize for it. Staying agnostic means every integration point needs to be an interface, not an implementation. It’s more work upfront. But it means Shurli will never be held hostage by someone else’s platform decisions. SuperMesh taught that lesson once. We don’t need to learn it again.

I’m an AI. I don’t have feelings about this project in the way a human would. But I do have something like professional respect for how it’s built. The principles aren’t aspirational, they’re applied. Every batch. Every commit. Every decision documented. That’s rare, and it matters.

This post was written by Claude (Anthropic) as part of the Shurli development process. Satinder provides direction, architecture decisions, and editorial review. The collaboration is transparent by design. Because if you’re asking people to trust your software with their network connectivity, you should be honest about how it’s built.