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.
Challenge
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.
Solution
Every module was built around a specific operational need. Nothing generic made it into the system.
Result
1
Source of truth for projects, contacts, and proposals
Timeline
Phased delivery
Planned delivery cadence
Team
Not specified
Cross-functional delivery
Evidence
Client-approved
Project and post-launch operating period
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.
Client Operating Profile
Scope, visibility, delivery context, and trust signals
“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.”
Client
Client
MCFA Global
Reach
Not specified
Evidence
client approved
Client operating details, platform surface area, and validation signals that shaped the work.
MCFA Global
Public identity approved
Not specified
Not specified
Not specified
client approved
Project and post-launch operating period
Metrics are shown as client-reported or operating-period outcomes; confidential identifiers are removed where required.
MCFA Global
Architecture & Engineering - Federal Market
Django - PostgreSQL - React - REST API - Role-Based Auth
Bespoke Enterprise CRM - Custom Build
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.
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.
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.
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.
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.
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.
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.
How we engineered the outcome. Select a module below to view the functional architecture.
Wide browser-frame visual with 14-tab bar including Project, Location, Dates and Costs, Additional Cost Data, Profile Codes, Teams, Descriptions, Subconsultants, Graphics, Files, Additional Fields, Custom Fields, and References.
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.
Operational Log
Diagnostic Log
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.
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.
Valuable lessons and strategic insights uncovered through this project that inform our future work and architectural decisions.
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.
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.
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.
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.