Let's focus on the Interface Layer

It's not unusual to see ideas for different interactions for products that already exists in abundance. Everyone kinda wants their own little ideas baked in, and it usually comes from frustration experienced first hand.

Something lots of people struggle with every day, is video collaboration, and a little week ago I stumbled upon this "Request for Startup" tweet:

So how would you go about doing that product in 2019?

All of these bullets for the product is all about the user experience, the user interface. It differentiates itself solely on that, so whatever runs the stuff at the back-end is really not that important.

So what can we do now, that we couldn't do 3-5 or 10 years ago?

Well, we can completely ignore WebRTC infrastructure, we don't need to worry too much about scale, we sure as h*** can forget everything about servers, patches, databases, video encoding and all of those wonderful distractions.

Today there are so many offerings that facilitates the heavy lifting of such things - in this case it could be Twilio's Programmable Video APIs.

Need to take payments? Stripe is pretty easy to get going.

E-mail? SendGrid, MailGun among others are up for that job.

We have super powers!

There's a ton of APIs ready for us to use, all the heavy lifting is taken care of, we can focus on our product, user experience, business model and all that great stuff.

We pay for what we use, and we can expect a great deal of scalability from day one.

So how does the products we build change, when we do not have to worry about so much infrastructure and back-end stuff?

How does the team that build products now change?

Well, from a team point of view we can increasingly invest in design and development of the product, instead of buying or configuring hardware.

We can much quicker focus on prototyping the experience, and gather feedback from real people.

A more implementation minded perspective, we increasingly want to keep the front-end as atomic and separated from the back-end as possible - well, we always wanted that, but today we'd never keep code that interacts with back-end APIs such as Twilio, tighly coupled to the front-end and release both in the same package.

We increasingly want to use messaging to connect the smaller parts into the entire product experience.

Since we now depend more and more on external APIs, we have to be able to address updates proactively, or very quickly as we cannot control how and when the API provider will release a new version of the product.