Rebuilding the Account Portal a Whole Customer Base Logs Into
A continuous engineering partnership for a higher-ed data & transcript-services platform
Dev, QA, and prod are isolated AWS accounts, not folders — nothing reaches production without passing through QA first.
The entire stack — API, functions, databases, auth — is defined in code, so every environment is reproducible and every change is reviewable.
Still the same engineering team, still shipping on the same pipeline, more than a year into the relationship.
A standing disaster-recovery region with automated backups and a rehearsed, scripted failover — not a plan on a wiki page.
Starting point: a portal outgrowing its architecture
The portal handles account identity for our client's institutional customers, but the source of truth for those accounts lives in a separate CRM. Reconciling the two, while a support desk, a community forum, and a directory search all had to agree with each other, is where the engineering effort concentrated.
What changed
The whole stack now scales on demand and provisions itself from code instead of manual setup.
The customer-facing app runs on a current framework with an environment pipeline where what QA tests is exactly what ships.
Ongoing audits of authentication, session handling, and access control, with issues closed as they're found rather than left for later.
Login and session logic, once scattered across the app, now lives in a single place — fewer edge cases, easier to reason about, easier to extend.
Redesigning signup so staff, not the form, decide who gets an account
The original flow wrote to the CRM the moment someone signed up, before anyone had confirmed they belonged where they claimed. We redesigned the process end to end — a lightweight signup, a staff review step with the tools to verify and correct details, and a single, deliberate point where an account is approved and the CRM is updated. The result is fewer duplicate records, a real checkpoint before access is granted, and a workflow staff actually trust.
What shipped
A sample of the ground covered over the engagement.
Account and contact data stays consistent between the portal and the CRM automatically, with the edge cases — duplicates, partial matches, legacy records — handled instead of ignored.
Institution and people search was redesigned around how staff actually look things up, with faster results and a cleaner, more informative result view.
One login now carries a customer into the community forum as well, with access there reflecting what that institution has actually licensed.
A standing DR region, automated backups, and a documented failover procedure a new engineer could run — not something discovered for the first time during an outage.
Help-desk content and the app now link cleanly for logged-in and logged-out visitors alike — small friction removed from a high-traffic path.
Still their team
This isn't a project we delivered and left. Our client has kept us on the portal continuously for over a year — through the platform rebuild, the SSO integration, the search redesign, and now the signup overhaul — shipping through the same dev, QA, and prod pipeline every week.
“The signup flow, CRM sync, and disaster-recovery posture were three separate problems when we started. A year in, they behave like one system — and the client keeps handing us the next one.”
Capabilities: cloud architecture · identity & access · CRM integration · search · disaster recovery. Recurring engagement · 2025–present.