Monolith to modules
The company's first web product, rebuilt from one Angular template into modular React, with the admin portal and employer billing it never had.
- Client
- Great Lakes Reality Labs
- Sector
- Career marketplace, skilled trades
- Role
- Lead frontend engineer, founding team
- Year
- 2021-2024
- Stack
- React, Angular, TypeScript, Stripe
- Result
- Monolith retired
The problem
Detroit has a gap between high schoolers and the trade programs built for them. A student who is not heading for a four year degree finds automotive, manufacturing, and skilled trades programs mostly by word of mouth, which means the programs that reach them are the ones somebody happened to mention.
The product closed that gap: a searchable place where students could find trade school programs the way anyone else finds a job. It was also the company's first web product, which meant it was built the way first products get built, as a single Angular template one engineer could hold in their head.
The constraint
The site could not stop. Students were using it and schools were listed on it, so there was no freeze to hide a rewrite behind. Whatever replaced the template had to arrive in pieces, each piece live, while the rest of the old application kept serving traffic.
The forcing problem was parallelism. Everything in the template was coupled to everything else, so two engineers working the same week collided, and a change to one surface could appear somewhere unrelated. The team could not grow into the codebase it had.
What I built
A shell that could host both
A routing layer that let the React application take ownership one route at a time while Angular kept serving everything it had not reached yet. Nothing was built twice, and no route existed in both applications at once.
An admin portal, because there was not one
In the Angular template there was no way for an administrator to manage users at all. Every account change was a person asking an engineer. I built the admin portal in React alongside a role-based access model covering students, school administrators, employers, and internal staff, so managing accounts stopped being a support ticket aimed at the dev team.
Billing shaped like the marketplace
Students and schools never paid; employers did. Stripe multi-tier subscriptions priced on the two things an employer actually consumes, job postings and employee accounts, with custom plan flows so a company could land on the tier that matched its hiring rather than the tier that was easiest to bill.
Result
No route was served by the original template by the end of the migration.
Administrators could manage users themselves for the first time, instead of routing every account change through an engineer.
Multi-tier plans priced on job postings and employee accounts, running against paying customers.
All of it shipped and served users. The company later changed direction and rebuilt the product with an outside team on a different stack, which is the ordinary fate of a lot of good software and says nothing about whether the work was right at the time. The resume figures for this engagement (20% faster, 30% less manual oversight, 25% more conversions, 15% MRR) were identified as estimates and are deliberately absent.
What I would change
The migration ran well past the estimate I gave for it, and the cause was not technical. Requirements reached the client through QA and reached engineering late, partly, or not at all. We would build to what we had been told, then discover mid-route that the actual requirement was different, and a rebuild that depends on knowing what each route is supposed to do does not survive that well.
What I changed was the meeting, not the process document. I insisted that at least one developer sit in on discovery calls, so the people who would estimate the work heard the requirement first-hand instead of third-hand. The surprises dropped immediately. What I would do differently is insist on it in month one rather than after the estimate had already slipped, because by then the number I had given people was the number they remembered.
Email me
If you are hiring for a senior full stack or frontend role, a line about the team and the stack is enough to start.