
Dataprint
I spent nine months on a proposal automation product for architecture and engineering firms, set a purchase-intent threshold before the research started, and killed it when the evidence came in under the bar. The build was repurposed and is still earning.
Snapshot
- Role
- Product Lead & Developer
- Timeline
- May 2025 to February 2026
- Status
- Discontinued as a standalone product. Build repurposed as an internal pursuit tracker
- Scope
- Market research, product definition, build, and the decision to stop
- Stack
- Next.js, React, TypeScript, Node.js, Supabase
The Bet
Public agencies ask architecture and engineering firms to bid on work by submitting written proposals. That work is repetitive by design. Agencies ask the same categories of question, and firms answer them with material they already own: past projects, staff biographies, safety records, references.
The gap I saw sat between having that content and having it organized, searchable, and reusable. Firms were not missing information. They were missing any reliable way to find their own.
The bet was that a product which closed that gap would sell itself to the people doing the assembling.
Proposals are also high stakes and time boxed. A firm that misses a submission deadline does not get a second chance at that contract, so the work gets done no matter how painful it is. High pain with no option to skip it is usually a good sign for a product.
Where the Problem Came From
Firsthand. I wrote proposals professionally and watched the same work get rebuilt from scratch on every new one.
That origin is worth stating plainly, because it is the strongest thing about the early thesis and it also turned out to be the weakest. I knew the problem intimately, which made me confident, and confidence is what a threshold is supposed to protect you from.
Founders who have lived the problem tend to validate the pain and skip the purchase. I had already decided the problem was worth solving before I spoke to anyone, so the only useful question left was whether anyone would pay to have it solved.
Discovery
I interviewed 20 firms.
Before any of those interviews happened, I set a purchase-intent threshold of 30%. If fewer than 30% of firms showed intent to buy, I would not build the product.
Setting the bar in advance is the part that mattered. A threshold chosen after the data arrives is not a threshold, it is a justification written backwards. Committing to the number first meant the research was able to tell me no.
The 20 firms spanned both ends of the size range on purpose. Interviewing only the firms I already knew would have produced a flattering answer, because those were the ones whose problems I had watched up close and built the thesis around.
What I Found
The pain was real, and it was in the wrong place.
Small firms carried the heaviest manual burden. They had the least process, the fewest people, and the most rebuilding from scratch. They also had the least money and the least appetite for adding a subscription.
Large firms had already solved it. They ran synced, accessible systems, they had established process around them, and they were not looking to change either. The problem I was selling against had already been addressed internally.
So the need concentrated in the segment least able to pay for it, and the segment that could pay did not have the need. That is a structural problem with the market rather than a problem with the product, which means no amount of building fixes it.
I had assumed firm size would correlate with willingness to pay. It correlated with having already solved the problem instead, which inverted the thesis rather than adjusting it.
The Decision
Purchase intent came in under 20% against the 30% threshold I had set.
I killed it.
The evidence did not clear the bar, and the bar existed precisely so that I would not be able to argue with it later. I could have built it anyway. The research handed me plenty of material to justify that: real frustration, real wasted hours, firms describing the exact problem I had set out to solve, in their own words.
None of that is purchase intent. People will describe a problem in vivid detail and still not buy a solution to it, and the gap between those two things is where most failed products live.
Stopping after nine months is expensive in a way that is easy to underestimate, and most of the cost is not financial. The alternative was more expensive and the bill would have arrived later, after a build, a launch, and a year of trying to sell into a segment the research had already told me could not afford it.
What Happened to the Work
The build did not go to waste. I repurposed it as an internal tracker at PMG for the proposals the firm decides to pursue, where the same underlying problem existed inside an organization that already had the data and the people.
In that form it raised the number of solicitations pursued by 18% and moved win rate from 15% to 28%. It contributed an estimated $2 million to $3 million in 2025 revenue.
That revenue figure is a partial contribution and an estimate. The tracker is one input among several, and I have not isolated its effect from the other things that changed over the same period.
The lesson is narrower than it looks. The product was wrong for the market I aimed it at and right for the organization I already worked in. Those are two different findings, and only the second one came with a customer attached.
What I Would Do Differently
Test willingness to pay earlier and more directly. I measured pain first and planned to price later, which is the wrong order.
Pain is easy to find and cheap for people to talk about. A firm will walk you through a problem for an hour and still never reach for a card. I would put a real price in front of people in the first five interviews rather than the last five, and accept the more uncomfortable conversation in exchange for the earlier answer.