“No Man is an Island”, says the famous poem from 1624.
Thinking of where we stand today, certainly neither does any SaaS.
Whenever we’re on a call with a potential customer, it is clear they are thinking of Stackbit as an element in a larger story - either a rebuild or a major upgrade to a website (or an entire line of sites), which often means a significant re-tooling effort is underway all across the tech stack of that customer.
Naturally, that means a lot of questions like these: how does Stackbit fit with tool X or software Y? do they actually overlap? what about framework Z we heard about?
Often, the tech team we're talking to is still uncertain about multiple elements of their chosen stack.
That's totally understandable!
Even as a tech-savvy decision maker for a business doing anything from dozens of millions to billions a year, armed with an intimate knowledge of your in-house tech stack, you're aware of the limitations of your knowledge of things moving quickly outside in the wider world.
Perhaps it’s become cliché to point out, but still true:
Countless organizations are in the midst of adopting a whole new stack of tools, away from legacy all-encompassing CMS and e-commerce platforms and towards an open-source stack of tools: React being always popular, headless CMS (e.g. Contentful and Sanity), APIs & microservices, and so on.
As a vendor in such times, for the most part we don’t actually need to pitch this transformation at all - there’s simply a huge market pull for it.
Established vendors are either going with the flow - or bleeding business to younger, faster players.
What's driving this change?
Underlying this trend, there’s often the wish by the business end (by which I mean sales, marketing and management) to get the brand experience just right; to have a responsive, fast, modern site; to get unshackled from many painful constraints they know all too well.
Often, it’s a wish to switch from a monolithic does-it-all platform - that was once hailed as the big solution but now feels too much like a big weight - into an interconnected stack of best-of-breed tools.
Of course, there’s much that could go wrong.
Like any home renovation project ever, it takes a big effort in time, money and conflict management skills to get the rebuild delivered. But the promise at the end usually goes beyond look & feel, whether it’s a physical house or a website:
It’s not just about how nice the home (or your brand new website) is gonna look. It’s about how you want the people inhabiting or visiting it to feel.
Fueled by these wishes, the tech decision makers within the company go about the re-tooling effort for their org.
I would only half-jokingly say that the typical first step organizations take in this journey is hire or train a whole team of React developers ;-)
React, React Everywhere!
Here’s an interesting metric I personally like to track from time to time:
world-wide search volume for React vs. Wordpress. Here’s the trend for the last five years:
Apples vs. oranges, you might say.
And technically, you’d be right: one is a library for building front-ends. The other positions itself as a website builder that has it all.
I think it is a useful view nonetheless: with Wordpress you commit to the all-encompassing platform first. With React, you typically build bottom-up. While monoliths are sinking (slowly but surely), engineers the world over are passionately preaching the new stack.
It's a tectonic shift.
As you come up with all the basic building blocks of your new stack, however, you realize that once the old king is down (to much rejoice by many developers), there’s a whole new challenge:
React and all other cool tech non-withstanding, how do I actually let my people build, edit and add content to the new website?
(without needing R&D for everything, that is... the idea was to make business more agile, not to increase dependency on engineering!)
Say what you will about legacy CMS - at least there was a clear (if painful) way to put content in!
The Old King is Dying, Now What?
At Stackbit, we’ve set out to tackle this problem and enable freedom of content creation, without forcing you into a new monolith. Developers and content creators have clear roles with Stackbit.
If you identify with any of the challenges above, you probably have a ton of questions -
- Does it work with a headless CMS? does it require one?
- What about search?
- Image serving?
- Analytics?
- Logged-in users?
- Multiple data source?
...and much more.
In the next part of this post series, we’ll dive into these questions in depth.
Meanwhile, you’re definitely invited to talk to us. We get your challenge.
