Rebuilding for the Next Decade

01Executive Summary & Motivation

The Next Platform is a ground-up rebuild of the Company's flagship retail and service management product, replacing a decade-old monolith with a domain-driven, cloud-native application built for scale, integration, and speed of delivery.

The original product, the Legacy Platform, served its market well for many years, but the technology beneath it aged faster than the business grew. Each new feature became more expensive to build, harder to test, and riskier to deploy. Customer expectations shifted toward modern, mobile-friendly experiences and open integration with third-party systems, while the underlying framework made both increasingly difficult.

The Next Platform addresses this by rebuilding on a modern, well-supported foundation with a clear separation between business logic and delivery mechanics. The goals were straightforward:

• Sustainable velocity: make new features cheaper and safer to ship over time, not more expensive.
• Scale: support growth in customers, locations, and transaction volume without architectural rewrites.
• Integration-first: treat the API and third-party connectivity as first-class concerns.
• Modern experience: deliver a responsive, consistent, accessible UI across devices.
• Continuity: migrate without disrupting the businesses that run on the platform daily.

02A Brief History, and Why Change Mattered

The Company was founded to solve a real, unglamorous problem: independent and multi-location retail-and-repair businesses were running their operations on a patchwork of spreadsheets, paper tickets, and disconnected point-of-sale systems. The Legacy Platform brought point of sale, work-order tracking, inventory, and customer records into a single system, and for businesses drowning in manual process, that was transformative.

Over roughly 15 years, the product grew from a focused tool into a broad operational backbone. It has processed hundreds of thousands of repairs for thousands of users across dozens of countries. Success brought scale, and scale exposed the limits of the original design.

Why the change became necessary

The Legacy Platform was built on a framework and architectural style that were reasonable choices at the time but became liabilities as the product matured:

• Aging framework and runtime. The foundation reached the edge of active support, making upgrades, security patching, and hiring progressively harder.
• Tangled business logic. Rules lived in controllers, views, and shared globals rather than in a coherent domain layer, so changes rippled unpredictably across the system.
• Testing friction. Low testability meant every release carried risk, which slowed the pace of change and raised the cost of every fix.
• Integration pressure. Customers and partners increasingly needed API access and modern integrations that the legacy design was never structured to provide.
• Experience gap. Expectations for responsive, mobile-friendly, accessible interfaces outpaced what the legacy front end could deliver.

Rather than attempt a risky in-place rewrite of the existing system, the Company chose to build the Next Platform alongside it, preserving continuity for existing customers while establishing a foundation designed for the next decade of growth.

03Architecture Overview

The Next Platform is a modern server-rendered application with a reactive front end, organized around Domain-Driven Design (DDD). The single most important architectural decision was to separate what the business does from how it is delivered.

Three-layer separation

Crucially, these boundaries are not just convention. They are enforced by automated architecture tests that fail the build if, for example, the domain layer reaches into the application layer. This keeps the design from eroding under delivery pressure.

Technology choices and rationale

04Legacy → Next Migration Strategy

The overriding constraint was continuity: real businesses run on the platform every day, and a "big bang" cutover was never an acceptable risk. The strategy is incremental and coexistence-based.

• Run side by side. The Next Platform operates alongside the Legacy Platform, with a controlled connection to legacy data so both can read a shared source of truth during transition.
• Migrate by capability. Features move to the Next Platform in prioritized slices rather than all at once, letting the team validate each area with real usage.
• Preserve data compatibility. Data models are designed to remain compatible with legacy structures, avoiding disruptive one-way migrations.
• Multi-tenant awareness. Tenant-aware migration tooling manages schema and data changes safely across many customer environments.
• Progressive cutover. Traffic and functionality shift gradually, with the ability to fall back if a slice needs more work.

05Domain Model & Business Capabilities

The domain layer models the real operational world of a multi-location retail-and-service business. Core capability areas include:

Business rules are expressed with domain building blocks: value objects for concepts like money and status, specifications for reusable business rules, and domain services for multi-step workflows, rather than being scattered through controllers and views. The result is logic that is discoverable, testable in isolation, and resistant to accidental duplication.

06Permissions & Multi-Location Model

One of the most demanding areas of the domain is access control. A user is not simply an "admin" or a "clerk." Permissions are scoped by location, because a person may hold different roles at different storefronts, and many businesses operate dozens or hundreds of locations.

