The situation
Shoptimised’s platform processes product feeds for ecommerce businesses. As the platform grew, the architecture and delivery approach needed room to evolve. My responsibility covered the technology, the way we delivered it, and the people doing the work.
As a hands-on CTO, I contributed to the architecture, implementation and production rollout alongside the team. Working with two other engineers, I led a move from a coupled Laravel application to three independently deployable services over approximately six months.
The decisions that mattered
Keep the team’s strengths
We retained Laravel and built on the team’s existing knowledge. I focused the architectural change on clearer boundaries and independent deployment. That gave us a practical way to modernise while continuing to understand and operate the platform.
Make the migration reversible
We ran the new and existing systems in parallel for two weeks. We used workload testing, feature flags and a fallback path to reduce the risk of the cutover. These steps gave us opportunities to observe the new behaviour before committing the full workload.
Give engineers a voice earlier
I brought engineers into refinement and scoping earlier. We introduced smaller work items, shared estimates and clearer sprint goals. People could help shape the approach and understand the reasons behind it.
How we worked together
Alongside the platform work, I coached a Senior Developer into a Lead role. We worked through realistic planning and technical scenarios, using questions to develop independent judgment.
That engineer went on to take greater ownership of planning and mentor others. For me, this is a meaningful part of leadership: creating the conditions for someone else to make good decisions and support the people around them.
What changed
Daily feed processing grew from approximately 20,000 to 35,000, an increase of 75% in observed daily volume. The services could be deployed independently, with deployment time moving from around an hour to approximately two minutes.
The team also had clearer ownership of refinement, planning and delivery. Architecture and team development supported each other: smaller boundaries made change easier to reason about, and stronger ownership helped us maintain those boundaries.
What I take forward
The most useful architecture is one the team can understand, evolve and operate. My approach is to make the important boundaries explicit, keep change manageable, and involve the people who will live with the result.