A prototype that changed the direction of the company

Situation

Before SmartFrame was a company, it was basically an experiment inside Pixelrights.

Pixelrights built portfolio websites for photographers. We could see a wider problem around how images were published on the web.

Once you put a normal image online, the photographer has very little technical control over what happens to it afterwards.

We had some ideas for changing that.

They were technically interesting, but interesting technology is a terrible reason on its own to change the direction of a company.

So before committing too much time and money, we needed to find out whether the idea actually worked.

What I did

I started building prototypes.

The early work explored different ways of protecting and distributing images, including techniques for transforming image data, reconstructing it in the browser, watermarking and delivering different image data depending on the viewing context.

Some of it worked.

Some of it didn't.

The useful part was finding that out quickly.

Eventually I built the first full-stack MVP of what became SmartFrame and set up the initial production environment.

I deliberately wasn't trying to build the final product.

The main questions were much simpler.

Could we make this work in a normal browser?

Would it behave well enough on an actual webpage?

Could somebody else integrate it without heroic amounts of custom development?

Could we take it outside our own environment and make it work there too?

Once we had something credible, we started putting it into external integrations.

That was much more useful than another internal demo.

A prototype always looks better when the person who wrote it is standing next to it.

External integration exposes all the things you quietly assumed would work.

The company-level decisions were made with the other founders and leadership. I wasn't sitting in a room unilaterally deciding that Pixelrights was now SmartFrame.

My part was reducing the technical uncertainty far enough that the wider decision could be based on something real.

Some of the R&D later went into patent work as well. I worked directly with our patent lawyers, wrote and refined descriptions of the methods, reviewed filings and explained where our approaches differed from earlier work.

SmartFrame eventually developed four patent families.

I wouldn't use the patents as evidence that the commercial idea was good. Plenty of patentable ideas make terrible businesses.

They do show that there was real technical invention behind the prototype.

Outcome

The prototypes and early integrations gave us enough confidence to keep investing.

SmartFrame went from an internal experiment to the main technology proposition, and eventually became a separate company where I was CTO and co-founder.

That is the part I think the prototype can fairly take credit for.

It answered enough questions to justify the next decision.

Everything after that was another set of questions.

The later company went through multiple product directions and eventually operated at a completely different scale. The original prototype didn't predict any of that.

It didn't need to.

Its job was to tell us whether the next investment made sense.

What I took from it

I still like prototypes for exactly this reason.

If there is a big technical or product decision ahead, I would much rather spend a small amount of time building the thing that answers the awkward question than spend months arguing about it.

Before starting, I want to know what we are trying to learn.

Then build as little as possible to learn it.

Sometimes the answer will tell you to continue.

Sometimes it will tell you to kill the idea.

Both are useful outcomes.