Dataprint

Public agencies ask construction and engineering firms to submit proposals, and those proposals repeat a lot. The same firm answers the same kinds of questions over and over, and it already owns almost everything a proposal needs. The problem is not a lack of content. The problem is that the content is hard to organize, search, and reuse.

A medium-sized proposal takes 80 to 200 hours to put together, and most of that is not writing. It is looking for the right project sheet, the current version of a resume, or the last answer to a similar question, and then reformatting all of it. Dataprint is built on the idea that this reuse problem is large enough to be its own product.

I did not find this problem in a report. I found it by doing the work. As proposal manager at PMG, I put these submissions together myself and watched the hours go into searching for files and reformatting them. Because the problem comes from direct experience, I can describe it in detail.

I defined the target customer before designing the product. The target is Texas construction and engineering firms with about 5 to 30 million dollars in revenue, submitting 15 to 25 or more public proposals a year. At those firms, the marketing coordinator usually pushes for a tool, and a principal usually approves the purchase.

I wrote a 20-question interview guide organized into seven sections. Each section tests a specific assumption, labeled A1 through A7, so an interview could prove an assumption wrong instead of just collecting praise. I set the bar for success ahead of time: at least 30 percent of firms would need to be actively frustrated and already looking for a better option.

Out of 20 firms, 50 percent showed that level of frustration, well above the 30 percent bar. The main idea held up.

These numbers come from my own interviews and are not yet recorded in a formal scorecard, so I treat them as a strong signal rather than a final result. I am not publishing a total market size, because I do not have a reliable source for one, and an invented number would weaken everything else here.

The research confirmed the problem but moved where it lives. I had assumed that helping several firms work together, assumption A6, was the key opening. The firms did not ask for that. They asked for better organization, digital asset management, and a simpler process inside their own company.

So A6 was dropped. Working across organizations moved far down the plan to Phase 11, and the effort went to building a strong single-firm content library instead. The plan changed because the interviews pointed that way, not because I preferred it.

There are three levels of competition, and the most important one is not software. The real competitor is the current habit of using Word, Excel, SharePoint, and shared folders. That is what firms use now, and it is the direct cause of the disorganization they complained about.

The next level is specialized tools that firms have tried and often stopped using. About 65 percent of the firms I spoke with had tried some tool, which tells me the interest is there but the tools did not keep them. Further out is general proposal-automation software, which is related but not built for public construction and engineering work, so it does not fit well.

Dataprint's focus is a single system that covers the full process, from the initial request to the final submission, and is built specifically for public construction and engineering proposals. It includes real asset management underneath, and it is shaped around the coordinator's day-to-day production work rather than a manager's sales tracking. It keeps a person in control of decisions, because the firm is responsible for meeting the requirements and will not hand that off to a system it cannot check.

The plan names are set: Solo, Team, and Firm. The pricing model and the exact prices are still open, and I would rather explain my thinking than present a number I cannot defend yet.

The plans are based on the size and shape of a firm's marketing team, because that predicts how the firm will use the product better than a random list of features. There is a real trade-off. Charging per user discourages the teamwork the product is meant to support. Charging per proposal matches the value but is hard to predict month to month. Charging a flat rate per firm is the easiest to sell. For now, I am treating the exact prices as still needing to be tested.

The first version centers on the RFQ Analyzer, and keeping a person in control is a stated design rule, not an afterthought. The system suggests, and the coordinator decides.

The clearest example of what I left out is SF330. The full vision starts with it, but the first version leaves it out, because it carries the highest risk of a compliance mistake and is not where I want to make an early error. InDesign export is also left out, for the opposite reason: it is the hardest to build and adds the least value for the effort. There is also a permanent list of things that will never be in scope, which keeps later excitement from quietly growing the first version.

The plan has a trade-off I have not fully solved. Asset management sits at Phase 9, even though it was the most clearly needed feature in all of the research. Placing it that late is a reasonable choice based on what has to be built first, but it is a tension worth stating plainly rather than hiding behind a clean-looking roadmap.

Four questions are still open, and they decide how far this can go. Who actually signs the purchase, the coordinator or the principal. Which pricing model works with real buyers. How small a firm can be before the product stops being worth it. And the biggest one, about AI: when the system makes a suggestion the user is responsible for, do users want an explanation, a ranked list, or the ability to override it.