Topic Guide
Running a SaaS Lean: Product Calls and the Tooling That Holds It Together
Running a real, paying SaaS product with a small team removes a thing you don't notice until it's gone: a hallway full of people to route every decision past before it ships. Every product call in this hub, a dialog that had to die, a pricing model that had to separate subscription cost from per-event cost, a badge-covered list row replaced with one honest sentence, got made and shipped by one or two people, not a department. What replaces the missing headcount is a discipline: read the actual friction before deciding, check whether an existing pattern is already almost right before inventing a new one, and revisit a call in public when it turns out wrong.
The other half of this hub is the tooling that makes running lean survivable at all. A backlog that had been quietly lying for weeks about what was actually in progress. Dashboards that stopped centering on busy-looking activity and started answering the one question that matters: what needs a decision next. A backup job that had been silently dead for three weeks, found by accident during an unrelated repo split. None of this is glamorous work. It's the maintenance a bigger team would normally split across more people, caught here by whoever is watching that day.
The posts closest to the surface are the operator's own week: fifty-one wrong review verdicts caught before they shipped, a hundred and thirty-six bounced emails traced back to real orders, two apology drafts that never got sent because nothing is authorized to send them. Running lean doesn't mean fewer decisions. It means every one of them has to be caught by the few people actually watching.
41 posts in this guide, by DX
Start here
The 'AI runs the company alone' story everyone is writing, with git receipts
One week of receipts from running a legacy platform through AI agents the way the WSJ's solo-founder profile claims is possible, minus the solo part: 51 wrong review verdicts, 136 bounced emails traced back to orders, and two apology drafts nothing is allowed to send.
Product and UX calls made end to end
-
Trading Badge Soup for One Human Sentence
I deleted four metadata badges from a list row and replaced them with one state-aware sentence like 'Waiting on you'. A list view serves one decision per row.
-
An Evening of Progressive Disclosure: Four Commits to Hide Everything Behind 'Details'
Four commits in two hours to hide a wall of fields behind one Details seam. Progressive disclosure is a convergence you iterate into, not a one-time call.
-
Routing Logic That Does Work on the Way In: Redirect, Auto-Select, or Prompt
Resolve a page's selection prerequisite on entry: redirect on zero options, auto-pick on one, prompt on many. The expensive fetch only fires once something is selected.
-
First-Time Use Is Part of the Product
A feature may work for experienced users while failing for people arriving without inherited setup.
-
The Create-Event Dialog Had to Die
A complex tournament form improved after a product review reconsidered its container. The lesson is not that dialogs are always wrong, but that form scope, lifecycle, and mobile use should determine the interaction surface.
-
When a Familiar Screen Makes a Simple Job Harder
Repeated fixes can be a sign that the work has outgrown the way it is being presented. Before improving another detail, ask whether the process still fits the task people need to complete.
-
When the System Cannot Know Intent, Make the Decision Explicit
Some write actions have more than one legitimate outcome, but the deciding fact is not in the data. A trustworthy system does not silently guess: it explains the conflict, offers only authorized and supported choices, validates the decision on the server, and records the result.
-
Before adding a new option, ask whether the existing one is almost right
A feature request can look like a request for a new branch of the product. Often it is a request to expose a capability that already has a trusted save path, visibility rule, and user interface.
-
A Product Model Cannot Live in Scattered Assumptions
Different screens can each sound credible while describing different versions of the same product.
-
A Pricing Change Is Not Real Until Its Rules Are Clear
A pricing idea becomes real only when the conditions that allow, limit, and verify it are explicit enough for people to review.
-
The Bundle-Ceiling Model: Separating Subscription and Per-Event Cost
A two-layer tournament-pricing redesign separated recurring platform access from one-time event capacity, then used membership eligibility to keep the resulting choices legible.
A migration that turns into a platform decision
-
The Migration Ticket Was Hiding a Landing Page
A redirect ticket concealed a broader user-orientation problem. In this product move, the destination needed context, clear positioning, and a maintained landing surface, not only a URL change.
-
A Redirect Is Not an Orientation Plan
Moving someone to a new place does not explain what they found or what to do next.
-
The blog merge that turned into a platform decision
Folding dxdev-blog into dxdev-landing was supposed to be content migration. It became schema design, renderer archaeology, and a question about what the public surface of a product should reveal.
-
A Content Move Can Become a Platform Decision
A small migration can become a larger decision when it changes how people publish, find, govern, or maintain shared work.
-
Before You Build a New Door, Check the Building
A request for a new path can hide a usable path that already exists but is hard to find, explain, or trust.
Measuring the work honestly
-
A Work Metric Should Count the Work Once
A flattering total can be wrong when the same work appears in several places.
-
Same SHAs in Two Repos: Why Commit-Count Metrics Lie in a Clone Workflow
A commit-count script treated mirrors and local clones as separate work, turning 23 unique commits into an inflated total of 134. The fix was to aggregate unique commit IDs, not repository directories.
-
Do Not Improve a Dashboard Until You Know Its Job
A familiar dashboard can consume attention and time without helping anyone make a better decision.
-
A Good Dashboard Tells You What Needs You Next
A busy screen can show every recent activity and still leave people unsure where to start. A useful work view puts the next point of human attention ahead of the activity log.
-
The dashboard got better the moment I stopped centering sessions
Rebuilding a work-tracking dashboard around Area, Epic, and Task instead of sessions. What WAIT_HUMAN detection unlocked, and the tax of renaming 19 directories to strip dates from IDs.
-
Busy Time Is Not the Same as Progress
When work happens in parallel, a larger activity number can look impressive without showing whether the work was useful, reviewed, or ready for the people affected by it.
-
Parallel Work Needs More Than a Clock
Elapsed time, concurrent process time, human attention, and verified outcomes are different measures. Once work happens in parallel, a useful record must preserve provenance, uncertainty, review state, and the limits of what any productivity metric can claim.
Backlog and ticket tooling that tells the truth
-
If Your AI Workflow Only Exists in Comments, You Have Exhaust
A backlog cleanup exposed a boundary between readable AI commentary and operational state. When an output must drive routing, filtering, or review, it needs a documented structured representation as well as its human-readable rationale.
-
I Built a Triage Cockpit Because Context Switching Was Eating the Day
A backlog becomes hard to manage when every decision requires rebuilding context across disconnected tools. A focused decision surface can reduce that friction, provided its actions remain authorized, auditable, reversible where possible, and grounded in current evidence.
-
Parked Is Not the Same as Waiting
Two items can both look inactive while needing entirely different next actions. One may be waiting for someone. Another may be deliberately parked.
-
A Backlog State Should Tell You What Happens Next
A single backlog label hid two different conditions: deliberate deferral and an external dependency. Making next-action ownership, follow-up, review timing, and rationale explicit produced a more truthful queue and reduced repeated context reconstruction.
-
The dormant-project tripwire: make the unknown visible
A small project inventory stopped quiet repositories and leftover automation from disappearing from view. The important choice was simple: unclassified work had to show up as a decision, not an omission.
-
One mixed QA ticket can slow down every independent fix
A single QA report may contain several different kinds of work. Splitting independent findings gives each one an honest owner, scope, verification path, and release decision-provided the parent retains an auditable map.
-
When a work queue stops telling the truth
A priority label can quietly become a history marker. The fix is not a bulk cleanup; it is restoring a clear difference between work in progress, planned work, and the links that keep unfinished work findable.
-
When AI Makes Analysis Cheap, Your Decision UI Becomes the Bottleneck
AI made ticket analysis nearly free, which exposed the real cost: a read-only backlog page. Inline verbs turned tab-thrash into one-click decisions.
Auditing your own infrastructure
-
My backups had been dead for three weeks. I found out by accident.
I split a sprawling AI ops monorepo into five sibling repos. The rename exposed runtime automation that had been silently dead for weeks.
-
A Migration Became the Audit I Had Never Run
A repository move exposed external automation and a backup job that no longer produced the expected artifacts. The lesson is to treat any substrate migration as an inventory-and-verification exercise, not a search-and-replace task.
Deciding what to build now, and what to defer on purpose
-
Defer Work With a Trigger, Not a Vibe
Later is not a plan when no one knows what evidence will make the work necessary.
-
Do Not Defer on a Vibe: Use Named Decision Triggers
Defer a reversible capability with a named, measurable trigger. Pull a decision forward when waiting expands security, privacy, compliance, data-integrity, contractual, or migration risk. Good timing is an explicit policy, not a hunch.
-
When a Manual Workflow Hurts in Seven Small Ways, the Seven Ways Are Your Spec
One manual ticket close surfaced seven papercuts, and each one became a hardcoded default or halt condition in the tool. A friction list is a spec.
Splitting your own tools from the product you sell
The content pipeline is a product too
-
When a Content Workflow Needs Explicit State
A folder of Markdown remains a good source of truth for many publishing workflows. As concurrent contributors, approvals, structured review, traceability, and governed automation grow, an explicit state model and scoped authority become more important than the storage technology itself.
-
Don't Publish Into a Void: Baking Revenue Attribution Into the Schema on Day One
The outcomes table ships in wave one of my content pipeline, because you cannot backfill revenue attribution for posts published before it existed.
-
A Content Workflow Needs States People Can See
A content process becomes hard to trust when draft, review, approval, publication, and correction exist only as assumptions or messages.
Hitting one of these walls in your own codebase or your own machine? Talk it through with us, or read the rest of the Build Log.