We know who we are, and we like to stay small because we believe that the bigger you become, the more boring the work is for everyone, basically. There are a lot of areas in which you can build something great and keeping these rules.

Today, I'm talking to Matteo and Stefano from Dato CMS, a headless CMS that went from side project inside a small agency to doing over 6 and a half million euros of revenue without raising any money. We get into how they stayed lean and how they used constraints, pricing, and trust with customers to keep the business simple and durable. I think this episode is gonna be amazing for people who are looking for an alternative to the all or nothing VC approach of building a DevTool. I think the story is very interesting for people.

Yeah. Yeah. Yeah. Sure. So basically well, DataCMS is our headless CMS.

So it's a content management system that delivers content through APIs. So developers can build sites and apps and whatever whatever stack they want and editors get a clean interface. And yeah, it started as a a web inside a web agency that I was running as a CTO. We tried a bunch of stuff like any other agencies from WordPress to custom back ends and whatever, and nothing hit, like, sweet spot of maintainability and costs and and being fast. And so static site generators were starting to grow.

And it seemed like a good solution to a lot of our issues at the agency, but there was not, like, not good or cheap at the CMS to pair with them. So, yeah, I I started building one. And we used it internally for about a year, then release it publicly publicly just to see how it would be seen from the outside world. We got kinda lucky in a sense that Jamstack was exploding and Netlify and Gatsby were taking off. And there were like in an industry analysis analysts like Gartner, etcetera, really pushing everyone towards this architecture.

So we we rode the wave, but it it wasn't like an an overnight success by by any means. I was the only one one working on it for at least two years and and part time while keeping my CTO job at the agencies. At the agency, it took like four years to reach like Raman profitable level. And the company wasn't actually even funded until 2019. So It was like very slow.

And then in like 2020, everything started to accelerate beyond our control, honestly. So we went from ramen profitable to around, like, €1,000,000 in revenue, think, in a single year or something like that, and with just three people working.

Wow.

So, yeah, now we are 13 people. We are fully remote across Italy, Germany, and US. Now we're doing, like, €6,500,000 in revenue. We're handling like 3,000,000,000 API calls a month. And with a lot of agencies, like 200 agencies using us regularly and still not making almost no marketing.

So it's basically all word-of-mouth. People use it, like it, and tell others. And, yeah, that that's the short version of the story.

That's wild. Why why do you think it took off? Like, why did it take off in that, like, 2020, you said?

I honestly, I've not no idea. Like, it was like a mix of things that we couldn't control. Like I said, it was the whole IT system going towards this kind of architecture. We already had like a pretty solid product. So we were like in the right spot in the right time with the right product.

And there wasn't too much competition at the time around this sort of solution. And also like Netlify, etcetera, they really had to like, showcase use cases that actually prove that the thing was working. So they really they really liked having, like, us, for example, showing how to integrate, how easy it was to integrate with them. And so basically, use their marketing efforts also to promote ourselves. And it worked it worked, like, really well for a long time.

First, petrified and with Gatsby, which it didn't go that well for them. But they were they were, like, huge at the time. Yeah. Everyone was talking about them. Yeah.

We had we had a a working integration. We we integrated with our cloud system, etcetera. So

yeah. Yeah. The whole the whole headless static web space was growing. So I feel like all the headless CMSs were growing at the same time. And so the the pie was growing for for everyone and we had our share that was growing as well with everyone else.

I feel like it was a was we were lucky to be at the right spot at the right time, and and and the product was was solid. And so yeah. We still have a lot of customers from twenty twenty, twenty twenty one, and they're still customers right now. So it's impressive to see.

Scaling DevTools is sponsored by WorkOS. If things start going well, some of your customers are gonna start asking for enterprise features. Things like SSO, SCIM provisioning, role based access control. You could spend ages tearing your hair out, building these things yourself, or you could use WorkOS. Will, what do you guys do?

