I've been incredibly fortunate over the years to work with some talented individuals while trying to solve interesting problems. Most recently I spent three and a half years working at Heroku trying to carve out a little piece of history by changing the way developers deploy modern web applications. Before I left Heroku (and as a result the USA) I spent a lot of time meeting with various VCs to get their perspective on the developer/software development space and what lay ahead of us. One made a comment in passing that stuck with me, "Heroku lowered the barriers in going from an idea to production. And they're now so low that having just an idea isn't enough. The days of thinking you'll be funded with just an idea are ancient history". I chalked it up as a minor win for all of our efforts.
In some circles Heroku are still only known for making deploying Ruby on Rails apps easy.
git push heroku master was a revelation at the time and an approach that has been often copied since. But anybody who has deployed a non-trivial app to the platform knows the magic goes much deeper than that. You get a fully-managed postgres instance provisioned for you, with the configuration automatically inserted into your app's runtime environment. If you need redis there's a number of fully-managed options to choose from. Want to play with Elasticsearch? Again there's a number of managed services to choose from. And again the configuration is automatically inserted into your environment. Even more incredibly it takes only a second or two for all this to happen.
Never before has such access to technology been available to so many so quickly.
Adam Wiggins, co-founder of Heroku, would occasionally speak of a future where programming literacy was treated with a similar level of importance as reading literacy is today. The early origins of Heroku as a Ruby on Rails focussed IDE you could use in your web browser was in part an attempt to move us closer to that reality, by placing the tools required into the hands of millions via a web browser. And he's not alone in that thinking, Marc Andreesen famously proclaimed 3 years ago that "software is eating the world" and as software disrupts more and more sectors it introduces wave and wave of new potential software developers to the potential of their new tools and systems. One of Andreesens partners at a16z, Sam Gerstenzand, earlier this year wrote about the major potential opened up with this massive shift:
We begin optimizing success for problem solvers and business builders, not those who happen to be both these things and have been programming since age 12. We unleash new categories of startups, from builders with new backgrounds and perspectives. We unleash thousands of new startups that can now be built because this friction is gone.
I love Sam's comparison of software development to building with Lego blocks. There are many people who love the freedom of creation possible with a random assortment of blocks and can quickly assemble whatever it is they imagine. However Lego long ago recognised that not everyone is able to fully realize the potential of their little blocks without some guidance. For a few decades now the primary means by which kids around the world consume Lego is by purchasing a pack with instructions on how to build the object(s) on the box.
The same is increasingly becoming true with software and services. There's so much we can learn but seeing what people have built previously. What blocks did they use? Why those ones? What blocks should I use if I'm trying to build a new thing?
There were a few things that I had hoped I could focus on at Heroku regarding Add-Ons, that I never got the chance to. One of them was discoverability and decisions. With so many different pieces of functionality that you could add to your app, one common challenge I heard about from customers was the need to help people make better decisions. Developers were on their own when it came time to picking Add-Ons, and that's still very much true today. And yet when weighing this problem against the myriad of others we had to deal with for the core platform, it was always clear that Heroku's focus had to remain on the hosting platform's DX.
Heroku, like many other providers is focused on providing the best Legos which is the best thing to for it to focus on. Without that core piece to build upon, everything else falls apart. But outside of the context of that core piece, the people using the Legos have 5-10, 15, 20 moving pieces, and they need help choosing the right pieces and putting them together.
On the opposite end of the experience, in my role at Heroku, I dealt with enterprise and developer-focused vendors frequently. I saw how most of them benefited from the distribution that Heroku provided. Add-Ons would instantly get access to Heroku's large customer base via the Add-Ons Marketplace; some services even launched there. In return for this distribution, Heroku has revenue-share agreements in place. So I always knew that whoever was able to nail the Legos problem for users would also be solving the distribution problem for vendors, and as a result would be able to capture a lot of the value in that chain, just as Heroku's Add-Ons did. It would be a huge business opportunity.
When I first learned of Leanstack.io a few months ago, I immediately recognized the problem it was solving. After speaking to Yonas and hearing his vision for what would become StackShare, it was clear that he had thought about and learned much about this problem; and more importantly, that he was going about solving it in the right way. Like most developer services, I believe a company solely dedicated and completely focused on solving a specific problem will beat anyone else doing it as a supplementary/complimentary activity. I think StackShare has the potential to do something truly amazing and help developers in a way that's never been done before.
That's why I invested in StackShare. I've also joined as an Advisor and am excited to tag along for the ride.