The 120,000-yuan system that died in a month

A 29-person building-materials company could not use off-the-shelf software, because the way it quoted, ordered and tracked material did not line up with any product. So it paid for custom work: 120,000 yuan, roughly a year, delivered by an outside team. The system went live and the owner killed it inside a month. He then learned enough to build the replacement himself, and that one ran.

The comfortable reading is that the vendor was bad and the owner happened to be technical. Neither is what the record supports. The owner's account is narrower and more useful: the first system was accepted by someone other than the person who would use it, and the second is accepted every day by the person who does.

All figures here are the sharer's own. The case is short, and the missing sections are marked as missing.

What was bought, and what it cost

The purchase was a custom ERP matching how the firm actually worked. Off-the-shelf products were the alternative and they had already failed. The material does not say which service line earns the firm's money, or what share of revenue the system was meant to protect. That part of the anatomy is absent.

What is recorded is the cost and the stop rule. One year and 120,000 yuan, then a month of live use. The owner's stated reason for killing it was not the sunk money but the forward look: at the speed and quality on display, continuing would have cost another year.

That distinction is the only financial judgement in the record, and it is a sound one. Sunk cost is not a reason to continue; a credible forecast of the next year is a reason to stop. There are no percentages, no hours saved and no before-and-after numbers for the first system — any such figure would be invented.

The three maps

Mostly absent. The one line that is recorded matters: the person who paid for it, the person who used it and the person who killed it were the same person. That collapses the money map and the power map into one seat, which is why the stop decision could be taken in a month.

No other roles appear. Who lost when the ERP was dropped, who had to change how they worked, what else those people were responsible for — none of it is in the material. For a 29-person firm that is a large omission, because the staff who type into an ERP are exactly the people it is supposed to serve.

Where the judgement was wrong

Acceptance. The first system was signed off on module completion — this part is built, that part is built — by people other than its user. The signal arrived one month after go-live, when the owner tried to run the business through it and could not.

The record is a retrospective, not a weekly log, so there is no week number and no single moment of discovery. What it does give is the corrected rule, stated by the buyer: a finished module is not acceptance; a business flow running end to end, operated and confirmed by the person who owns it, is.

That correction should be generalised carefully. It does not mean the owner should have written code. It means acceptance has a subject, and outsourcing moves that subject out of the room. When a vendor accepts its own work against a module list, the only thing being tested is whether the modules exist.

What lived

The self-built replacement: three tools and one agent, running in production, with a daily operating summary delivered to the owner on WeChat. The cost basis changed too — an AI coding subscription plus the owner's time directing changes, against a six-figure quote for equivalent outside work. That contrast is the sharer's, and it compares a subscription price with a service price, so read it as a direction rather than an accounting result.

The evidence of life is daily use by the person who commissioned it. The material gives no duration, so by the four-week rule the claim is plausible but unverified. It also withholds the hours: the share mentions ten-plus-hour days at peak, awake and working. That is a real cost the subscription comparison hides.

What died

The outsourced ERP, one month after go-live. The recorded cause is the speed and quality of delivery.

Notice what that cause is not. The six-cause index used for deployment postmortems — the need did not hold, the wrong person was in the room, the workflow change cost more than it returned, the data was unstable, the only champion left, we did not keep up — has no slot for "the supplier was slow and wrong". The index was written for teams delivering their own work. An outsourced failure falls outside it, and the gap is the lesson: the taxonomy assumes you were close enough to watch the thing fail.

Acceptance you perform yourself

Five lines to put in the contract before work starts:

1. Who operates the acceptance run — a named person, not a role, not the vendor.
2. Which flow is run, from which starting record to which end state.
3. Which real data the run uses, and where it comes from.
4. What "done" looks like at the end state, in the customer's own unit.
5. What happens if the run fails — who reverts what, within how long.

If the answer to the first line is anyone other than the daily user, the acceptance is a rehearsal. The second attempt in this case worked because the person accepting it was the person who had to live in it. That is the cheapest form of metric definition available: the number is measured by whoever feels it.

Case details come from a public share and have not been independently verified.