My name is Will Stewart, cofounder and CEO of Northlink. We're a self-service developer platform, and we help teams deploy their most critical workloads into their VPC. And you guys use We use WorkOS for our SAML and OIDC integrations. It's a pretty exceptional product. It makes everything regarding authentication pretty seamless, and, it's been instrumental for us to onboard our enterprise customers much faster.

Yeah. It's a great product.

WorkOS helps your DevTools start selling to enterprises much faster, and they're trusted by DevTools like Cursor, Fowl, and Vercel. If you use their user management all, you can get your first million monthly active users completely free. Why do you think people were choosing to go with you at that time? Was it that the tight kind of integrations and stuff? Do you think that was the the drive for people?

Yeah. Probably, we had very good integrations, as Stefano was saying, with other players in the headless space. And I feel like that was very, very useful. And also, think we were more approachable than the competition in certain surely as a company, being a small company, they were speaking directly with us at the beginning. So I feel like, especially in when you don't know very well how things work, how they integrate, being able to speak directly with the people that that can take decisions and and make stuff is very reassuring.

So people were asking features and we were developing features in like a week. I think we we we acquired many customers, like, being very approachable. We were cheaper than the alternatives as well.

That that's also part of the equation, I think. We were really cheap, and we could afford being cheap because we were small and we didn't have like to necessarily have huge revenues to be just to have some margin. It was really easy for us to just stay in the business. And maybe others, other competitors were trying to figure out how to maximize the revenues, maybe picking bigger clients. We just focused on the small fishes, to be honest.

This is like the target that we feel like we are most connected with, both of us coming from small web agencies. So we really know that market quite well, I think. So we can put we we we know how they think. We know, for example, that price is a big thing for agencies. They need to resell the the product they they're choosing.

So they have to convince also other people. So price is always like an important part of the equation.

Yeah. And I like a lot of DevTools don't talk about because I remember studying at university, there was like free state they're in the textbook. There's like three ways you can have a strategic advantage, I think, competitive advantage. And it was like, you either have like quality, like you're the best, or you have focus. So like you're really niche down.

And then the third one was cost. And no one there's, like, very few DevTools that really focus on cost, I feel like, even though it must be you know, if you can get if you can serve it at a much cheaper price than everyone else, it's like depends what it is, but a lot of people could go for you. Right? I don't know. That's

Yeah. Yeah. Yeah. It's a it's a combo of having a, like, a good product that fits like a niche market very well. So you know the surrounding area around the product.

You can offer it at a cheap price. You can afford to leave money on the table. So, yeah, that and we also like always try to offer like the best support possible to any tier, like even free. Still now, basically the quality of support that you get, it's it doesn't it doesn't matter where what what your plan is. We you're you're getting exactly the same quality of responses from us.

Yeah. I I was think especially at the beginning when the the headless concept was was new, having this kind of support where we helped our customers also develop their own code base. We were providing code integrations, especially for for their own solutions was was very helpful. We were really trying to to go as far as possible in helping them out. Yeah.

Also, was simplifying the product as much as possible and optimizing developer experience.

Yeah. I think we spoke on the previous call about simplification and there were you were talking about how you do it and how, like, it does come with, like, you have to make sacrifices for simplicity. Could you talk a bit about how you how you've been doing that?

Yeah. I mean, not not necessarily sacrifices. I mean, you you have to be, like, consistent and know what you are doing. Like, for example, we know who we are. We we like building products, not building like shells or businesses.

We we like doing things, doing building great products. And we like to stay small because we believe that the more the the bigger you become, the more boring the work is for everyone basically. So they're not necessarily like cons for us. This is who we are and we try just to do our own thing. And for us is like trying to be as simple as possible, make stuff for yourself, keep your costs low low.

Yeah. That that's basically it for us. And I know

for sure that there are a