The Next Platform models this explicitly with a role-and-location resolution system: given a user, an action, and a location, the platform resolves the effective roles and answers a clear allow/deny decision. Designing this as a dedicated, well-tested domain concern, rather than sprinkling permission checks through the UI, keeps authorization consistent and auditable as the product grows.

07Frontend Approach

The front end pairs a reactive component framework with server-driven routing, and standardizes aggressively on a shared component library.

• Server-driven reactivity. Inertia connects server-side controllers to reactive pages, so the team ships modern interactions without maintaining a separate API contract for every screen.
• Standardized components. The UI is built from a consistent component library rather than bespoke widgets. This improves visual consistency, accessibility, and delivery speed, because new screens assemble from proven parts.
• Modern build pipeline. Fast builds and hot reloading keep the developer feedback loop tight.

08Quality Engineering

Testability was a first-class design goal, precisely because it was the Legacy Platform's biggest weakness. The Next Platform layers multiple safeguards:

• A testing pyramid of unit tests (domain logic), feature tests (end-to-end workflows), and integration tests, using a modern, expressive testing framework.
• Architecture tests that enforce the DDD layer boundaries automatically, so the design cannot silently decay.
• Static analysis to catch type errors and defects before code ever runs.
• Automated formatting to keep the codebase consistent without manual bikeshedding.
• UI / acceptance testing driven through browser automation for critical user flows.
• CI gating so all of the above must pass before code merges.

# Format, analyze, and test before committing
<format> && <static-analysis> && <tests>

09Cloud & DevOps

The Next Platform runs as a containerized workload on AWS, with infrastructure defined as code so environments are reproducible and reviewable.

• Containerized deployment on managed container orchestration for elastic scale.
• Infrastructure as code (Terraform) so environment changes go through the same review process as application code.
• Multiple environments (development, sandbox, and pre-production) mirror production to de-risk releases.
• A disciplined branching and release workflow that promotes changes through environments with automated checks at each stage.

10AI-Assisted Development

A distinctive part of the Next Platform program is a purpose-built AI-assisted development toolkit woven into the daily workflow. Rather than treating AI as a novelty, the team encoded its own engineering practices into reusable assets:

• Skills: packaged domain knowledge for recurring tasks (commit standards, documentation templates, testing patterns, estimation, and more).
• Specialized agents: guided workflows for planning, implementation, code review, and acceptance testing.
• Persistent memory: context that carries useful knowledge across sessions, reducing repeated discovery.
• Issue-tracker integration: planning and implementation flow directly from tickets to code to review.

11Lessons Learned & Roadmap

What worked

• Investing early in enforced architectural boundaries prevented the very decay that doomed the legacy design.
• A coexistence-based migration protected customers and let the team learn from real usage incrementally.
• Standardizing on a shared UI component library accelerated delivery and improved consistency.

What was hard

• A shared database throughout coexistence. Because the Next Platform and the Legacy Platform ran against the same database the entire time, every change had to protect backward compatibility while still moving as close to the target architecture as the plan allowed. Progress and compatibility had to be balanced on every step.
• Vocabulary collisions between old and new. Rebuilding functions from scratch meant adopting industry best practices, and on occasion the resulting terminology conflicted with established legacy jargon. Reconciling the two vocabularies without confusing users or developers took deliberate care.
• Modules that are both self-contained and synergistic. Each module had to stand on its own while still working seamlessly with the others, a tension that required disciplined boundaries and clear contracts between capabilities.

What's next

• User acceptance testing. Validating the Next Platform with real users to confirm it meets operational needs before broader rollout.
• Marketing and partner promotion. Working with partners on integrations and campaigns to attract new customers.
• A product feedback system. A new mechanism for collecting usage and customer feedback data, then adjusting the product based on what that data reveals.

Closing Thought

The Next Platform was never only about newer technology. It was about restoring the ability to move: to ship value to customers at a sustainable pace, safely, for years to come.

When technology becomes an obstacle rather than an enabler, every decision gets harder, every feature takes longer, and every release carries more risk. The goal of this rebuild was to reverse that trajectory, to create a foundation where good practices compound over time instead of eroding under pressure.

This project demonstrated that even deeply entrenched legacy systems can be replaced thoughtfully. The key was never trying to do it all at once. By running systems in parallel, migrating capability by capability, and keeping the business operational throughout, we avoided the risks that sink so many modernization efforts.

The Company now has a platform built for the next decade of growth, a team equipped to evolve it, and, most importantly, the freedom to focus on serving customers rather than fighting their own software.