In November 2025, Tristan Sigerson sat between two ways of running the same business. He operated a small cold-email agency — the trade of sending strangers messages they did not ask for — and that business has only one raw material: contact data, the names, titles, and working email addresses of people who might buy. For years he had acquired that data the way his whole trade does, by renting it: paying roughly ten cents a contact for lists that began going out of date the day they arrived, and paying again the next month to replace what had decayed. The question in front of him was whether to keep paying that rent, or to stop buying the data and build a system that produced and maintained its own. He was not a trained engineer. He had, scattered across his machine, several working pieces of such a system — and no system. Whether to assemble them, and whether assembling them was even the right use of the next year, is the decision this case presents.
Background: A Business That Runs on a Spoiling Input
Sigerson’s agency sends outbound email on behalf of clients. Its results depend entirely on the quality of the list it sends to: a name that has moved companies, a title that is wrong, an address that no longer resolves, are all wasted sends. Business-contact data decays at an estimated two to three percent a month as people change jobs and companies fold; by the standard industry figure, a third of any list is wrong within a year. The vendors who sell the data know it spoils, and rent it anyway. For a sender, the cost is structural and recurring: the list is never finished, and the bill never stops.
By November he had accumulated a great deal of data without it adding up to an asset. In his own description of the starting state, he had “a folder with approx 5k csv files with company, prospect, email information” — the residue of years of buying — “but it is messy, the column names are different.” The records lived in a SQL Server database built for analysis, not for production use, and the cloud bill underneath it was climbing; the free credits had run out. The ambition was not small: he framed the universe he wanted to maintain as “12 mill, or 16 mill, accounts, and 38 mill prospects” — a body of data the size of a commercial product.
The founding intent is stated plainly in the record, in the first week of the project: “i run a cold email agency, and im building a data pipeline / data warehouse.” What the record does not yet contain, at that point, is any evidence the thing could be built by one person.
The Pieces Already on the Bench
The decision was not whether to build a data company from nothing. Sigerson had already built parts of one, piecemeal, to serve the agency — each solving a single step, each running on its own. He had a routine that took a company name and found its real web domain; one that found a likely decision-maker inside the company; an email finder (a third-party service, LeadMagic) to locate and check an address; and an “industry enricher,” a prompt that classified a company from search results. These were real and they worked in isolation.
What he did not have was a system. The pieces did not hand off to one another; there was no reliable way to take a raw company name and move it through every step to a finished, sendable record without a human shepherding it. The store was the wrong shape. There was no defense against the same company entering three times under three spellings. And the parts that did run could not yet be trusted to report honestly whether they had succeeded. The gap between “pieces that work” and “a pipeline that runs” is the substance of the build decision, and Exhibit 2 lays it out.
| Dimension | Keep buying (rent lists) | Build (assemble an owned pipeline) |
|---|---|---|
| Unit cost | ~$0.10 per contact, known and predictable | Mostly compute once built; unknown and unproven at his scale |
| Cost timing | Recurring — due again every month as data decays | Large effort up front; lower marginal cost later, if it works |
| Freshness | Static list, decaying 2–3% a month after purchase | Re-verifiable on demand — in principle |
| Coverage control | Limited to the vendor’s universe and filters | Steerable to any niche he chooses to source |
| Up-front effort | None — buy and send | Open-ended; no schedule, no guarantee of completion |
| Who maintains it | The vendor | Him — one operator, no formal training |
| Principal risk | Paying rent forever on an asset you never own | Spending a year and arriving with nothing sellable |
What “Build” Would Require
Assembling the pieces into a system meant building the connective tissue that did not yet exist, and a reader can see most of it from the fork. It meant an orchestration layer so that each step claimed a record, did its work, and passed it on without losing it or doing it twice. It meant moving off the analytical SQL Server store onto something built for live transactions. It meant solving identity, so a company could not masquerade as three. It meant a way to source raw records he controlled, rather than renting them, if the owned model was to mean anything. And it meant monitoring, so the system would say when it had failed instead of reporting success over dead work.
None of that was exotic for a trained data-engineering team. The complication was that Sigerson was not one, and would be learning each layer as he hit it, at night, around the agency that paid the bills. His own first instinct on looking at the tangle was to cut it down — “simplify down to just accounts, contacts… remove all the other tables” — which is the instinct of someone who senses the assembly will be hard and wants fewer moving parts to fight. A reader should not assume the layers above can be built in any fixed amount of time; the case takes no position on how long they would take, because at the fork neither did he.
| Already built, working in isolation | Still missing to make it one system |
|---|---|
| Domain finder (company name → real web domain) | Orchestration: reliable hand-off between steps, no lost or double work |
| Decision-maker finder | A production data store (transactional, not analytical) |
| Email finder & verification (LeadMagic) | Identity resolution: one company, not three spellings |
| Industry enricher (LLM classification from search) | Owned sourcing: raw records he controls, not rented |
| ~5,000 CSV files of previously bought data | Monitoring & quality: the system reports its own failures |
| An analytical SQL Server store (wrong shape, climbing bill) | A reason to believe one untrained operator can do all of the above |
The New Variable
What made the question live in late 2025, rather than obviously settled in favor of renting, was a change in tooling. Sigerson did not write production code by hand; he worked through AI coding assistants, describing what he wanted and correcting what came back. The wager underneath the build option was that these tools had lowered the cost of assembling and maintaining software far enough that a single non-engineer could now own infrastructure that had previously required a team — the same wager, at a firm level, that much of the software industry was making at the time. Whether that was true in practice, or whether the tools mainly lowered the cost of discovering that he should have kept renting, is exactly what the case leaves open. It is the variable a reader has to weigh and cannot look up.
The Decision
So the choice, in November 2025: keep buying contact data at about ten cents a contact — cheap per unit, certain, and never-ending — or commit an unknown quantity of the year ahead to wiring his scattered pieces into a system that made and maintained its own data, with no guarantee it would ever produce a sellable record. He has the parts and the intent; he does not have an engineering background, a schedule, or proof that the owned economics beat the rented ones at his scale. What should he do, and what would have to be true for “build” to be the right call?
Questions for Discussion
- At ~$0.10 a contact with no up-front cost, renting is cheap and certain. Under what conditions does owning the pipeline beat renting it — and can you state them in numbers (volume, refresh frequency, hold period) rather than in conviction?
- How should Sigerson value an unproven, self-maintaining asset against a known recurring cost? What discount for execution risk is reasonable when the builder has no formal engineering training and no schedule?
- Does cheap, AI-assisted software change the make-or-buy calculus for a one-person firm — or does it mainly lower the cost of finding out you should have bought? What in the case bears on the difference?
- He already owns the pieces but not the system. Is “assemble what you have” a materially different decision from “build from scratch,” and how should it change his risk assessment — if at all?
- What is the kill criterion? Before committing, what should Sigerson decide in advance would tell him to stop and go back to renting — and would he be able to see it in time?
Teaching note. This case supports discussions of make-versus-buy and vertical integration; cost structure in data-dependent businesses; and whether falling software-build costs change the make-or-buy calculus for very small firms. It is a decision case: the outcome is deliberately withheld, so that readers reach their own recommendation before learning what happened. What Sigerson decided, and the nine months that followed, are told in the companion tellings.
New Frontier Business Review cases are prepared as the basis for discussion rather than
to illustrate effective or ineffective handling of a situation. This case was reconstructed from the
operator’s own message logs across four AI tools; all quotations are verbatim from those transcripts.
Figures are the operator’s own estimates, not audited financials. The decision’s outcome is
presented in the companion tellings, not here.
© 2026 New Frontier Business Review. Primary-source record, November 2025–June 2026.