lot of other ways to build a business and not every kind of business can use our this strategy because for example, you might need like huge investments before even starting building something. It depends on the context, but there are a lot of areas in which you can build something and keeping these rules and and, yeah, and building something great without even wanting to have like an autistic growth. That also is not our thing, for example. For sure you need like to take off at a certain point, But then it's it's totally fine for us to just keep being in orbit, you know, for fluctuating a bit high or down and try to just not not to fuck things up, like becoming bigger, making things more complex in software. You can basically keep building things.

There's not like this physical quality to to to it. So it's it's very easy to to make think things complex. So you have to be aware of that, I think.

And maybe something it was something we we mentioned before, and then I I feel it's useful. It's been useful guide for us is always to to ship when we are also a bit uncomfortable with the with the result, like, not being perfect, not being completely finished. We we not not by saying and we're I'm not saying that we are shipping stuff that doesn't work or it's partially finished. It's just that we we we think about the feature as as possibly omitting parts of larger feature that could if you think it abstractly, you can say, yeah, it would be nice to add also that functionality, but maybe it's not the core of the functionality. So we try to avoid adding it until someone expressly asks for for that feature.

And then and then some we have discovered over and over again that that part of the feature and that it was not the core. Nobody was was asking for it. Nobody was using it. And so in the end, we said, okay, cool. Let's do it.

Otherwise, people were coming in and asking all over and over again for the same feature and said, that that's useful. We we should do it. Like, for example, stupid stupid thing that comes to my mind is we we have a feature where you can create new environments which are like copying copying the entire content and you couldn't rename the environment. Once you gave it gave a name to your environment, it was fixed forever. It stayed like that for months, years possibly.

And then at some point, yeah, maybe we should add the possibility to rename the thing. And then we added that and it was like a very basic thing, but just avoiding the UI to change, rename, simplify it as much as possible the the feature. And so we focused on the on the core functionality and left everything else for later. It pays off more often.

We're using to help help us with that, we we're using the Shape Up methodology, which really helps a lot, like, thinking in terms of fixed constraints. So you are like six weeks to start working and then shipping the actual feature. So you have to you have to do some you have to sacrifice something in order to ship that thing in time. Otherwise, it's just be it would be basically crushed. It won't go online.

It won't be restarted on the next cycle by default. So the idea is that you you either ship this thing in time or we'll think about it or and it might not even ever be published. And the same goes with feature requests, issues we get, etcetera. Like, there's like this huge burden, mental burden of of of keeping like this infinite backlog of small tiny requests or small fixes. And these things pile up over time.

And every time you have to choose what you want to work on, you have like to mentally rethink about all of them. And that's a lot of wasted time in our experience. Like the common requests will keep on being repeated over and over by people. We can just and this methodology is built around this idea. So every six weeks, we decide to work on some pitches for some ideas.

And we start from scratch every time. So it's not like we are reworking, rereading everything that we thought maybe two months ago that that was a good idea. Let's start like fresh every six week. And if someone something really matters, it will be surely present in our minds when we are deciding something. And then the rest can just basically go away.

We can just forget about it and and live better lives.

Yeah. And wait. So you you said that, like, stuff goes in the bin if it's not finished in six weeks. Does that, actually happen? We didn't throw

it away. But, yes, we we stopped the pro our project. It happened once. We said, okay. Let's let's pause.

We had planned for something else, and so we did that something else first. And then after after that, we finished the feature. But we plan sometime again for that particular feature. I think it helps also the whole company synchronize and say so we can say, okay. Because because since we we have one code base, we need to say, okay, one person works on on a certain part of the code base, someone else on the other part.

So we need to plan features so that they everyone can slot in in their place. And so if you don't finish something, could potentially not fit the next cycle. And so, yeah, we had to pause it until we had time again and and pick it up again.

