Case study · My own product · Shelved on purpose
I killed my own product. The hard part was proving I was reading the right number.
ReplySequence turned sales meeting transcripts into sent follow-ups. It works, it is built, and it is on a shelf. This is the story of the month between deciding it had failed and finding out that the first test had measured the wrong thing entirely.
What this case study does not contain
No growth numbers, no user counts, no revenue. Not because they are embarrassing, though some of them are, but because every one of them measures a distribution channel that turned out to be faulty, and quoting a contaminated number as a result would repeat the exact mistake this page is about. What is here is the sequence of decisions, with dates, and the one correction that reversed the conclusion.
What it was
Sales calls get recorded and transcribed by tools people already pay for. The follow-up email that should come out of that call gets written from memory, hours later, badly, or not at all. ReplySequence sat between the two: it read the transcript, drafted the follow-up in the rep's own voice, and sent it from the rep's own mailbox in about a minute.
Bring your own transcript, bring your own mailbox. It plugged into the meeting recorders teams already ran rather than asking anyone to switch, and it never held the sending relationship, which mattered for deliverability and for trust.
The build was not the problem. It shipped, it worked, and the thing it automated was a real chore. Every failure below happened downstream of a product that functioned.
The correction the whole project turns on
Fifteen sent, zero replies. That was not a market answer.
The first real demand test went out to fifteen matched prospects and came back completely silent. Read at face value, that is about as clear a signal as a founder ever gets, and I read it that way for a while.
What the number looked like
Nobody wants this.
Fifteen well-targeted messages, zero replies. The send reported success. Nothing errored. The number was real and it was correctly calculated.
What it actually measured
Nobody received this.
A brand new sending domain with no warming history, pushed through infrastructure built for transactional receipts rather than cold outbound. The messages very likely never reached an inbox anyone looked at.
Those two conclusions produce identical output. Zero replies looks exactly the same whether the market rejected you or the mail never arrived, and only one of them is about your product. A month went into the wrong one.
The fix was not better copy. It was changing the channel to one with no deliverability layer in the way, so that whatever came back would at least be interpretable. That is the whole discipline: before you accept a disappointing number, establish that the instrument producing it works.
What got built along the way
Everything below is running today, on a product nobody is selling. It is here because it is the part that transfers.
A content pipeline that did not stop when the product did
Automated drafting, publishing and refresh, running on a schedule since before cold storage and still running now. Turning off a product and turning off its domain are two different decisions, and conflating them throws away an asset that costs almost nothing to keep.
A page-weight fix found by measuring, not by guessing
Blog pages were shipping over two megabytes of images each because the body content bypassed the framework’s image handling entirely. The first diagnosis blamed the hero image, which turned out to be six kilobytes. Measuring properly moved a page from roughly 2,343 KB to 23 KB, verified live rather than assumed from the build.
A sitemap guard that was proven to fail first
A drift check that keeps the sitemap honest, written so that it was verified to fail without the fix before being trusted with the fix in place. A test that has never failed is not evidence of anything.
An orphaned section reconnected
A whole product section had zero inbound internal links, so roughly 168 pages sat outside the site’s own link graph. Deleting it was floated and declined. An orphan is a linking problem, not a content problem.
The decision, and why it has a date on it
The product went to cold storage on 2026-06-17. A formal go/no-go on 2026-08-14 confirmed it and recorded both halves in one line: cold storage on the product, keep the domain. A separate decision on 2026-07-31 cancelled the plan to shut the workspace down.
Dates matter here for an unglamorous reason. Between the decision and the go/no-go, the tracking task for it was closed without the decision being made, and for about five weeks the question looked settled to anyone glancing at the board while actually being open. Closing the card that tracks a decision is not the same as making it.
Since then the recorded decision has done real work. Twice, automated tooling of mine has tried to decline legitimate infrastructure work on this project by citing cold storage, because the note it read said the product was shelved without saying that the infrastructure was not. A decision that is written down imprecisely gets applied imprecisely, forever.
What I take into client work because of this
An unexplained zero is a broken instrument until proven otherwise
A collector that fails returns nothing. A channel with no demand returns nothing. They are the same output and opposite facts. Before accepting any disappointing number, I run the cheapest available control: send one message to an address I own and check it arrived. It costs minutes and it would have saved a month here.
Write the decision down with its boundaries, not just its verdict
Cold storage on the product was correct. Cold storage as an unqualified sentence was wrong, and it kept being read as covering everything. Every standing decision I record now names what it does not cover.
Killing the product is not the same as killing the asset
The domain, the content and the search presence were built for a product that no longer ships, and keeping them costs almost nothing. Shutting everything down in one gesture is tidy and it destroys the half that was still working.
Being willing to shelve your own work is the whole qualification
I am asking clients to let me tell them that something they have paid for is not working. It would be strange to sell that and never have done it to myself.
Most bad numbers are measurement problems.
An audit maps what you are actually measuring before anyone argues about what to do with it. That distinction is usually where the money is.
Questions people ask
Is ReplySequence dead?
The product is in cold storage, decided 2026-06-17 and confirmed at a formal go/no-go on 2026-08-14. That means no new features, no marketing, no roadmap. The domain, the content pipeline and the billing infrastructure are deliberately still running, because those are a different asset from the product and killing them was never the decision.
Why publish a case study about something that did not work?
Because the transferable part of this project is the decision, and the decision was the hard bit. Building the thing was ordinary. Working out whether the silence coming back meant nobody wanted it, or that nobody had received it, took a month and one correction that reversed the answer entirely. That is the same problem every client has when a channel underperforms, and most of them are one bad inference away from cutting the wrong thing.
What was the measurement failure?
The first demand test sent 15 messages and got zero replies. Read at face value that is a clear market answer. It was not one. The sending mailbox was new and unwarmed, and the whole batch went out over transactional infrastructure that was never built for cold outbound, so the messages were very likely not being seen at all. The test measured deliverability and was reported as demand. Nothing about that failure looked like a failure: the send succeeded, the tool reported success, and the number that came back was a real number.
How do you know the second read was any better?
Because the second attempt changed the channel rather than the copy. Moving to manual outreach on a platform with no deliverability layer removed the variable that had been contaminating the first result. That does not make the answer flattering. It makes it interpretable, which is the only thing a test owes you.
What would you do differently?
Run the cheapest possible control before trusting any zero. One message to an address I own, checked on arrival, would have caught the deliverability problem on day one for no cost. I now treat an unexplained zero as a broken instrument until something proves otherwise, and that habit came directly out of this.
Does this mean you will tell me to kill my project?
Sometimes, and you should want an outsider who is willing to. More often the useful answer is narrower: the thing being measured is not the thing you think you are measuring. That is worth finding out before you spend another quarter on it, and it is most of what a workflow audit actually produces.