DatoCMS: bootstrapping to €6.5M ARR
Stefano Verna and Matteo Giaccone on bootstrapping DatoCMS to €6.5M ARR with three and a half developers: six-week Shape Up cycles, a decade on Heroku before a triple-rehearsed five-minute-downtime migration to Kubernetes, and why staying small was a choice, not a constraint.
Stefano Verna and Matteo Giaccone run DatoCMS, a headless CMS that started as an internal tool inside the web agency Stefano was running as CTO and grew into a €6.5 million ARR business, fully remote across Italy, Germany, and the US, without ever raising money.
We get into why it took off when the Jamstack wave hit in 2020, how they've stayed lean enough to run 3 billion API calls a month with three and a half developers, the Shape Up methodology behind their six-week ship cycles, and the decade on Heroku that ended with a carefully rehearsed migration to their own Kubernetes cluster.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
How did DatoCMS go from an internal tool at your agency to a 6.5 million euro business with no outside funding?
DatoCMS is a headless CMS — a content management system that delivers content through APIs, so developers can build with whatever stack they want and editors get a clean interface. It started inside a web agency, where we'd tried a bunch of things, from WordPress to custom backends, and nothing hit the sweet spot of maintainability, cost, and speed. Static site generators were starting to grow and seemed like a good fit for a lot of our problems at the agency, but there wasn't a good or cheap CMS to pair with them. So we built one, used it internally for about a year, then released it publicly just to see how it would land. We got kind of lucky — Jamstack was exploding, Netlify and Gatsby were taking off, and industry analysts were pushing everyone toward that architecture, so we rode the wave. But it wasn't an overnight success by any means. It was one person working on it part-time for at least two years alongside an agency job, and it took about four years to become ramen-profitable — the company wasn't even properly funded internally until 2019. Then in 2020, everything accelerated beyond our control: we went from ramen-profitable to around a million euros in revenue in a single year, with just three people. Now we're 13 people, fully remote across Italy, Germany, and the US, doing 6.5 million euros in revenue, handling about 3 billion API calls a month for around 200 agencies using us regularly — almost all word of mouth, still barely any marketing.
Why do you think it took off specifically in 2020?
Honestly, it was a mix of things we couldn't control. The whole industry was moving toward that architecture, we already had a pretty solid product, there wasn't too much competition in this specific space yet, and platforms like Netlify really needed to showcase use cases that proved the model worked — so they liked having us show how easy it was to integrate. We ended up using their marketing efforts to promote ourselves too, first with Netlify and then Gatsby, which was huge at the time even though it didn't work out for them long term. The whole headless, static-web space was growing, so the pie was growing for every headless CMS at once, and our share grew along with everyone else's. We were lucky to be in the right spot at the right time with a solid product — and we still have plenty of customers from 2020 and 2021 with us today.
Why were people choosing you specifically over the alternatives at the time?
Probably our integrations with other players in the headless space, but also that we were more approachable than the competition — as a small company, people were speaking directly with us. When you don't fully understand how a new architecture works or how the pieces fit together, being able to talk directly to the people who can make decisions and ship things is reassuring. People would ask for features and we'd ship them in about a week. We were also cheaper than the alternatives, and we could afford to be, because we were small and didn't need huge revenue just to stay in business — some competitors were figuring out how to maximize revenue by chasing bigger clients, while we focused on the small fish, since both of us came from small web agencies and understood that world. We know price is a big deal for agencies specifically, because they have to resell what they choose to their own clients.
Staying small feels like a genuine principle for you, not just a constraint. What does that actually mean day to day?
We know who we are — we like building products, not building shells or businesses for their own sake, and we like staying small because we believe the bigger you get, the more boring the work becomes for everyone. That's not really a sacrifice for us, it's who we are: try to be as simple as possible, build for yourself, keep costs low. There are plenty of other ways to build a business, and not every kind of business can use this strategy — some need serious investment before they can even start. But there's a lot of room to build something great while keeping to those rules, without chasing hypergrowth for its own sake. In software there's no physical ceiling on how complex something can get, so it's very easy to let things get complicated if you're not deliberate about it.
How do you actually decide what to cut when building something? You've mentioned shipping while still a bit uncomfortable with the result.
We think about a feature as possibly omitting parts of a bigger version of itself. It's easy to abstractly say "it would be nice to also add that," but we try to avoid adding anything until someone actually asks for it — we've discovered over and over that the extra part wasn't the core of what people needed and nobody was using it. A silly but real example: we had a feature to create new environments that copy all your content, and for years you couldn't rename an environment once you'd named it. Eventually enough people asked, so we added renaming — a very basic thing, but we'd deliberately left it out until it was clearly needed. We use the Shape Up methodology to help with this: six weeks to work on something, and you have to sacrifice something to ship in time, otherwise it doesn't go out and isn't automatically picked up next cycle — it might not even get published. The same goes for the backlog of feature requests and small fixes: carrying an infinite backlog around is a huge mental burden, so we start fresh every six weeks. If something really matters, it'll keep coming up and will be in our minds when we plan the next cycle; if it doesn't, it just falls away. Right now we're building dark mode as a six-week project, and we already know some rough edges will be left out — like plugins built on our older plugin SDK that won't get the new UI right away. That's a sacrifice we're happy to make rather than trying to cover every corner perfectly.
You're doing 6.5 million euros in revenue and 3 billion API calls a month with three and a half developers. How?
We focus only on the core product — anything that isn't core, we delegate to someone else and just pay for it, and pass that into our regular pricing. Image transformation and CDN, video streaming, all the infrastructure — that was on Heroku for years, so our maintenance burden around infrastructure and security was very small. That matters a lot when you have a huge surface area to cover: integrations with every framework, a plugin SDK, our own content-editing studio, GraphQL and REST APIs. It's ten years of consistent, small changes — we've never done a huge rewrite of everything, never done anything that could jeopardize the whole engineering team for a long stretch. If you look at screenshots of the first version, it's very simple and missing most of what we have now, but you still recognize the product. We also kept the stack boring on purpose: we started with Rails, which meant not reinventing everything early on when there was more uncertainty about what we were building, and we still just use Postgres for everything, including JSONB columns to handle the fact that a CMS has to support free-form, per-record schemas. We added sharding over time, but it's still just Postgres — no microservices, we simply can't afford that with three and a half people. Postgres has been genuinely impressive at handling how complex our queries have gotten.
You moved off Heroku onto your own Kubernetes cluster on AWS last year after a decade there. How did you pull that off without it being terrifying?
We would probably still be on Heroku today if it hadn't clearly started going into maintenance mode — you could see the direction from the outside, so we made the move last year. Our Heroku bill had gotten to somewhere between 150 and 200 thousand dollars a year, and running it ourselves ended up costing a bit more than half that, but with no comparison in performance — our databases are about half the size they were, web servers are at least three times faster, it's honestly kind of mind-blowing. The migration itself took about six months of a full-time-equivalent person's time and was a pretty scary project going in, but we ended up with about five minutes of downtime. We used our CDN and edge workers to duplicate real traffic to the new, read-only infrastructure, then wiped and repeated that rehearsal three times, so we knew exactly how the database would behave warming up under load and how the machines needed to be sized before we ever flipped writes over. By the time we actually committed, we had a full checklist and knew precisely what to expect — it ended up being genuinely chill. We did it early on a weekend morning, all in the same office, coffee and croissants, with a second attempt planned for the next morning in case the first one failed. It went fine the first time, so we had Sunday to relax.
You mentioned trust with customers earlier — how does that actually show up, say with refunds or support?
We trust each other a lot internally to begin with, which helps a lot with staying small and fast — there isn't much process built up around people, partly because some of us have worked together since university. With customers, we try to be very transparent and avoid overcomplicating things. If we mess something up, or something's unclear about a bill, or there's an unexpected traffic spike we can't fully explain, we'd rather just refund or offer credit as a goodwill gesture and move on, rather than argue about who's at fault. That's how I'd want a company to treat me. We support somewhere between 1,500 and 2,000 customers with two support people, partly because we keep the commercial and support conversations simple — we'd rather leave money on the table if it closes things faster and keeps someone happy, and being small with healthy margins means we can do that without escalating two layers up to ask permission. If a customer has an issue and it feels like emails are creating a misunderstanding, we're happy to just jump on a five-minute call and sort it out immediately, rather than dragging it out over another dozen emails — and in seven years, nobody's ever abused that by booking a call for no reason.
Any closing lesson for other DevTools people?
Try to stick with what actually works for you. There's a lot of noise around VC funding as basically the default way to build a company, but it's important to stay who you really are along the way — there isn't only one way to do this. If you like working with a small team, that's completely fine; you don't have to chase growth at all costs, and you can build something that matters to you and to other people without following everyone else's rules. We've also never done crazy hours, since the beginning, because this is a marathon, not a sprint — it pays off more to be consistent and improve a little every day than to run fast and burn out. It took a long time to get here, and if we'd gone faster we probably wouldn't have ended up where we are. There's also just luck involved every step of the way — there's no secret recipe at the end of it.