Development Philosophy
The principles, inspirations, and decision-making framework behind Shurli’s development.
How it started
Shurli started when Satinder wanted to access OpenClaw from outside his home network. Every alternative meant routing through someone else’s infrastructure to reach his own data. Tailscale would have worked, but it requires an online account and the free tier has limits. So he tried a different approach: “I’ll just code the simplest silly tool using AI and see if it works.” It worked. Features grew naturally from real needs, one at a time. The principles emerged from development conversations, not a predetermined manifesto.
For the full origin story, see the blog post.
The founding ethic
Every technical decision in Shurli flows from a moral commitment: if this software breaks, people who depend on it get hurt. Financially, psychologically, and potentially physically. This isn’t a quality standard. It’s the reason the project exists the way it does.
In practice: No silent failures. No data hostage. No trust assumptions. No “good enough” security. The relay is treated as hostile until proven otherwise.
Core principles
1. Never build on what you can’t control
Origin: In 2015, Satinder built SuperMesh on top of CJDNS. CJDNS stalled. SuperMesh couldn’t survive without it.
Applied: Single binary, own DHT namespace, libp2p as a library (forkable), no external auth provider, no cloud dependency.
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, so every feature is tested against this constraint.
3. Lead with outcomes, not protocol
Nobody cares about DHT or circuit relay. They care about “access my home server from anywhere.” 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 wizard. Simplify the config. Every component is a candidate for deletion.
5. Let the work speak
Never disparage competitors publicly. Never engage with trolls. Describe what Shurli does. Let users compare. The best response to criticism is better code. This applies to all public content.
6. Never leave users without options
Every error message includes next steps. Every failure path offers alternatives. Escalation: 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. Mandatory security audit after every development batch.
8. Privacy by architecture
User data never touches infrastructure the user doesn’t control. No cloud accounts. No phone-home. The default is privacy. Always.
Observability and telemetry are planned, but user-controlled. All collection, storage, and analysis happens on the user’s own infrastructure using open-source tools. Enterprise users get the data quality they need. Home self-hosters keep full control. No bytes sent to us. Ever.
9. The process IS the product
The engineering journal, batch system, and post-phase audits aren’t bureaucracy. They’re the project’s immune system. A project that can’t be understood by others can’t survive its founder.
10. Sovereignty over convenience
Shurli exists for people who choose sovereignty over convenience. No accounts, no cloud dependency, no phone-home, no vendor lock-in.
Inspiration: Elon Musk’s 5-step process
After the core principles were established, we recognized strong alignment with Musk’s engineering process, what Walter Isaacson called “the algorithm”, first explained in detail during the 2021 Everyday Astronaut Starbase tour:
| Step | Musk | Shurli equivalent |
|---|---|---|
| 1. Make requirements less dumb | Question every requirement | Explicit dismissals with documented reasoning |
| 2. Delete the part | “The best part is no part” | Relay elimination research, removing unnecessary commands |
| 3. Simplify/optimize | Only after deleting | Simplify config before adding wizards |
| 4. Accelerate cycle time | Go faster (after 1-3) | Docker integration tests, deploy pipeline |
| 5. Automate last | Don’t automate broken processes | CI/CD after manual process proves out |
Adopted from Musk
- First principles thinking - reason from fundamentals, not analogy
- Vertical integration - own the critical path, use libraries for commodity
- “Manufacturing IS the product” - the batch system and audits ARE the deliverable
- Mission-driven engineering - “bubble in outer space” parallels “making life multiplanetary”
Rejected from Musk
- Public combativeness - rejected as a net-negative use of time and focus. Every hour on public fights is an hour not spent writing better code
- “Break things” in production - Shurli is infrastructure where failure hurts people
- Vendor-controlled telemetry - observability yes, but user-controlled. Data stays on the user’s infrastructure, never ours
Inspiration: Steve Jobs’ design philosophy
Jobs’ principles on simplicity, design, and user experience directly shaped the shurli.io website and documentation strategy.
| Jobs Principle | Source | Shurli equivalent |
|---|---|---|
| “Simple can be harder than complex” | BusinessWeek, 1998 | Two commands from zero |
| “Design is how it works” | NYT Magazine, 2003 | SVG docs, visual-first communication |
| “Say no to 1,000 things” | WWDC 1997 | Explicit dismissals, batch scoping |
| “Start with the customer experience” | WWDC 1997 | Lead with outcomes, not protocol |
| Details matter (“back of the chest of drawers”) | Playboy, 1985 | Post-phase audits, engineering journal |
| “Real artists ship” | folklore.org, 1983 | Batch system delivers every cycle |
Adopted from Jobs
- Simplicity as discipline - make it BE simple, not just look simple
- Design is function - visual docs and website design serve comprehension, not decoration
- End-to-end experience - documentation is self-contained; automated install scripts planned so users won’t need GitHub
- Detail obsession - security audits, ADRs, privacy checks on parts nobody sees
Rejected from Jobs
- Walled garden - Shurli’s agnostic design is the philosophical opposite of Apple’s closed ecosystem
- Secrecy - Shurli operates fully in the open (28 ADRs, AI disclosed, blog documenting every batch)
- “Users don’t know what they want” - Shurli respects user sovereignty and agency
The agnostic design principle
This is where Shurli deliberately diverges from both Jobs and Musk.
Jobs said: own everything, lock users in for quality. Musk said: vertically integrate for speed. 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 - run your own, use community relays, or any compatible relay
- No single transport - QUIC, TCP, WebSocket. The stack adapts
As Shurli grows toward mobile apps, web/desktop clients, and SDK/plugin ecosystems, this principle extends to every new integration point. No vendor lock-in. No platform dependency.
Shurli is plumbing, not a platform. Plumbing works with any fixture.
Alignment and divergence
| Dimension | Shurli | Musk’s influence | Jobs’ influence | Alignment |
|---|---|---|---|---|
| Simplicity | Two commands | Delete the part | Simple > complex | Adopted from both |
| Focus | Explicit dismissals | Challenge requirements | Say no to 1,000 | Adopted from both |
| Shipping | Batch system | Accelerate cycle time | Real artists ship | Adopted from both |
| Quality | Post-phase audits | Factory IS the product | Back of the chest | Adopted from both |
| User control | Sovereignty, agnostic | Vertical integration | Walled garden | Diverges |
| Privacy | User-controlled telemetry | Vendor telemetry | Moderate telemetry | Diverges |
| Transparency | Open engineering journal | Selectively open | Extreme secrecy | Diverges |
| Competition | Let work speak | Public combativeness | “Holy war” marketing | Diverges |
The core principles came from experience. The influences sharpened the process and gave a shared vocabulary for decisions that were already being made.
How principles evolve
New inspirations get the same treatment: honest assessment, explicit adoption or rejection, documented reasoning. The intellectual lineage so far:
- Core principles (emerged during development) - from the SuperMesh lesson, P2P ecosystem experience, moral conviction, and development conversations
- Musk’s 5-step process (adopted 2026-02-19) - engineering process discipline
- Jobs’ design philosophy (adopted 2026-02-20) - simplicity, user experience, visual communication
No principle is sacred. But changing one requires documenting why.
AI-assisted development
Shurli is built with AI assistance (Claude, by Anthropic). The architecture, design decisions, and direction come from human judgment. AI helps with code generation, documentation, and systematic analysis.
We believe in transparency about this. The quality of the code speaks for itself. Every line is reviewed, tested, and shipped with the same rigor regardless of who wrote the first draft.
For the full narrative of how these principles evolved and how they’re applied in practice, see the blog post.