The first test we ever wrote was on day ninety-eight
A 771-line daemon appeared in the two minutes between one commit and the next. Eight minutes later, the repository acquired a test suite for the first time.
Email sequences were added to this product on 2026-02-02 at 14:53, as one item in a commit whose subject line runs to 245 characters and promises sixteen features while listing fifteen.
They were removed at 15:22. Twenty-eight minutes of life.
They came back ninety-one days later, and the second attempt is the reason this entry exists.
The rebuild started at midnight on 2026-05-07 with a visual canvas: drag nodes onto a grid, connect them, and the shape you draw is the sequence. Seventeen hundred lines, a vendored graph library, a new stylesheet, two new templates. That is the part users can see, and it is the part that would spend the following week fighting back.
The part that matters ran eighteen hours later, between 18:42 and 19:25, in nine commits.
Seven hundred and seventy-one lines in two minutes
At 18:42 a commit added the database schema for tracking individual sequence step runs. At 18:44 the next commit added workers/sequence_executor.py, at 771 lines, plus the wiring to start it on boot.
Two minutes. I am not going to pretend a 771-line daemon was composed in 120 seconds, because it obviously was not. What those two timestamps actually record is that the schema and the worker were written together, as one thought, and split into two commits at the end so the history would read sensibly. That is a small dishonesty in the log and I would defend it: the commits are shaped for the person reading them later, not as a stopwatch.
What the daemon does is unglamorous. It wakes up, asks the database which enrollments are due, sends what needs sending, records what happened, and works out when to wake up again. A sequence is a graph and the executor is the thing that walks it, slowly, over days, on behalf of people who are asleep.
Then, at 18:46, an endpoint to pause and resume an enrollment, including automatic pausing when a prospect replies. At 18:48, the panels in the interface that let you see any of this happening. At 18:51, a sweep of analytics events across the whole flow.
And at 18:53, this:
Phase A.2: pytest tests for executor (3-step + branch + pause + cap)
Four files. A pytest configuration file, a conftest.py, an __init__.py, and 264 lines of tests. This is the first test suite in the entire repository. The project was ninety-eight days old.
Why it took ninety-eight days, and why it was this feature
For ninety-eight days this codebase had no automated tests of any kind. Not thin coverage. None. And I want to be careful here, because there is a very tedious version of this story where the moral is "always write tests," delivered by someone who has never shipped anything on a deadline.
The honest reason there were no tests is that for ninety-eight days, every single feature was verifiable by looking at it. You add a prospect, the prospect appears. You click a button, a modal opens. The application was a thing a human could exercise completely in about ten minutes, and for that shape of software, a person clicking around genuinely is a reasonable test strategy. Slow and unreliable, but reasonable.
The sequence executor is the first thing in this product that you cannot look at.
It runs in a background thread. Its interesting behaviour happens over days. The bug you care about is "on step three, when the prospect replied between the send and the next tick, does the enrollment stop or does it keep going," and there is no amount of clicking around that answers that question this afternoon. You would have to wait four days, with real prospects, and if the answer was wrong you would find out by having emailed someone who had already told you to stop.
That is what changed. Not discipline, and not maturity. The product grew its first feature whose correctness was invisible, and invisible correctness is precisely and only what tests are for. The four cases in that first file are the four things you cannot see: a three-step sequence completing, a branch taking the right path, a pause holding, and a daily cap holding.
Everything else in the app was still untested that night, and stayed that way for a while. The tests went where the darkness was.
The last two commits of the session are my favourite kind of detail. At 19:23, "strip em-dashes from sequence executor diff per locked rule." At 19:25, a handoff document recording the audit and the sweep.
There is a standing rule in this project that em dashes do not appear in product copy. It exists because a certain punctuation habit reads as machine-written, and a site full of it looks like a site nobody wrote. On the night the first daemon and the first test suite shipped, the session's last half hour went on the fact that some strings in the diff contained the wrong dash: five characters changed, across three files. A one-character-wide house style, enforced on a background worker, at half past seven in the evening.
The tests, incidentally, were written eight minutes after the daemon and about a minute before the changelog entry announcing it. Which means the order of operations that night was: build the thing, prove the thing, tell people about the thing, then fix the punctuation. I have seen far worse orderings, including in companies with a QA department.
Ninety-four days between a feature being deleted for being too much and the same feature returning with a graph editor, a daemon, and the first tests anyone here had ever written. Sequences were worth doing properly. They were just not worth doing on 2026-02-02 at ten to three in the afternoon.
— DealArena Team