Aptora’s products grew up around a large, mature VB6 codebase. As the company planned its next generation, I took on a dual role as Lead Engineer and Scrum Master: finding a technical path forward, and building a delivery process that could carry it out.
Starting Point: The Same Rules in More Than One Place
The platform had grown the way long-lived software does. Key business rules were implemented in more than one product, so fixing a bug often meant fixing it more than once and hoping nothing got missed. The system worked, but the cost of change kept increasing, and it was hard to predict what a given change would touch.
The product is both a field service platform and an accounting system, so correctness and controlled change were not optional.
The Decision: Don’t Copy the Problem Forward
One proposed path was a straight conversion of the existing VB6 code into a more modern desktop framework. On paper it looked like the faster, lower-risk option.
When a sample of converted code came back for evaluation, it reproduced the legacy structure faithfully, including the coupling that made the original hard to change. It would have compiled and run. It would not have made the system any safer to work on.
I recommended stepping back and fixing the architecture instead of carrying it forward: clear boundaries, with business rules implemented once behind APIs. Leadership agreed, and that set the direction for everything that followed.
What We Built Instead
- An API-first service layer. Core operations sit behind REST endpoints with shared validation, so every product gets the same behavior and a rule changes in one place.
- Shared identity. One model for sign-in and permissions across products, so new services inherit it instead of rebuilding it.
- A web front end direction. I built a Blazor proof of concept so stakeholders could judge feasibility, performance, and user experience from working software, then established the component and data-access patterns the team built on.
Making It Executable
Architecture alone would not have been enough. I became the team’s Scrum Master, earned my PSM I, and led the change in how work flowed: a single prioritized backlog, a steady sprint cadence, and one clear path for stakeholder requests.
On the engineering side that meant pull request review, tests that block a merge when they fail, CI/CD pipelines across dev, staging, and production, and QA working inside the team instead of at the end.
I mentored developers on the new patterns and built scaffolding so new services followed the architecture by default. The point was that the decisions did not live only in my head. They were encoded in code, pipelines, and documentation, so the team could keep building as people changed.
What I Took From It
Meaningful technical change requires buy-in. Progress came from explaining tradeoffs clearly, earning trust with working proofs of concept, and helping people see how the change would improve their day-to-day work.