From MVP to a global production platform

Situation

SmartFrame started as an experiment inside Pixelrights, a business building portfolio websites for photographers.

We were looking at a fairly basic problem: once you put an image on the web as a normal JPEG, you lose most control over what happens to it.

I started experimenting with ways of changing that.

At the time I was the engineer building the product. I worked through the early technical concepts, chose the implementation approach, built the first full-stack MVP and set up the initial production environment.

There wasn't a ten-year architecture plan. There couldn't have been one.

What eventually became SmartFrame went through several major changes in direction. Technology licensing, image hosting and distribution, monetisation and advertising, then much larger-scale image libraries and distribution.

Each of those put different pressure on the platform.

And every few years there was an obvious temptation: maybe this would all be easier if we just started again.

We didn't.

What I did

The architecture changed constantly over the following decade, but we tried to change it where there was an actual reason to.

Some things were rewritten. Some were refactored. Some stayed around for years because they were boring, stable and still doing their job.

That distinction became more important as the company grew.

Once customers were integrated with our APIs and our code was running across third-party websites, changing an interface had a real cost. Backwards compatibility wasn't an abstract engineering nicety. It meant customers didn't have to rebuild integrations every time we improved something internally.

So we increasingly separated the parts we wanted to change from the contracts we wanted to preserve.

APIs evolved. New connectors appeared. Front-end technology changed. Authentication changed. Image processing changed. Infrastructure changed. Operational practices became much more mature.

Where something had genuinely become a constraint, we replaced it.

Where it hadn't, age alone wasn't enough of a reason.

I also resisted building too far ahead of the business.

The original MVP wasn't designed for tens of millions of images or hundreds of terabytes of data. Doing that would have been ridiculous at that stage. We added capability as there was evidence that we actually needed it.

My own role changed along with the platform.

Initially I wrote the software myself. Later I was much more focused on architecture, technical direction, product specification, engineering leadership and deciding where investment was actually worth making.

By then this was obviously team work. The engineering organisation eventually grew to 20 people. My job as CTO was to make sure their work accumulated into a stronger platform rather than being thrown away every time the business changed direction.

Outcome

At mature scale, SmartFrame was serving more than 100 clients across more than 2,000 domains.

The platform held roughly 60 million images and more than 250 TB of data, supported over 55 million monthly impressions, and later image-processing workloads reached around 1.2 million images per day.

Availability was 99.99%.

During the same period the business went through roughly four major changes in product or business model.

There were plenty of technical mistakes over more than ten years. Some components lasted longer than they should have. Some things were replaced more than once.

But we never reached a point where the only way forward was to throw the whole platform away.

That mattered commercially.

The company could keep changing what the technology was for without repeatedly paying to rebuild everything it already had.

What I took from it

You don't need to predict what your company will look like in ten years.

You do need to avoid making today's decisions unnecessarily expensive to undo tomorrow.

When I look at an ageing platform now, I don't start with whether the architecture is modern or elegant.

I want to know what is actually limiting the business, what still works perfectly well, what customers depend on, and where changing something would genuinely buy us a useful new capability.

Quite often the right answer is much smaller than a rewrite.