Yeah. But it's even if you then, like, try to work on that thing again, it's still very valuable for everyone in the company to just know that that's the default. Like, you set the mindset of everyone towards, this idea that you need to finish the thing you're working on in the specific timeline we decided. And that helps a lot, like, really simplifying things along the way. The the the pitches of the projects we want developers to work on are, like, not too detailed.

And that's by design because once you settle too many details, then the developer has actually to implement all of them. And there that's not much room for, like, freestyling along the way. So you keep the general idea very clear. We we set also you also explicitly write what this pitch is not about, for example. That's very important, like excluding things, explicitly excluding things, and that really works.

And what what kind of things, for instance?

Well, it depends on the pitch, but during the design process of a pitch, we try to really specify what this thing is and what it's not, what could be interpreted as. And so we try just to keep it really straight that what this thing is so that also the the six week timeline can be can be doable for people.

How big, like, would the six week target be? Like, what kind of things would you build in six weeks? I guess, like, what what kind of ones have you done recently?

For example, we are planning we are planning the the next feature that we are working on. So so we are spoiling the next feature is pro no worries. We we are we're aiming to implement dark mode. So for example, dark mode is is a big project that will will be done in six weeks. And probably in the spirit of sacrificing something, we we already know we have some possibly rough edges, like we have a plug in SDK that has been used in the past.

And there will be some migration needed from our customers having that have built plugins. So probably, there will be some plugin maybe that's used by many people that will be still with the old UI, whether with the not dark mode, will be left out, possibly. So this is one, for example, one specific choice that we'll we are making. Okay. We we we know there will be some plugins that will be on the old UI.

That's fine. We have a plan. We have a big picture of where we are going, but we don't know exactly all the views. I I'm fine if there are some weird corners of the UI that are not going to support dark mode to begin with. It's gonna be fine.

It's a sacrifice that I'm very happy to to make, for example, or not be perfect. So we have we have thought about all the possible gradients and accent colors and whatnot. But maybe some we we cannot go into the perfect detail for all the UI elements, and that's fine. We will note that down and maybe every between every cycle, there is a cool down period in which we can refine previous tasks or do small improvements. It's more it's more free.

It's more unstructured time. And so we can leave something for for later and pick it up again. So that's one specific example.

Super cool. One thing I wanted to ask you about that you mentioned before is, like, kinda keeping really lean, like, how you've been able to do that. And I know for instance, you mentioned about, like, suppliers and stuff and, like like, how because you guys have been doing a lot with a small small team. Like, how what are the key things that have been made that possible?

Well, we are trying to focus just on the core product, and that's it, for example. So everything that's not core, we try to delegate to someone else and just pay whatever they asking for. And that applies, for example, for to our image CDN with all the transformation, etcetera, for the, all the video streaming integration we have. These are all existing services that we just pay as customers. And we basically offer to our customers inside the our regular price.

All the infrastructure has been on Heroku, for example, since last year. So we basically had very small maintenance burden alone around the whole infrastructure, security, etcetera, was all delegated to someone else. It's really important. Like you have like, right now I think we are, we have three and a half developers.

Three and a half?

Yeah. One is for yeah. And that's it's a huge surface area for Yeah. I mean, we have, like, integrations with every possible framework. We have the Yeah.

As Matteo talked about the plugin SDK, we have our own interface for the studio where you edit content, you have all the APIs, GraphQL API, REST API. You really have a lot to work on. And you build over time. I mean, it's not like if I tell you this now, it seems like this huge thing. We just kept working with consistency over time and kept adding new things, trying not to complicate too much.

And it's ten years of development. So we never did like a huge rewrite of everything. We never did anything that could jeopardize the whole development department for a long time. Yeah. We try to do small things, but consistent consistently and it kinda works.

Yeah. Yeah.

If you see screenshots of the first version of the UI, it's very, very simple. It lacks many features that we are we have now, but the idea is the same. I mean, you recognize the product And the product was simpler. It was cheaper at the time. And so progressively, it got more features, more complex, more functionality.

