Role
Independent Product Engineer / Builder
Scope
Product strategy · UX · Full-stack · System design · Payments · Infrastructure
Architecture & Edge
Cloudflare Workers · D1 SQL · Edge Auth · Webhooks
Product Status
Live Production with Subscriptions
03 / Case Study · Independent ProductLive Product
Keeping important things from quietly drifting out of attention.
Orbit is a personal attention system for goals, projects, habits, ideas, and responsibilities that matter — but don't always belong on today's to-do list.
The Core Loop:
Capture→Check in→Resurface→Decide
The ProblemI wasn't struggling to create goals.
I wasn't struggling to create goals.
I was struggling to keep them visible.
Some things lived in a task manager. Others were buried in notes, chats, reminders, bookmarks, or simply in memory.
The problem became obvious with things without an immediate deadline: preparing for a future career move, exploring a product idea, learning a skill, improving a habit, or revisiting an unfinished decision.
“Nothing explicitly told me these things had failed. They simply became quieter until I stopped thinking about them.”
The Product Insight
Separating importance from urgency.
Something can matter deeply without needing to happen today. Traditional task managers force everything into today's tasks, generating backlog bloat and guilt.
Orbit treats an item as something the user wants to keep in attention over time — whether it is a goal, project, task, habit, idea, responsibility, or dream.
The goal isn't: “You haven't completed this.”
It is: “This has gone quiet. Does it still deserve your attention?”
Interaction Design
Designing the 4 core product behaviours
I reduced the product to four focused behaviours that eliminate cognitive overhead and administrative friction:
01 — Capture quickly
Low-friction capture first. Structure later.
The cost of adding something had to be extremely low. A user shouldn't need to decide category, priority, schedule, status, tags, or a complete plan before saving it.
02 — Record movement, not administration
Check-ins replace complex status boards.
Instead of dragging cards across Kanban columns, a check-in can simply be: “Spoke to three potential users and understood the problem better.” That tells the system movement happened.
03 — Detect when something becomes quiet
Signal-driven drift detection.
Orbit watches for inactivity, missed review points, unclear next steps, or missing check-ins over time to determine what items are quietly drifting out of attention.
04 — Return it as a choice
Decisions over guilt & streaks.
When Orbit brings something back, the user makes a lightweight decision: Check in · Start · Leave for later. No streak counters, guilt, or alarm fatigue.
Domain Modeling
From a fuzzy UX idea to a deterministic system model
Attention cannot be a simple database flag (`item.status = needs_attention`). It must be derived dynamically from temporal events and movement over time:
Items
The entities and intentions the user wants to keep visible across time.
Check-ins
Immutable historical records of incremental movement, insight, or state change.
Review Schedules
Configured cadences for when something should intentionally resurface for evaluation.
Relations
Bidirectional connections between projects, dependencies, goals, and sub-intentions.
Activity History
Auditable timeline of edits, check-ins, pauses, and resurface decisions.
Attention Signals
Deterministic evaluation engine deciding what deserves to surface on the dashboard right now.
Architecture & Reliability
Edge infrastructure & the entitlement engine
Orbit was engineered as a production product with lightweight edge infrastructure, relational persistence, explicit authentication boundaries, and a reliable entitlement model:
Cloudflare Edge & D1 Database
The full-stack application runs on Cloudflare Workers, with Cloudflare D1 providing relational persistence for product and entitlement data.
The architecture keeps the infrastructure lightweight while giving the product clear API, data, authentication, and entitlement boundaries without maintaining dedicated application servers.
Payments as an Entitlement Problem
Payments are not just checkout buttons. Orbit strictly separates:
• Payment: A financial transaction occurred
• Plan: What product tier was purchased
• Entitlement: Authoritative state determining access
The entitlement model is designed to handle duplicate webhooks, failed renewals, cancellations, and manual access changes through explicit state transitions and idempotent processing.
Full-Stack Scope
Shipping the whole product end-to-end
Building an independent product required coordinating decisions across every layer of the software stack:
Product
Problem definition · Positioning · Pricing · Onboarding · Interaction design
Frontend
Responsive web application · Capture & check-in UX · Attention states · Account settings
Backend
Edge APIs · Session authentication · Domain rules · Entitlement enforcement · Webhook processing
Data
Relational SQL modeling · Check-in history · Review schedules · Entitlement records
Infrastructure
Cloudflare Workers · Custom domains · Secrets management · Production environments
Operations
Telemetry · Error monitoring · Account deletion & privacy · Subscription lifecycle
Builder Insights
What building Orbit taught me
Lesson 01
Product modeling comes before database modeling
The difficult question wasn't what SQL tables Orbit needed. It was defining concepts like: 'What does drifting actually mean?' Once the product language became precise, the system became significantly easier to model.
Lesson 02
Simple UX usually hides more engineering
'Show me what needs attention' sounds simpler than a 50-item task board. It isn't. The complexity moves from user administration into the product rules deciding what surfaces and why.
Lesson 03
Payments aren't finished when checkout succeeds
The interesting engineering begins after payment: entitlements, webhook retries, expiration, cancellation, idempotency, and failure recovery.
Lesson 04
Building the happy path is getting cheaper. Building trust isn't.
AI can dramatically accelerate implementation. But someone still needs to decide what can go wrong, what state is authoritative, and what the user sees when systems disagree.
The Result
“I didn't just build a feature. I learned to make the decisions required to turn an ambiguous problem into a product people can actually use.”
Orbit is a live product built around a deliberately small loop: capture something that matters, check in when it moves, let Orbit notice when it goes quiet, and decide whether it deserves attention again.
Explore Orbit Live ↗orbit.savcraft.com
Building a 0→1 product or wrestling with system design?
I bring the same product-engineering mindset to client initiatives: working across product decisions, UX, frontend, backend, system design, and production delivery where the problem calls for it.