Higher Education & Research
One codebase for the public site and the platform behind it
A public-facing site and an internal student-tracking platform, built years apart on stacks nobody still owned. We consolidated them into one application with one design system and one authorization model, and shipped it without a production regression.
- Client
- A university cybersecurity center and its program stafftxcr.tamu.edu (opens in a new tab)
- Duration
- 20 months, four phases
- Team
- 5 engineers, embedded customer
- Year
- 2023–2025
The situation
What we walked into.
Two systems, built years apart, neither owned by anyone still on the team. They had drifted apart in the way that always happens when the same facts are maintained in two places, and routine content edits were arriving as interrupts to engineers rather than as work the program staff could do themselves.
The public site was failing at its actual job, which was explaining what the center did to the people it wanted to reach. The internal platform tracked students, projects and credentials, and a meaningful subset of that was personally identifiable student information.
The deployment target was university infrastructure with restricted egress, so every dependency had to be self-hostable and reproducible from CI rather than reachable as a managed service.
The team was five engineers working part-time around full course loads, with the center’s director and program staff reviewing weekly. That combination punishes any plan that needs a heroic month.
Approach
How we sequenced it.
Each step had to be independently valuable. That constraint is what let the client stop at any point without being stranded.
- Step 01
Fix the scope before writing code
Two requirements sessions produced a one-page scope document that fixed three things: the user roles, the data domains, and the in-scope use cases for each. Anything that did not map to one of those cells was explicitly out of scope and tracked in a parking lot. That document is what kept “just one more thing” from eating the schedule.
- Step 02
Foundations before features
The first phase shipped no user-visible functionality at all: repository, CI, design system, authentication skeleton and role primitives. Every later change landed on rails that already worked, which is the cheapest time to get them right and the only time anyone will agree to spend on it.
- Step 03
Authorization at the server boundary, not the interface
Three roles with explicit permissions on every mutation, enforced at the route handler rather than in the components. The interface hides what a user cannot do; the server refuses it regardless of what the interface shows. Anything touching authentication or personal data shipped integration tests against a real database in CI.
- Step 04
Harden, then hand over
A penetration test, a performance pass, audit logging and handover documentation, with each phase closing on an exit criterion the customer signed off. The rotation of who shipped the riskiest change each week meant no single engineer became the only person who understood a subsystem.
What was built
The parts that mattered.
- One application serving a static public surface and a gated platform, sharing a design system and a data layer
- Role-based access enforced at the route handler on every mutation, independent of interface state
- Test-driven development as the default workflow, reaching 600+ unit and integration tests
- Required-checks pipeline: typecheck, unit, integration and a preview deployment on every change
- A data-exposure incident on a legacy route found, closed, credential-rotated and written up within 24 hours
- Follow-on penetration test led in-house, with a remediation plan the center adopted
Results
What changed, and how we know.
3 of the 4 below are measurements, each against a stated baseline. The rest are states of the delivered system rather than numbers, and are written as such rather than dressed up as figures.
- Production regressions
- 0
- Tests at handover
- 600+
- Incident to written post-mortem
- 24 hrs
- Under staff who did not build it
- Still running
“Closed by default at the route layer is the only design that survives a moment of inattention.”
Built with
Services involved
More work
Related engagements.
- 2024About four weeks
The scanner read every barcode except theirs
They had no way to say who was holding what, and a barcode scanner that would not decode their own label format; the capability was licensed separately and they had declined to buy it. Writing the decoder in C cost less than the license and made the rest of the system possible.
Read the case study- Trackable, in and out, by holder
- Every item
- Bought to read their own labels
- No license
- 2023–2025Built over two years, still operating
A cyber range that a person can actually run on a Tuesday
Building an isolated hundred-machine training environment is a project. Running one every week, for cohorts and for a multi-institution competition, is a system. We built the second thing.
Read the case study- Concurrent isolated machines per exercise
- 100+
- Competition run across several institutions
- Multi-site
Next step
Tell us what’s breaking.
Forty-five minutes, no charge, no deck. We’ll tell you what we’d do, what it would likely cost, and whether what you already have can be made to work.
- Phone
- (214) 723-2510
- Reply
- A person replies, not a sequence: within one business day, from someone who would be on the engagement.