3,853 Additions Before the First Useful Number

My first count of active paid accounts was the number of accounts whose expiry date was still in the future, and it was wrong. That count quietly included trials, internal test groups, and branches of the account structure that were no longer active, so any conversion or renewal figure built on it would have pointed attention at the wrong accounts. The fix was not a better table but a written set of rules for what belongs in the count, and that is the work I ended up doing across five new report pages in an older admin area.

The pages covered packages, conversions, renewals, the overlap between conversion and renewal, and the total value of sales over a customer’s time with us. On paper, that sounds like a lot of separate work. In practice, I gave each one the same simple shape: a place that gathers the rows, a page that turns them into a table, and a bit of styling that keeps the table readable. Once I had that recipe, adding another report was no longer a scavenger hunt through old code. It was more like using the same recipe card for five dinners, then changing the main ingredient.

That consistency mattered because the admin was old. There was no shiny new reporting service sitting beside it. The reports had to live with the rest of the application, in a form that someone could come back to later and understand. I used the same page pattern each time, with the starting steps, button actions, and drawing of the page kept together. If I could follow one report, I could follow the next one without spending half an afternoon figuring out where everything had been hidden.

Then I went after a number that should have been easy: how many paid accounts were active right now. My first pass did not work. I counted accounts whose expiry date was still in the future. It gave me a number, but not a number I could trust.

Some of those accounts were trials. Some belonged to internal test groups. Some were attached to parts of the account structure that were no longer active. Leaving any one of those in the pile would make a conversion or renewal figure wrong. That is the part people often do not see when they ask for a report. The hard work is not making a table. It is agreeing on what belongs in it.

The cost of that first, easy answer was the time it took to spell out the real rules. It also carried a more serious cost: a wrong renewal number can put attention on the wrong accounts. I had already spent too many years learning that a report is only as honest as the small decisions underneath it.

The scary term here is SQL. It is simply a way to ask a database a very exact question. I used it to write down the rules instead of trusting myself to remember them later. For the renewal work, I made a separate review file and kept it beside the report code. It found accounts that had expired during a chosen period and had paid at least once before. It also found the last payment before each account expired.

That file matters because it turns a vague sentence, such as “lapsed paying customer,” into something another person can check. The trial accounts are out. The internal test groups are out. The inactive parts of the account structure are out. The expiration window and past payment are in. If the resulting number ever raises an eyebrow, there is a written trail back to the exact rule that produced it. I do not have to rely on memory or reopen an old query window and hope I recreate the same answer.

There was another wrinkle. Years of real use had left some broken records in the account structure. A few pointed to parents that did not exist. A few had priority values that should never have been there. A few were half deleted in ways the system allowed, even though ordinary use did not expect them.

A single broken record can disappear inside a normal screen. A report is less forgiving because it adds up everything. One bad row can spoil the total or stop the whole report from loading. So the report checked for the known bad shapes before adding anything together. It repaired or skipped those records rather than letting one old mistake decide whether a whole page worked.

All five pages went out together in one feature branch, which is just a separate bundle of changes that can be reviewed and merged as one. That made sense because the work added new admin pages without changing an existing customer flow. A more delicate change, one that could disrupt a live action, would deserve a smaller release that is easier to undo. The size of a release should match what can go wrong, not follow a ritual.

The first number I trusted in this project was not 3,853. It was the one that came after I wrote down the renewal rules: expired inside the chosen window, at least one payment before that, no trials, no internal test groups, no inactive branches of the account structure. Each of those exclusions changed the count, and the review file kept beside the report code is the only reason I can say by how much. The earlier figure, accounts whose expiry date was still in the future, looked fine right up until I asked what was in it. A count like that is only worth acting on once its exclusions exist as a query someone else can open and rerun.

dxdev LESSON · paste into your AI coding agent
LESSON: A report is only as honest as its written exclusion rules
SOURCE: dxdev.com/blog/2026-02-24_3-853-additions-before-the-first-useful
WHAT HAPPENED: Five new admin report pages needed an "active paid accounts" count. The first version counted every account with a future expiry date, which silently included trial accounts, internal test groups, and inactive branches of the account structure, producing a number that could not be trusted for business decisions. The fix was writing the inclusion and exclusion rules into a standalone SQL review file kept alongside the report code, and adding a defensive check for known-broken account records, such as dangling parent references or invalid priority values, so one bad row couldn't corrupt or crash the whole aggregate.
THE RULE: A number used to drive a business decision needs a written, checkable definition of what is included and excluded, kept next to the code that produces it, not just a query that happens to run without erroring.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any active, paid, or renewed style count derived from a date comparison alone, without explicitly excluding known non-customer categories like trials, internal, or test accounts.
  2. Any aggregate report query with no accompanying written rule file describing exactly what rows are in and out of scope.
  3. Any report or aggregation that would fail or silently corrupt its total on a single malformed row, rather than detecting and skipping or repairing known-bad shapes before summing.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.