And so we raised the price accordingly. Now we can have enterprise customers are happy and stay with us for years, but it's been it's been a, like, a long process to get up to

where we are now. Yeah. And we don't offer, for example, on premise installation. We try just to have one product to to work and maintain over time. And we used rails to start working on the product, which is already a huge help.

Like, you don't have to reinvent the whole thing at the beginning there's more more uncertainty about the future of what you're building, for example. We still basically just use Postgres for everything. And DataCMS is a product that has to work with free schema content, like every record has its own schema. So we tried working with that. Let's see how much we can get with just a single Postgres instance and JSONB columns.

Turns out it still works.

Yeah. That's crazy.

That's crazy.

We we

added yeah. We added, like, starting over time, of course. But it's still just a a posters instance, and that still works. Microservices, no, no fucking way. We cannot afford that.

How can we afford that? You have to be lean. I mean, three and a half people, you have to be lean and you'll find That's so cool.

Yeah. Honestly, Postgres is so impressive how fast it can go and with the complex queries we are sending it, it's really impressive product.

Yeah. What happened after Heroku? Where did you where you where is Dato now?

Yeah. No. We moved to AWS. So we are managing our own Kubernetes cluster, and we moved everything in there. So it's been a project of last year.

Yeah. But we are using the managed Kubernetes service by AWS. And the Postgres database is a managed one by AWS. All the managed stuff that we could use, plus the application is managed by us. We did a small CLI tool to manage the Kubernetes deployment.

Yeah. And that's it.

Yeah. And and by the way, we would have never switched to anything else unless Heroku was really like going south. Now they're basically officially retired in maintenance mode. But it was like you could see from from the outside that that was the direct direction. So basically, made the switch last year.

But if everything worked, we would probably be on a Roku still now.

That's wild. Yeah. That's so cool. So so simple.

Yeah. I mean, it's a it's a lot of money you you maybe give to Iraq, but with 13 peep 13 people and 6,500,000.0 in revenues, that's like half 1,000,000 per employee. Yeah. It's not like that much of a of a cost. So you just focus on what matters and leave the rest to the to others.

How big was your do you mind me asking how big the Heroku bill was getting towards the end? Just for curiosity.

I think it was something around a 150 k per year, something like this. A bit more probably. Less than 200,000.

Yeah. And I suppose if you'd have run it all yourself, maybe it would be like would it be like an order of magnitude less? So you kind of think No.

Not not an order of magnitude. It's like half.

Half. Yeah. Mhmm. So

Yeah. I think I think now we are doing more than before and paying a bit more than half, I would say. But like it's there's no performance, there's no comparison. It's like so much faster.

It's faster Yeah. Than our

Yeah, yeah, okay. Significantly faster. Yeah. Databases are like half the size of the ones that we had before. Web servers are, I think, at least three times faster.

It's mind blowing.

Wow. Okay. So it's good. Yeah. Okay.

But then I guess it's like how it's like some work to manage it, I suppose. So yeah. Or it's

still Yeah. It it was some work thinking about the migration. It was like a pretty

scary

project for us. But now that the migration has been completed and with like, I think five minutes of downtime. Five minutes. Yeah.

We we had, like, something we didn't think about. Right? Otherwise, it was good.

Yeah. I was gonna say that's not bad. Right? Did I have to switch switch to take effect?

Yeah. Now the maintenance is basically like we did before. Maybe a little bit more, but it's not it's not significant. We'll see how long it it lasts. I mean, we we are we are open to changing something or spending a bit more time on the infrastructure.

But for now, it's it's good. It took, let's say I would say it took more or less six months of a full time person. So something like this, the equivalent, a bit more probably.

Yeah. And then six months of your life when you you ran the migration role of this?

No. We did it we did it so many times.

Okay.

