Modernized a marketplace as CTO

As CTO I was responsible for the full technical direction of the business - from the day-to-day operation of a legacy shop system to the complete conception and launch of a new marketplace business model. I led an organization of up to 16 developers, DevOps engineers, Product Managers and BI analysts, and I was accountable at the C-level for whether the technology strategy and the company strategy were actually the same strategy.

The situation

Juniqe sold art and design products through an established e-commerce shop. That shop worked, it carried the revenue, and it had been built for exactly the model it served: one catalogue, one seller.

The marketplace came out of the merger with the Myposter Group. It was not a plan the business already had; the idea only existed once the two companies were one. That made the platform question and the integration question the same question: the architecture had to carry a business model the company had not had before, on top of another company’s systems, teams, and roadmap.

The shop itself was a decade of accumulated decisions, built and extended over that time by several engineering teams, none of them still with the company. The code was there; the reasoning behind it was not. Nobody could say why a given piece worked the way it did, which parts were load-bearing, or what would break if you touched them. One bare-metal server at a hosting provider stood in for the whole problem: nobody knew what ran on it or what depended on it, and nobody was willing to switch it off to find out. So the invoice kept getting paid, and it kept getting paid until we shut the old platform down and there was nothing left for it to break.

The plan was to build the marketplace on top of that shop. A few weeks of investigation showed it was not possible. A marketplace - many sellers rather than one catalogue - is not a feature you add to a shop: it needs a different set of primitives for inventory, onboarding, pricing, fulfilment, and payouts, and the old system’s assumptions ran through all of them. So the scope changed. We had to build the new platform and clear out the legacy chaos underneath it, while the shop kept earning throughout.

The constraint that defined the work

The legacy shop had to keep running, well, the entire time. This is the constraint people underestimate. It is not “maintain the old system while building the new one” - it is that the old system is the entire revenue of the business, so its worst week sets a ceiling on how much attention the new one can get. Every plan I made had to be robust to the legacy platform demanding a month of the team’s focus at no notice.

That ruled out a hard cutover: the downside was the business. The in-place route was already gone, ruled out by the investigation rather than by taste - a marketplace grown inside the old shop would have inherited the assumptions nobody could explain any more. What was left was building the new platform alongside the old one, at a pace the legacy system had a veto over.

Decisions and tradeoffs

Reuse the group’s shop system instead of Juniqe’s own. The old shop ran on Commercetools, and that was one of the things we removed. We built the marketplace on the same backend shop system Myposter and the other group companies already ran: payment, basket, products, admin, and user management existed and worked, so we extended the backend for the marketplace use case and rewrote only the frontend from scratch. The second half of the argument was people. A system several companies shared meant engineers from those companies could step in when we needed to move faster, which a platform only we understood would never have allowed. The tradeoff is coupling: our roadmap now sits next to theirs, and a change that suits the marketplace has to make sense for everyone else on the system.

Go and PHP alongside each other, deliberately. New services went to Go; the existing PHP estate was maintained rather than rewritten on principle. Rewrites that nobody asked for are how modernization programmes lose their credibility. Vue on the frontend, with AWS and GCP both in play at first - a consequence of the merger rather than a preference. I accepted it rather than spend the team’s limited capacity on consolidating clouds mid-rebuild, and we moved to AWS alone once the rebuild could carry the work.

Spot instances instead of a few large fixed ones. The old estate answered load with size: big EC2 instances provisioned for the worst day and paid for on all the others. The new platform scaled horizontally on spot capacity, which is both more elastic and cheaper. That was less a clever idea than a consequence. Workloads that can be interrupted and replaced are the precondition, and the old system could not survive an instance disappearing. Most of the modernization went like that: the architecture change is what made the operational option exist at all.

AI as candidates to evaluate, not as a mandate. This was the period when every company was expected to have an AI answer, and a good part of the job was telling apart the use cases that would survive contact with the business from the ones that only demo well. The candidates worth the time were the ones tied to the catalogue: tagging images that sellers uploaded so they could surface through related images and tag search, and generating collages and photobooks from a customer’s own pictures. The tradeoff is that evaluation costs real capacity in a year when the rebuild wanted all of it, and most candidates are supposed to die - which is an awkward thing to report upward when what is expected is announcements.

I kept BI inside the engineering organization. Analysts sat with the people building the systems that produced the data. A marketplace decision - which sellers to onboard, how to price, what to promote - is only as good as the numbers behind it, and the fastest way to get bad numbers is to have the people who model the data be organizationally distant from the people who emit it.

The part that was not technical

Most of this job was translation. Engineering, the business units, and the C-level each had a coherent picture, and they were not the same picture. A marketplace rebuild reads very differently to a marketing team planning campaigns, a finance team modelling margin, and a group of engineers who can see the coupling in the old system that nobody else can.

I spent a large share of my time making those pictures match: turning architectural constraints into business consequences leadership could weigh, and turning strategic goals into technical direction the team could act on without me in the room. That is the actual job of a CTO at this size, and it is not adjacent to the engineering - it is what determines whether the engineering gets to finish.

Outcome

The new platform launched - conceived out of the merger and delivered through it - without sacrificing the legacy shop that funded it. The old platform was shut down and the estate ended on AWS alone, with the second cloud retired.

What I would do differently

I underpriced what it costs to run two unrelated systems with one set of people. Keeping the old shop alive was not a background task. It took real capacity at unpredictable times from the same engineers who were building a platform that shared almost nothing with it - different model, different assumptions, no reusable ground between them. Switching between a decade-old system nobody could fully explain and a greenfield build is not a scheduling problem, it is a tax on attention, and none of my plans priced it as one.

It showed up hardest in timelines. The C-level needed dates; the engineers could only give estimates that were honest about legacy work nobody could schedule in advance. I translated between the two constantly, and I did it by absorbing the variance myself - committing upward, then shielding the team when the old platform took a month back. That protects trust with leadership and it quietly wears the team down. People can see the gap between what was promised and what was possible, and morale depends on that gap being explained rather than smoothed over.

What I would change is to make the drag visible instead of carrying it. The share of the team’s time going into keeping the old platform running should have been its own reported number from the start, not an explanation produced after a date slipped. It would not have changed the physics of doing both jobs at once, but it would have moved the conversation from why the new platform was late to what the old one costs to keep - a question leadership can actually decide on. It would also have let the team see that work counted, rather than watching it disappear into the delivery number.