Product-Led Engineering: Why I Start With What Matters

Engineering is a tool. Product is the decision.

At Moru I learned this daily: I was Scrum Master and Technical Lead while still shipping features UI-to-DB. The best leadership was staying close to the code. But the best product work was asking why before how. A perfectly engineered feature nobody needs is still a failure — and a small, focused product that ships teaches more than a clever architecture that doesn’t.

This is the decision stack I now use across AuraLock, CipherOnce, and consulting — told through the PEM framework: Point → Evidence → Meaning. For each filter, I state the point, show the evidence that shaped it, and explain what it means for how I build.

Code is not the product

Point: Build the right thing, then build it right.

Evidence: At Moru, I toggled between Scrum Master rituals and hands-on delivery: facilitating sprint planning in the morning, writing Kotlin and React in the afternoon, reviewing Supabase migrations in the evening. The ceremonies mattered, but the product moved when we asked: “What would make this sprint meaningful to a user tomorrow?” One sprint we cut a complex permission matrix that was already half-built — it passed code review but failed the user test (“as a support agent, will this help me ship a refund faster?”). Cutting it saved two weeks and let us ship a refund timeline users actually thanked us for.

Meaning: Engineering without a product filter is motion. Product thinking without engineering is wish. Product-led engineering means the engineer can still speak for the user — and then go build the answer. That’s why I stay close to the work even as a lead.

Three filters I use before I code

1. Philosophy veto

Point: A one-sentence philosophy must be strong enough to kill a feature.

• AuraLock: “Start with what matters, not what to avoid.”
• CipherOnce: “Your secrets are yours alone — even from us.”

Evidence: AuraLock’s gamification V1 rewarded time spent in Aura and incentivized idling. It failed the veto: “Does this reinforce intentional focus without becoming a distraction?” No — cut. CipherOnce was asked to add “team vault with searchable history.” It failed: “Does this keep the server blind?” No — searchable index needs plaintext — cut. Both cuts were painful because the features were already coded, but each deletion made the product clearer.

Meaning: If the philosophy can’t say no, it’s a slogan, not a filter. Write it so it hurts to enforce; that’s how you know it’s working.

2. Lifecycle test

Point: Can I own this from design to release to iterate?

Solo or small-team products die not from lack of ideas, but from surface explosion — new feature per platform per docs per store copy per support load.

Evidence: Before building scheduled Auras (AuraLock), I asked: can I own the native scheduling path (Kotlin AlarmManager + Supabase Edge Functions), the extension parity (declarativeNetRequest mirroring), the empty-state copy, the privacy disclosure, and the Fire/Chrome review responses — alone, in a week? Yes — scope was a single Aura schedule. Before adding “auto-expiry for shared secrets” (CipherOnce), the ownership check was: Web Crypto encrypt, Edge Function cron, and copy about fragments — also one week. Features that failed the test were reshaped until they passed: “real-time collaboration for secrets” became “one-time link with view-status” — same user value, ownable lifecycle.

Meaning: The test turns “we should” into “I will.” If you can’t own the full slice, slice smaller. Shippable beats ambitious.

3. Joy test

Point: Does using it feel intentional and calm? If it feels punitive or clever, simplify.

Evidence: AuraLock’s first enforcement was a hard lock with red warnings. Usability testers called it “stressful.” The calm version — soft haptics, “Aura active — 3 apps curated,” plus a journal close — lifted same-day completion and next-day return without changing enforcement strength. CipherOnce’s first URL design exposed the key in a query param; it was clever but scary (“is that my password in the URL?”). Moving the key to the fragment and adding human copy — “The part after # never leaves your browser; copy the whole link” — made the same crypto feel safe.

Meaning: Joy is not delight confetti; it’s the absence of anxiety. A product that respects attention earns trust, and trust retains.

What I deliberately cut

Point: Deletions are the product.

Evidence — the cut log (abridged):

• AuraLock — auto-block lists → Too parental. Failed philosophy. Expected +12% coverage, got -31% onboarding completion in test. Cut.
• AuraLock — complex rule builder → IF location AND time AND app → power-user trap, hurt the 80% use case. Cut to explicit allow-list only.
• AuraLock — leaderboards → Competitive noise before core loop retained. Cut until 7-day return was solid.
• CipherOnce — accounts → Friction > persistence. For one-time sharing, account creation added 28s median. Cut; keep no-account flow.
• CipherOnce — resend/recovery key → Would require escrow. Cut; add fragment preservation warnings instead.
• Both — premature distribution → Resisted Product Hunt until store reviews stabilized.

Meaning: Each cut increased clarity. When users can explain your product to a teammate in one line — “pick what stays” or “key after #, we never see it” — distribution becomes cheap. Until that line is crisp, adding features is hiding.

Stay close to the work

Point: I work across frontend, mobile, backend, native Android, testing, and release — not to be a generalist for its own sake, but to keep the product coherent.

Evidence: On AuraLock I touched: React Native UI, Kotlin Bridges (UsageStatsManager, AccessibilityService, ForegroundService), Next.js + Supabase backend (Auth, Postgres, Edge Functions for schedules), and MV3 extensions + store assets. On CipherOnce: Next.js App Router, Web Crypto AES-256-GCM, Supabase Edge Functions, CSP hardening. The same hands wrote the privacy policy line and the regex that checks it.

Meaning: Cross-stack ownership isn’t about heroics; it’s about tradeoffs. When you own the full stack, you can ask: “If we can’t enforce this reliably on Samsung’s battery saver, should the UI promise it?” and then fix the promise. Coherence is the compounding advantage solo builders have over teams with handoff silos.

How I ship — the weekly loop

Point: Ship weekly. Let rhythm beat intensity.

Monday veto (one scope call), Tue–Thu build, Fri test on 3 OEMs (Pixel, Samsung, Xiaomi — variance is real), Sat store/screenshots/docs, Sun journal + next veto. The loop is calm on purpose.

Evidence: This loop took AuraLock from zero to Play Store and keeps CipherOnce iterating without churn. Weeks I broke the loop to “move faster” produced clever code and vague copy — both of which users felt as confusion.

Meaning: A gentle cadence is a strategy, not a vibe. When you ship every week, you don’t need to be right; you just need to be clear enough to learn.

PEM in one page — your starter template

Use this when you’re tempted to code too soon:

1. Write the philosophy as a veto: One sentence that can kill a ticket.
2. Run the lifecycle test: List the 4 surfaces you’ll own (UX, code, docs, release). If you can’t own it this week, split it.
3. Run the joy test: Show it to one user for 15 seconds. If they don’t feel calm, simplify copy before code.
4. Log the cut: For every feature cut, write why in one line. The log is your strategy.
5. Ship and read the evidence: Completion, return, support load — not vanity time-on-page.

Takeaway — PEM summary:

• Point: Product-led engineering means philosophy first, then lifecycle ownership, then joy — code last.
• Evidence: AuraLock’s inversion (+38% completions), CipherOnce’s fragment (+0 plaintext on server), Moru’s permission matrix cut (2 weeks saved), gamification V3 (+18% 7-day return), no-account CipherOnce (-28s to share).
• Meaning: Build the right thing, then build it right. And ship — every week you ship, you learn. If you stay close to the work and let a strong filter decide scope, coherence compounds and products feel inevitable.

If this resonated, peek at the deep dives: How I Shipped AuraLock and Zero-Knowledge CipherOnce — each is the same filter applied twice, once for focus, once for security.