Yeah. Maybe maybe that's that's useful for someone to know how we did. I think it was it was pretty chill at the moment because we have like the CDN on top of everything. And on the on the edge workers, we we started duplicating the the the traffic to the Heroku infrastructure and to our new infrastructure, so we could load test everything with the real traffic. The new infrastructure was read only, so you couldn't write on the database, but you could feed.

And we sent all the traffic also to the new infrastructure. And then we deleted all the data and do ended it again. We did it like three times so that the machines were correctly sized. We knew the database would have had like some time to to pre preheat. So it was before it was going as fast as we we wanted.

And so we knew how what what was gonna happen when we diverted traffic from the old infrastructure to the new one. We kept read only everything for for some time to so that we were comfortable. And then at some point, we said, okay. We're good. Let's start writing on the new infrastructure, and there was no no way back at that at that point.

But we tried like three times before. We had all the commands written like a mega checklist with all the steps. We tried yeah. We tried three times. We were we were quite comfortable at the moment.

And so we knew what was gonna happen, like the spike in the database load at the beginning because the cache was warming up and everything went like we did it before and so it was quite chill actually.

Yeah. Okay. Cool. That's awesome.

Yeah. Yeah. No. Not not too stressful at the moment. We were all the in the same room.

We we took the the we stayed in the same office at the for the migration. So that was also good. We had some coffee and croissant, and that was it.

Nice. Nice. No pizza. Like, was imagine, like

No. It was

early early

in the morning.

Okay. Yeah.

We should have had pizza as well. Was it a bit more cliche? Yeah.

Yeah. Yeah. Yeah. I was gonna say, like, because, you know, I feel like when people are, like, working late and stuff, it's always, like, you know, get some pieces there. Like, would you guys still do that in Italy?

Like, would that still be the go to if, like, it was Yeah.

Sure. Sure. Sure.

Yeah. Of course.

It was early in the morning because it's it's the best moment for our customer base. We have we have some people in The US and some people in Italy. It was like a Saturday more early morning. And so we had we we had we also said, okay, if it's not working, we'll try again on Sunday morning. So we had like two two tries, let's say.

Everything went went fine on the first try, so it was good. Better, though. We had Sunday to relax.

Yeah. Oh, yeah. Yeah. That's that's cool. And then I think the final thing I wanted to ask you about is like, kind of trust.

You're talking a lot about like, when we spoke before about like, doing the like the right thing by people and stuff and like kind of trust and like how you how you operate. Stuff like refunds, things like that, like how how you guys operate.

Yeah. May maybe I can I can say something? I think we we have we we trust a lot each other in the company to begin with. That that also helps a lot in being small and fast and lean because we we delegate a lot. And and between us, there's not much infrastructure to be built around everyone else because we've been working together for a long time.

Also, before Dato, we started university together. Between me and Stefano, there's surely a lot of trust, but also with with everyone else in the company. And so that that's helpful. And also with customers, something we we try to to do is is to be very transparent to avoid being very complicated. And as, for example, if we mess something up or if there's something unclear with the billing, we prefer, like, to say, okay.

That's fine. We weren't possibly we weren't clear as the problem was was us and then we weren't particularly clear with something or there's unexpected spike in traffic and that's possibly caused by spam bots or whatever. We don't know. We we don't maybe have enough data to prove everything. That's fine.

We prefer to just refund, offer some credit as a goodwill gesture and and move on. I think it's also how I would I would like companies to behave with me. And I would like the companies to be straight and then just go to the point help where when I'm in need and and not overcomplicate the commercial part and the support part, and that's what helps us also move fast with with many customers. We support, I would say, around between 1,502,000 customers, and we have two support people at at the moment. So and that that's also how we can we can do that.

Like, just simplify also how we talk with people.

Yeah. We definitely prefer like to leave some money on the table. If it means like closing deals faster, make the customer happy. It's another superpower of like being small with high margins is that you can afford these kinds of things. You don't have like to go up in the chain of responsibility, two layers to ask permission to do something.

