Work / W-02
An export-license portal built inside a defense contractor's government cloud
Replacing a failing Access database with a need-to-know compliance portal that runs entirely inside the client's own GCC High and Azure Government environment.
- Client
- A large defense contractor managing export licenses under federal law
- Sector
- Defense
- My role
- Forward deployed engineer: scoped requirements with the client and co-built the portal with one partner engineer
- Period
- Jul 2026–present
- Status
- Built · awaiting client approval
- Stack
- React · SQL · Microsoft Entra ID (GCC High) · Azure Government
- Result
- Delivered inside the client's government cloud, now in client review
The problem
The company makes components that can’t be exported without federal licenses. Hundreds of those licenses are active at any time, and a dozen departments need to know, for each of thousands of components, what’s permitted, what’s pending and what has to happen before a deadline.
All of that lived in an aging Microsoft Access database. Nobody at the company could update or maintain it any more, and the friction showed up across the organization: every department depended on a system of record that no one could change.
Off-the-shelf compliance software wasn’t an option. The company’s ERP is customized so heavily that packaged modules can’t plug into it.
What it was costing them: a process where mistakes carry federal consequences, running on a tool no one could fix. Every change to how licenses were handled had to work around the database instead of through it.
How I scoped it
I sat with the compliance department. I’m the forward deployed engineer on a two-person team, so I owned the client side: working through requirements with the compliance team and turning them into a plan we could build against.
I started with the Access database itself. Together with compliance, we went through the database to map what it actually did, what each department relied on it for, and where the workarounds were. That walkthrough became the requirements, not a feature wish list.
I made decisions around the client’s constraints:
- Build inside what they already have. The company already runs a Microsoft GCC High environment. Building on it meant no new vendor cloud to approve, sign-in through accounts that are already vetted, and data that never leaves the client’s own Azure Government tenant.
- Compliance owns access, not engineering. Who can see what is decided by the compliance department on a need-to-know basis. The portal enforces those rules; it doesn’t invent them.
- Stand alone rather than fight the ERP. Given how customized the ERP is, a separate portal was more reliable than trying to bolt a module onto it.
I deferred the next requirements on purpose. Controlled unclassified information (CUI) handling and EU export licensing are real needs, but they were scoped as later modules so the core license workflow could ship first.
What I built
With one partner engineer, I built a compliance portal that:
- Admits only authorized, licensed users, through Microsoft Entra ID in the company’s GCC High environment.
- Separates information on a need-to-know basis, using rules set and maintained by the compliance department.
- Stores everything inside the client’s Azure Government environment, so no data leaves their compliance boundary.
- Gives every relevant department clear reporting on permitting timelines and business requirements for each of the thousands of components the company produces.
- Is built to grow, with room for the planned CUI and EU export-licensing modules without a rebuild.
- People
- Compliance departmentOwns the access rules
- A dozen departmentsSee the timelines and requirements they need
Sign-in - Identity & access
- Microsoft Entra ID (GCC High)Only authorized, licensed users
- Need-to-know rulesSet by compliance, enforced per record
Filtered access - Portal
- Export-license trackingLicenses, timelines, requirements per component
- Department reportingWho needs to act, and by when
- Planned modulesCUI · EU export licensing
Stored in - Data
- Client's Azure Government tenantNo data leaves the client's boundary
Result
- Built and delivered; awaiting the client’s approval to launch
- Replaces an Access database that no one at the company could maintain
- Runs entirely inside the client’s existing GCC High and Azure Government environment, with no new vendor cloud
- Access rules owned by the compliance department, not hard-coded by engineering
- Ready for CUI and EU export-licensing modules
Lessons
Test the constraint before you design around it. At the start, we believed the only compliant way to store this data was to build a Microsoft application inside GCC High itself, which would have boxed us into that platform’s tools. Then we confirmed two things: a web app hosted on Azure Government met the same requirements, and the client already had an Azure Government account. You can’t just sign up for one of those the way you can a regular Azure account. Those two facts opened up a standard web stack, and we started moving much faster. I now ask early what the client already has approved and what the rules actually require, rather than what everyone assumes they require.