It was early 2019. The year where everything was normal and perfectly fine.
I was in my car. On my way to the office. (That was in the days when we had to drive to an office to do work on the same computer that rode down the road with us.)
The Jamstack was on my mind. This new, revolutionary way of building websites. The idea was catching on. Blowing up, in fact. But that part wasn't surprising to me. I was working for an agency and we'd gone all-in on the Jamstack a year prior. The potential of this change was palpable. By the time 2019 rolled around, we felt like seasoned veterans. Experts.
Finding a Missing Piece of the Jamstack
And yet, for all this so-called expertise, I felt I was missing something. Why is there so much innovation in this space and I don't have a single idea of a product? I always had an idea, and it was really starting bug me that being so excited about the Jamstack was clouding my ability to see any issues or opportunities to bring something new to the space.
And then it hit me.
The Jamstack is all about decoupling services. At first, I'd thought about that as a good thing. Developers get to decide what the best tool is for each job and bring those tools to each project.
But the reality is that not everyone wants to go through the process of making so many choices. After all, that's why Ruby on Rails was so great. Convention over configuration. It pushed devs to focus on solving business problems and removed trivial decisions like establishing a file-naming convention.
I needed to invent a service that connected all these services. To couple the decoupled.
And so I went to work.
First step. Research.
A quick google and ... my heart sank.
It already existed.
Stackbit.
Stackbit: The Early Days
In the early days, that's exactly what Stackbit was — a service that coupled various decoupled services of the Jamstack to provide users with a working website without having to set up each service.
Suddenly, developers could use one of Stackbit's prebuilt themes to generate a site that is equipped with a static site generator, ready to be wired up to a headless CMS, and automatically deployed to Netlify on their behalf, all after setting up a new GitHub repo with the website's code.
Brilliant! I thought. (Right after thinking: Hey, that was my idea!)
Addressing Jamstack Frustrations
A few months later I was back at the drawing board. My clients and in-house content team had been consistently complaining about the editing experience of Jamstack sites.
There's no preview. The build takes forever. You keep switching up the CMS we're using every project and I can't get into a groove. I'm publishing blindly. This is anarchy!
Aha! I thought. Another opportunity. One of the very few things I could find wrong with the Jamstack. Previewing — real-time, in-context editing is extremely difficult. It was a step backwards from the old way of doing things.
Well, great! Then we'll build it.
First step. Research.
After the first google, I felt that sinking feeling creeping in again. And what's worse, it was the same company — Stackbit — one step ahead of me again.
Stackbit: Introducing a Visual Editor
Stackbit had seen that same problem. Wiring up services wasn't enough. There was a void in between all those services. It was really difficult to maintain and edit Jamstack sites. So Stackbit built an in-context visual editor, a delight to non-technical content editors working with Jamstack sites.
Always One Step Ahead
Well, I couldn't wait around any more. These folks were always one step ahead of me, so ... I went to work for them. And here I am today.
And today Stackbit is working on something super exciting.
Stackbit: The Next Evolution
(Now I can say) We have recognized that most of our developer users want the same things. They don't really want to make decisions about all these disparate tools. They want a solid foundation of code that makes it trivial to add new features for their sites. And the folks doing the content editing want to be able to build up rich experiences quickly, without the help of a developer.
We're making a bet to help our developers and content editors. We're going all-in on Next.js. Just about every new Stackbit site will soon be a Next.js site. We're building a component library that will serve every one of our themes. So when we make an update to our library, all of the themes (including existing projects) will benefit. And we're reworking our studio UI (the place where visual editing happens) to make it a more pleasant and seamless experience.
This next version of Stackbit is going to be incredible! And we're offering sneak peeks through our Early Access Program. To learn more (and get some super sweet Stackbit swag), message us on Twitter, send us an email, or join our community.
As inspiration and background for this piece, I sat down with our COO, Dan Barak. Here's the full interview, which has much more of the story from Dan's perspective.
Throughout my Jamstack journey, Stackbit has always been one step ahead of me. Now that I'm part of the team, I know what the next move is, and it's awesome! But before we look too far ahead, let's step back and take a look at Stackbit's own Jamstack journey.
