Most AEC firms try to build their own proposal tool at some point. A resume spreadsheet, a shared project database, an Airtable base, sometimes a small custom app. The build usually goes fine. What ends them is maintenance, because the people who would keep the tool current are the same people running pursuits, and unmaintained software decays.
I write software for a living. That is the seat I am writing this from, and it is why I think the standard build-versus-buy advice gets this wrong for firms your size.
Why Firms Build Their Own Proposal Tools in the First Place
The instinct is sound. You already have the information: your engineers' backgrounds, your project history, the boilerplate you keep reusing. It sits in finished PDFs and old submittals, and pulling it into one place looks like an afternoon of work and a permanent fix.
There is usually a trigger. A pursuit gets missed because nobody could find a resume, or a principal asks how many treatment plant projects the firm has done and nobody can answer. Someone capable volunteers, builds something over two weekends, and for about four months it genuinely works.
What Actually Breaks Is Maintenance, Not the Build
Building software is the cheap part. Peer-reviewed reviews of software cost put the maintenance phase at roughly 90 percent of a product's total lifetime cost, and the IEEE Computer Society's often-cited range is 60 to 80 percent. Whatever number you accept, the shape is the same: the initial build is a rounding error against keeping the thing alive.
For an internal proposal tool at a 40-person firm, maintenance is not glamorous work:
- Somebody adds every new hire and every completed project, forever
- Somebody notices when a PE license lapses or a scope was described wrong
- Somebody fixes it when the export breaks or a formula silently stops calculating
- Somebody keeps it running when the person who built it leaves
That last one is the killer. The tool was built by one person in the margins of their real job, and it exists in their head as much as in the file. When they change roles, what remains is a database nobody fully understands, so nobody trusts it, so people go back to searching old submittals. It did not fail loudly. It quietly stopped being true, and a database that is 70 percent current is worse than none, because you cannot tell which 70 percent.
Firms With Engineers on Staff Could Not Sustain It Either
If your half-finished tracker makes you feel behind, this should help.
A top-five general contractor, a firm with a real technology budget and software engineers on payroll, built its own pipeline and CRM system. They ran it for years, then abandoned it for a commercial platform, because the upkeep required dedicated people writing code indefinitely and keeping pace with operating system and device changes was not a business they wanted to be in.
If a firm with that much engineering capacity could not carry it, a 40-person civil firm where the marketing director maintains the database between submittals is not going to carry it either. The stalled spreadsheet is the normal outcome. It is not evidence your firm is disorganized.
Has AI Changed the Build-Versus-Buy Math?
Honestly, somewhat, and it would be dishonest to skip it. AI-assisted development has made the build phase dramatically faster. A 2026 survey of 817 builders found 35 percent had already replaced at least one commercial tool with something they built, and 78 percent planned to build more.
Two caveats. The sample is customers of an internal-tools platform, so it measures people who build software, not firms in general. And more telling, 26 percent of that same group named maintenance burden as the thing blocking them from automating further. Even among people whose job is building internal tools, upkeep is the constraint.
AI made building cheaper. It did not make maintaining cheaper, and maintenance was always the expensive part.
Should You Build or Buy a Proposal Tool?
| Factor | Build makes sense when | Buy makes sense when |
|---|---|---|
| The workflow | Genuinely specific to your firm, no vendor addresses it | Common across firms your size, which most proposal work is |
| Who maintains it | A named person whose job description includes it | Nobody has spare capacity to own it |
| What happens if it dies | Inconvenient | You lose the record of who your people are and what you have built |
| Output fidelity | Plain documents are fine | You need your own InDesign or Word layouts to survive intact |
| Time horizon | You need it for one specific push | You need it to be true in three years |
The honest read for most 20 to 200 person firms: the underlying need, keeping staff and project records current and reusable, is not specific to your firm at all. It is the same need at every firm doing SOQs and qualifications packages, and the same one behind resume version sprawl. Specificity lives in your templates and your judgment about which projects to feature, not in the plumbing.
This is the thing you were trying to build. RFPM.ai keeps staff and project records as structured data and generates the tailored versions each pursuit needs, including from your own InDesign templates. A person still decides which engineers and which projects belong in the package. What changes is that keeping it current is someone's product rather than someone's weekend.
What to Do With the Half-Finished Tracker You Already Have
Do not throw it out. It tells you what you actually needed, which is more reliable than any feature list: look at what you built first and what you kept using. It also holds cleaned data, because somebody already pulled project details out of old submittals and decided what mattered. That effort transfers to whatever comes next, along with any reusable qualifications content it accumulated, and the retrieval problem it was built to solve does not go away in either direction.
Then ask one question: who maintains this in two years? If there is no name, you have your answer, and it was never really about the software.
Frequently Asked Questions
Should a small AEC firm build its own proposal or resume database?
Usually not, but the deciding factor is maintenance rather than build cost. If no one at the firm has keeping it current in their job description, an internal tool will drift out of date within a year and stop being trusted. Firms with software engineers on staff have reached the same conclusion.
Why do internal proposal databases stop getting used?
They decay rather than break. New hires and completed projects stop being entered, details go stale, and once people find one thing wrong they stop trusting the whole database and go back to searching old submittals. The tool is usually still working. It is just no longer accurate.
Has AI made building internal tools worth it?
AI has made the build phase much faster, and more teams are building because of it. It has not reduced maintenance, which is where most of a tool's lifetime cost sits. In a 2026 survey of builders, maintenance burden was still named as a leading blocker to automating further.
What should we do with a spreadsheet or database we already built?
Keep the data and the requirements it revealed. The cleaned project and staff information transfers to whatever comes next, and what you built first tells you what your firm actually needed. Treat it as a specification you already paid for rather than a failure.