A working prototype for construction licensing modernization

When agencies replace legacy licensing and enforcement software, the hardest part is usually not the screen redesign. It is untangling years of manual workarounds, disconnected records, policy-driven exceptions, and reporting demands into a system staff can actually operate. For our Oregon Construction Contractors Board bid work, we chose to prove that we understood that problem by building a working prototype instead of relying on slides and diagrams alone.

The result was CORE, a browser-based regulatory operations platform prototype designed for contractor licensing modernization. It covered licensing, renewals, complaints, investigations, enforcement, payments, correspondence, documents, search, and reporting. More importantly, it was designed so an agency could adapt rules, queues, templates, and workflows without treating every policy change as a custom development project.

Why we built a real system for a bid

Public agencies are asked to make long-horizon platform decisions with real operational and political risk. For that kind of procurement, polished language is not enough. We wanted to demonstrate how a modern licensing and enforcement platform could feel in practice: how staff navigation works, how queues are organized, how complaints connect to cases, how documents move through the system, and how audit history is captured around sensitive actions.

The design problem most agencies actually have

Construction licensing programs tend to accumulate complexity in predictable places:

• Different rules for applications, renewals, endorsements, and reinstatements.
• Complaint intake that needs to connect cleanly to enforcement workflows.
• Heavy dependence on letters, notices, evidence, and document retention.
• Financial workflows that must integrate with payment and accounting boundaries.
• Operational reporting that spans multiple record types, teams, and policy timelines.

Legacy systems often encode those requirements as brittle one-off customizations. That makes policy change slow, expensive, and risky. Our approach was to model those patterns as configurable platform behavior wherever possible.

Configuration first, not customization first

The strongest idea in the prototype was not a specific screen. It was the operating model behind the screens. Workflow rules, queue assignments, communication templates, and reporting views were designed to be adjusted by administrators instead of buried in code. That matters for agencies because statutes, board policy, forms, service targets, and staffing structures all change faster than a vendor-heavy release cycle can usually keep up with.

Architecture choices that reduce long-term risk

We structured the prototype as a Rails 8 modular monolith with bounded contexts aligned to agency operations, including identity, parties, licensing, complaints, enforcement, finance, correspondence, documents, workflow, and reporting. That gave us a cleaner separation of concerns than a single tangled app without introducing the operational cost of a prematurely fragmented microservice estate.

For the user experience, we used Hotwire and server-driven UI patterns because they fit workflow-heavy administrative systems well. That keeps the frontend stack simpler, improves accessibility discipline, and still supports responsive interactions for queues, forms, and detail views.

On the platform side, we mapped the system to Azure services appropriate for a government-oriented SaaS deployment, including App Service, PostgreSQL, Blob Storage, Key Vault, Service Bus, Monitor, and Defender. Workforce identity used Microsoft Entra ID for SSO and MFA, while application-level authorization remained inside the platform boundary. We also planned external integrations behind adapters so domain logic stays insulated from agency-specific protocols and partner systems.

What public agencies should take from this

Even though this prototype was shaped around the Oregon Construction Contractors Board procurement, the underlying needs are common across licensing boards, inspection programs, and enforcement-oriented agencies. If you are planning a rebuild, the practical questions are usually the same:

• Can staff and public users work in one coherent platform instead of disconnected systems?
• Can workflows, notices, and queues change without reopening core code every time?
• Can the system produce the audit trails, searchability, and reporting depth regulators need?
• Can identity, access control, and document handling hold up to public-sector scrutiny?

That is the standard we were designing toward. The bid prototype was a concrete demonstration of how a modern construction licensing and enforcement platform can be built to support change, not just automate the status quo.