Technical Architecture
Marketing Central is built on Liberty's existing Azure infrastructure, using a modern Next.js stack with TypeScript. The architecture prioritizes security, performance during tax-season peak loads, and long-term maintainability — with all code living in Liberty's environment from day one.
Stack Overview
The technology choices reflect both the requirements of the platform and the existing Liberty infrastructure. We're not introducing new cloud platforms, new identity providers, or new database vendors. We're building on top of what Liberty already has, using the framework best suited to this type of application.
Server-side rendering, API routes, TypeScript-first
End-to-end type safety across client and server
Component-based UI with server + client components
Liberty's existing cloud environment — no new vendor
Relational app data — users, funds, orders, claims
Marketing assets, product images, PDF templates, receipts
Existing Liberty enterprise identity — no new setup
B2B/B2C extension of Entra for external users
Performance monitoring, error tracking, usage analytics
Next.js App Router was chosen for its native support for server-side rendering (critical for SEO and first-load performance), seamless TypeScript integration, built-in API routing (allowing the front end and back end to live in one codebase), and strong alignment with the React component model the team already works in.
The key architectural principle is that the front end and back end are one application — not separate services that call each other over a network boundary. This simplifies deployment, reduces latency for API calls, and means there is one codebase to secure, monitor, and update.
Architecture Layers
Every request through Marketing Central flows through a consistent set of layers. Understanding these layers is important for understanding where security is enforced, where data lives, and how integrations fit into the picture.
User Layer
The browser or mobile browser running the Next.js React application. Server-rendered HTML is delivered on first load for performance; subsequent interactions are client-side React. The UI is fully responsive and WCAG 2.1 AA accessible for all franchise-facing screens.
Authentication Layer (Entra)
All requests pass through Microsoft Entra ID authentication before reaching the application layer. Corporate users authenticate via Entra ID. Franchisees and vendors authenticate via Entra External ID. JWT tokens carry role claims. Token validation happens server-side on every API request — not just at login.
Application Layer (Next.js)
The Next.js application handles both UI rendering (React Server Components + Client Components) and API logic (Next.js API routes / Route Handlers). Business logic — including RBAC enforcement, fund balance calculations, and integration orchestration — lives in the server-side code, never in the client. The client receives only what it is permitted to display.
Data Layer (Azure)
Azure SQL hosts all relational application data: user accounts (supplementing Entra), fund ledgers, order records, claim records, audit logs. Azure Blob Storage holds binary assets: uploaded marketing materials, PDF templates, product images, receipt uploads, and generated customized PDFs. The two stores are accessed exclusively from the server-side application layer — clients never access Azure directly.
Integration Layer
Outbound integrations to the Admin System (org data sync), Dynamics GP (claims routing, payment confirmation), FranConnect (supplemental org data), payment processor (checkout), vendor APIs (order telemetry), and carrier APIs (shipping rates) are all managed server-side. No integration credentials are exposed to the client layer.
Hosting & Infrastructure
Azure App Service / Container Apps
The Next.js application is deployed to Azure App Service or Azure Container Apps (determined during infrastructure design phase) with auto-scaling configured to handle tax-season peak loads. The platform is designed for elastic scaling — horizontal scale-out during the November–March peak, scale-in during the off-season to manage infrastructure costs.
Three Environment Strategy
Development (continuous deployment from the dev branch), QA (stable deployment for testing and stakeholder review), and Production (deployment-gated by QA sign-off). All three environments are isolated with separate databases and blob storage. Integration credentials for Dev and QA point to sandbox/test endpoints for all external systems where available.
Development Approach
AI-Assisted Development (30% Efficiency Gain)
AI tooling is integrated into every stage of the development workflow: code generation and review, test writing, documentation, and integration scaffolding. The 30% efficiency gain reflected in the estimate (–367 hours from ~1,676 gross) is a real, measurable productivity improvement — not a margin adjustment. The savings are verifiable in the delta between gross and net estimates.
CI/CD Pipeline
GitHub Actions (or Azure DevOps, per Liberty's preference) powers the continuous integration and deployment pipeline. Every pull request triggers automated tests. Approved merges to the main branch deploy automatically to the Development environment. QA and Production deployments are manually triggered with required sign-off.
Infrastructure as Code
Azure infrastructure is provisioned and managed via infrastructure-as-code (Bicep or Terraform). This means the infrastructure configuration is version-controlled alongside the application code, environment creation is repeatable and auditable, and there are no undocumented manual Azure configuration steps.
Code in Liberty's Repository
From the first commit, all code lives in a repository under Liberty's GitHub or Azure DevOps organization. Liberty has full access to the codebase at all times — there is no vendor-controlled repository that Liberty needs to be "handed off" from at the end of the project. The handoff is a process event, not a code transfer event.
Environments: Dev, QA / Sandbox, Production
The platform ships with three fully isolated environments, each serving a distinct purpose in the path from change to production.
Development
The active build environment, continuously deployed from the development branch. This is where new features land first and where the engineering team validates work in isolation before it is promoted.
QA / Sandbox / Staging
A staging environment that mirrors production and points at the test endpoints for every external system — Admin System, Dynamics GP, FranConnect, vendor APIs, carrier APIs, and the payment processor. This is the environment Liberty uses to test integrations and validate changes against realistic, production-like conditions without touching live data or live systems.
Production
The live environment serving franchisees, vendors, and Liberty's corporate users. Promotion to production is gated on QA sign-off — nothing reaches production that has not first been validated in the sandbox.
Liberty can use the sandbox / staging environment to test integrations and validate changes before they ever reach production. This directly satisfies the RFP's requirement that "a sandbox staging area is required" and the "ability to test integrations before production" — staging is a standing, production-mirroring environment, not an ad-hoc setup spun up on request.
Open APIs & Mobile-Ready Delivery
Open APIs / Data Feeds
Marketing Central exposes its own APIs and data feeds so Liberty can consume platform data in other internal applications and reuse it where it adds value — reporting tools, internal dashboards, or downstream systems. The platform is an asset in Liberty's broader ecosystem, not a silo whose data is only reachable through its own UI.
Mobile-First, Fully Responsive
The franchise-facing experience is mobile-first and fully responsive. Franchisees can browse the catalog, customize assets in the Design Builder, and place orders directly from phones and tablets — not just desktops. This satisfies the RFP's mobile-friendly requirement as a core design constraint rather than a retrofit.
Data Storage Approach
Application and transactional data — users, fund ledgers, orders, and claims — lives in relational Azure SQL. Assets, PDFs, and uploaded receipts live in Azure Blob Storage. Each store is used for what it is best at, and both sit within Liberty's own Azure tenant.