It's everything becomes quite easy and clear. And that's really appreciated by people, like, especially now in the time, this particular time we're living where AI is like everywhere, you cannot trust any anything to be really written on or said by humans. It's those things that give you like, you know, the the idea of that that that's there's something there's someone real on the other side.

Yeah. Jumping in five minutes call with a customer that has a problem. We you are exchanging a few emails, and then you feel like there's a bit of a misunderstanding or annoyance, just let's jump in a call and sort it out. It happens so many times and it happens still still now sometimes. I'm very happy when customers ask for a quick call and very often I'm just there, Okay, yeah, let's do it right now, like a quick call and we sort the problem immediately and everyone is happy.

We we sorted out a problem that otherwise would have lasted. Who knows how many emails and and the customer is also happy. So then it's got the problem sorted immediately.

That's cool. So do you suggest you suggest it? You just be like, you wanna here's a Zoom call. Like, is it maybe I'm overcomplicating this. Is that Yeah.

Pretty much

what Yeah.

Yeah. Yeah. That's it. Yeah. We just send an email.

If you prefer, feel free to let let's have a call. I'm available right now or book book a call with me whenever you prefer or carry on via email if you if you don't like having a call. It's also fine.

It's very cool. Sounds, like, obvious. It doesn't sound like but I feel like people are not I don't know. Yeah. It's kind of surprising, nothing that's happened to me.

I I think I think it's very difficult to to have a call with, like, the the product manager of whatever software as a service you use online, right? Instead, you just send an email to supportdatacinis dot com and you ask for a call and that's it. But if you treat your customer with respect and you feel like they know what they're doing, they won't waste your time. It never happened to me since it's like seven years now. I'm working on Dato.

It never happened that people just booked a call for no reason and wasted my time. It's like, it's normal. I feel like it could happen. I wouldn't be surprised if it happened. Would say, that's fine.

Once in a while it can happen and That's not the problem. I mean

Yeah. You suddenly, you get loads of calls. It's just like, who's your current inference provider?

We we'll see. We'll see. I might be wrong. I don't know.

A new CDM provider. Someone's listening. It was like yeah. Okay. This is awesome.

Is there any kind of, like, closing thing that you would say to other DevTools people if you have, like, one one kind of big lesson that you've really learned along the way?

Yeah. I mean, for me is the idea that you should try to stick with what works for you. I mean, there's a lot of talk on VC funding, for example, or any other established way of making businesses and building products. And it's I feel it's quite important to try to stay who you really are along the way. Just it's not there's not only one way to do things and try to be very clear with yourself in what it's important for you.

For example, you like working with a small team. That's totally fine. For example, you don't have to grow adult costs or whatever is your thing. I mean, there's a lot of ways you can build a sustainable business. Growth shouldn't be chased at all costs.

Nobody is forcing you to do that. And you can really build something that matters to you and to other peoples without, like, following other other people's rules, for example. Yeah.

Yeah. Maybe just a little addendum is is also since the beginning, we we never did crazy hours. And I feel it's very important because it's it's a marathon that you're running. It's not like a sprint. So it pays off being it pays off more being consistent and being there every day and improving every day a little bit rather than just running fast and then being burned out.

So it took a long time to to get where we are right now. And I feel like if we went faster, we wouldn't have been where we are right now. And there's also luck every time. So there is no there is no secret recipe, I I think, at the end.

Yeah. I I think it's really cool. And it seems like you guys are having an awesome time, and you're you're doing really well, and you're having fun along the way. And, yeah, it's it sounds really cool. Sounds like yeah.

I know Ronak. So shout out to Ronak for making this happen. And Yeah. Yeah. Yeah.

Seems like he's out of the time of his life over with you guys. So Yeah. People wanna learn more, where can they go?

Oh, of course. Datocms.com. That's the website. Yeah.

Awesome. Well, thanks so much, Matteo and Stefano, and thanks everyone for listening.