A Federal Architecture Firm Was Running a Complex Business on Tools Built for Someone Else's
MCFA Global operated at the intersection of federal compliance, multi-team project delivery, and competitive proposal writing. Their tools - a patchwork of generic CRMs, shared drives, and spreadsheets - had been adapted just enough to function, and not enough to actually fit. We built the system their business had always needed and never had.
MCFA Global
MCFA Global operates in the Architecture & Engineering sector with a specific focus on the federal market - a segment with its own vocabulary, compliance requirements, proposal formats, and procurement timelines. Federal AE work is not won by the firm with the best portfolio alone. It is won by the firm that can demonstrate relevant past performance, assemble the right subconsultant team, and produce a proposal that speaks the language of federal evaluation criteria consistently, at volume, under deadline.
The firm had the expertise and the track record. What they did not have was infrastructure that understood how their business actually worked. The CRM they had been using was built for sales pipelines. The proposal library lived in a shared drive nobody trusted. Subconsultant relationships were managed in someone's head and a spreadsheet that was always slightly wrong. The gap between what the firm knew and what the system could hold kept widening.
"Every proposal we write pulls from the same pool of past projects, the same subconsultants, the same boilerplate sections. We were rebuilding that from scratch every time because nothing was connected. We needed a system that remembered what we knew."
Every proposal was being built from scratch. In a business where the same material is used repeatedly, that is a solvable problem - if the infrastructure exists to solve it.
Federal AE proposal work is highly structured. The same project descriptions, the same subconsultant credentials, and the same boilerplate methodology sections appear across dozens of proposals - adapted for each opportunity, but fundamentally reusable. The operational problem at MCFA Global was not a lack of material. It was a lack of a system that made the material findable, trustworthy, and pull-able when deadlines were close.
Proposal sections were being rewritten instead of reused
The firm had produced hundreds of proposals. The methodology sections, past performance narratives, and sustainability language all existed somewhere. But somewhere meant a shared drive with inconsistent naming, duplicate versions, and no reliable way to know what was current. Writers defaulted to starting from scratch because finding and trusting existing material took longer than rewriting it.
Subconsultant management lived outside the system
Federal projects regularly require subconsultant teams. Tracking credentials, availability, and prior collaboration history required searching inboxes and memory instead of querying a structured record. Team assembly depended on who remembered what, not on reliable system data.
Federal project tracking had no single source of truth
A federal project lifecycle touches location data, cost information, profile codes, team assignments, subconsultants, graphics, and references. Managing that across spreadsheets and disconnected tabs with no access structure meant the project record was always behind project reality.
Opportunity pipelines had no structured path from interest to win
Opportunities were tracked informally. There was no workflow connecting identified solicitations to the tasks needed to convert them, limited stage visibility, and no systematic way to distinguish active pursuits from stalled ones.
The firm had adapted a general-purpose CRM to approximate the fields they needed while working around fields they did not. The result required heavy manual upkeep, did not match the structure of federal AE work, and was not trusted enough to become the source of truth. The shared drive and spreadsheets remained in parallel, leaving three systems and no definitive one.
The firm did not need a better CRM. They needed a system built around the federal AE business model.
Generic CRMs are shaped around a sales pipeline. Federal AE work is not. Projects run for years and span dozens of data types. Proposals depend on reusable, versioned content that must be trusted and instantly retrievable. Subconsultant relationships include compliance and credential dimensions traditional contact records are not designed to hold. Building from scratch was not a scope preference - it was the only architecture likely to produce a system the firm would actually use.
We learned the federal AE business before we designed a single screen.
Before design work began, we studied the federal proposal process in detail: evaluation criteria, past performance structure, subconsultant teaming dynamics, and documentation requirements. We interviewed proposal writers, project managers, business development stakeholders, and administrators. The system architecture came out of those conversations, not from a generic feature list.
One principle guided every module: reflect how MCFA Global actually works, not how a vendor imagines professional services should work. That meant a project record with the exact tabs federal project delivery needs, a boilerplate library tuned to real writer retrieval behavior, and a subconsultant module built for federal teaming realities. Specificity was the brief.
Role-based access was non-negotiable, with differentiated visibility across projects, contacts, proposals, and administrative functions.
Data accuracy and freshness had to be visible so the system could credibly replace spreadsheets.
Boilerplate retrieval had to happen in seconds, not minutes. Search and filter performance was a clinical requirement.
Every module was built around a specific operational need. Nothing generic made it into the system.
Project Management
Full lifecycle tracking across every dimension a federal AE project requires: Location, Dates & Costs, Profile Codes, Team assignments, Subconsultants, Graphics, Files, Additional Fields, Custom Fields, and References - all from one multi-tab form. A project record became the complete authoritative account, not a summary that linked out to other tools.
Boilerplate Library
Reusable proposal sections - Utility Coordination, Schedule Review, Sustainability Review, Cost Estimating, Firm Profile - became searchable and pull-able in seconds. Writers moved from hunting and rewriting to retrieving trusted current content directly inside the system.
Subconsultant & Contact Management
A structured, searchable directory of subconsultants and contacts with primary email, linked organizations, and cross-module relationship consistency. Teaming decisions moved from inbox memory to system queries.
Desired Outcomes & Opportunities
A Kanban workflow tied to each opportunity made conversion work visible and executable. Tasks moved through Someday -> To Do -> Working On -> Completed with assignees, status, and timestamps tracked in-system.
Role-Based Administration
Users, Roles, and Unconfirmed Users were managed with granular controls. Team members saw exactly what their role required - no accidental exposure of confidential project data and no undifferentiated all-access model.
Built for the firm that would use it daily - not for the demo that would sell it.
The build process was organized around real user groups: proposal writers, project managers, business development staff, and administrators. We ran review sessions at feature completion rather than waiting for project completion. Changes from those sessions were treated as discovery, not scope creep. The deliverable was workflow fit, not just spec compliance.
Designing a project record that served multiple disciplines simultaneously
A project means different things to different roles. We had to balance budget and timeline concerns, proposal narrative needs, and business development reference workflows without making the record unwieldy. The final 14-tab structure came after iterative validation with each user group.
Making the boilerplate library trusted enough to actually use
A content library only works if users trust currency and correctness. We introduced clear ownership, visible update state, and retrieval performance that was measurably faster than rewriting. Adoption followed because trust conditions were designed before content migration.
Role-based access that reflected real organizational structure
Access in professional services is not binary. We mapped real user types to real permissions through multiple rounds before configuration. The Unconfirmed Users queue emerged from this work and became an important operational safeguard.
One system. Every piece of the business in it. None of it in a spreadsheet.
Three disconnected systems were replaced by one trusted operating layer.
Each tab reflected a real operational need rather than placeholder complexity.
Retrieval replaced minutes of searching or full rewrites.
No undifferentiated visibility and lower confidential data exposure risk.
The most visible shift was the disappearance of the question 'where is the current version of that?' across proposal cycles. Writers retrieved trusted content, project managers updated records directly, and business development tracked opportunities inside the same source of truth.
Subconsultant module adoption changed team assembly from memory-dependent to query-driven. Knowledge that previously lived with individuals became durable organizational infrastructure.
The Desired Outcomes board shifted leadership visibility from informal updates to structured, current pipeline state with clear signals on active work, stalled items, and upcoming priorities.
Design for trust and the system compounds
A system people do not trust does not get used
Trust is a design requirement. Clear data ownership, visible recency, fast retrieval, and a structure that mirrors the business model are not extras. They are the conditions that make adoption possible.
Institutional knowledge is the most valuable and most fragile asset
Boilerplate, subconsultant relationships, and past-performance records represented years of expertise. Before the build, much of that knowledge was trapped in memory or buried in files. In a trusted system, that knowledge compounds instead of disappearing.
Bespoke does not mean complex. It means exactly right
Building around the firm's real data model made the product easier to learn and easier to trust than a heavily adapted generic CRM. Specificity reduced cognitive load because fields and workflows matched reality.
Running a specialized business on tools built for someone else's?
We build systems around the way your business actually operates, not around assumptions baked into off-the-shelf software. If the gap between what your tools can hold and what your business needs to track is widening, the right time to fix it is now.