MarsBased podcast - Life on Mars

Generalist or specialist? Inside our biggest business debate: Building MarsBased #4

• MarsBased • Season 2 • Episode 109

Share episode

In this episode of Building MarsBased, Alex Rodríguez Bacardit, CEO and founder, discusses the internal debate of whether the company should operate as a generalist vs specialist. This conversation offers key business tips for how to start a business, emphasizing the need for strategic thinking to foster business growth. We explore the essential elements of a sound business strategy for long-term success.

Support the show

🎬 You can watch the video of this episode on the Life on Mars podcast website: https://podcast.marsbased.com/

SPEAKER_00:

Hello everybody, I'm Alex Sio and founder of Martspace, and in this episode of Building Martspace number four, I will be discussing the internal debate we had of whether to become a generalist company on the one side or a niche company. Before I start, a few considerations. First off, this particular episode might make more sense if you have been watching the first three episodes in which I cover the start, like the starting years of Martspace, the origins, uh, what problem did we want to solve, and our personal background and professional background as well. Right. So, for those who just come to this specific episode, um, we are a software development company. We've been running for almost 12 years. We're founded in 2014 in Barcelona. Even though we are 100% remote, the three founders come from Barcelona. We decided to start this company as a result of frustrating past experiences. Uh in the companies that we were working at, we're not extremely satisfied. The way we did our job, the way the company uh behaved, their company values, the outputs and the outcomes of their projects, or the methodologies that were being used, or even the company culture, right? As a result of that, we decided to create Mars-based. And one of the very first big problems we had to tackle when we created the company was to define our positioning in the market. Because at least in Spain, pretty much every single agency, consultancy, or studio out there is a generalist. A generalist company that provides services is a company that offers a wide range of products or frameworks of solutions or services, right? It can be a software development. If we were a generalist company at Markspace, we would develop in all of the conceivable or most of the conceivable programming languages. We would do Java, we would do C sharp, we'd do.NET, we would do PHP, Ruby and Rails, JavaScript, we'd do native mobile development, would go into ARVR, would do all sorts of development, but as well, we would be doing other services like providing marketing services or maybe content or PR or you know or also integrating lots of tools that are available in the market, like SAP, Salesforce, CRMs, ERPs, what have you. It is very tempting when you start a company to become one of this, because you have no clients. And the fastest way to acquire clients at the beginning is to basically say yes to a lot of things. That is a short-sighted route, but I'm gonna go into much more deeper detail a little bit later on. So if you find the generalist companies on the other side of the coin, what do you have? The niche companies, right? A niche company is a company that offers a very, very limited set of services or technologies because they know them best. They master, they excel at these technologies or services, and they want to focalize market to a specific target audience, uh, go to specific kinds of conferences, go to hire specific very specific kinds of people and profiles, and be able to sell a somewhat higher rate per hour because of this excellence of this or or these accumulated expertise and know-how, right? You're better because you cover less ground than a generalist, therefore you have to be more expensive because you are a you're not a jack of all traits, you're a master of your own trade. So, generalists on one hand, jack of all traits, masters of known, on the other hand, the niche companies, masters of very, very few traits, but we really go into very deep detail. So, when we you know, as I mentioned, it is very tempting at the beginning of the company to become a generalist, because when you have no clients, the first one that gets even remotely close to being your client, you are attempt to say yes to whatever they want to do, right? At the beginning of Marspace in 2014, when we were defining our offerings, we put on the table all of the capabilities, skills, and strengths that the three founders, the initial team, had. And basically, we had on the one hand, we had expertise in creating websites and designing websites. That's what Jordi brought to the table. Um, we had strong full-stack development in Ruby on Rails and JavaScript. That was what Xavi brought to the table. And I was more like a consultant or Java developer in more enterprise kind of projects, right? That was that was a very hard decision because I could bring in my own deal flow because I had been in an industry very Java focused, very enterprise, but we didn't have the company structure required to support these kind of projects. And also we didn't really want to do Java. I mean, I wouldn't have minded, but um, at the end of the day, we decided that we want to do something that allowed us to iterate and develop very fast. Um mostly because Xavi and Jordi were working on the weekends when we started the company. So and I I wouldn't be developing, therefore, my expertise in Java was basically useless in this kind of company. So we decided to go for Ruby and Rails on the back end, Angular and the front end, mostly because that's the technologies that Xavi was developing on. We also started developing and designing websites for people. And luckily for us, we only did it a couple times at the beginning of the company, uh maybe a few projects, because we realized early on those were not the kind of projects that we wanted to have in the company. They were basically projects very limited in margin, and they required a lot of adaptations and iterations for a very small price, and we we had to sell lots of them in order to turn a profit at the end of the month. So by sticking to bespoke development, Ruby on Rails and Angular, we defined a very strict and specific tech stack that allowed us to go farther, and that is counterintuitive. Let's see why. You would think that by adopting a tech stack that is more popular or with a wider market adoption like Java or PHP or some other technology, um, we would have had more clients and you would be in the right. However, those were perhaps not the kind of clients that we wanted to work on. We wanted to work on bigger projects, not smaller projects. We wanted to work on projects that they were kind of like fast to iterate, get to an MVP relatively easily. And these kind of projects were best done by somebody like a full-stack developer like Xavi and um working on the weekends and on the night shifts after his regular job. And we couldn't do it as well with other technologies. Ruby on Rails basically was Ruby on Rails, Angular not so much, but Ruby on Rails was the kind of technology that allowed us to do that. So therefore, we decided to focus specifically on this. Even though at the beginning of the company, we received a lot of project requests with other technologies. Some Java, some PHP, some WordPress, some C. Off the top of my head, maybe one or two.NET, maybe some like commerce uh relatively a relatively interesting amount of sales force bespoke development, but we turned them down. Like it would it would have been great. Also native development. We didn't do native mobile development, we didn't do it at the beginning of the of the company. We knew it would be interesting, but we wanted to focus on doing only one thing and do it right. Why? And that is the key part to this question. The central point of this episode is it really boils down to what your core values are. In our case, when we decided that our company culture would be based on quality over quantity and specialization over being a generalist, and simpler is better, it wouldn't make a lot of sense to be a company that offers 10,000 different technologies and services and frameworks and libraries. No. Like we wouldn't achieve specialization or the simpler is better or the quality over quantity with a super vast technological stack or um uh or the the stack of offering of services. So by offering just one thing, bespoke development, web development in Ruby on Rails and JavaScript, we were covered. Maybe we left a lot of money on the table of all the projects that we didn't take. We could have, in the first year, we were approached by Rakuten, for instance, the giant uh Japanese company, and they wanted us to do some mobile development for them. And we turned graciously turned them down. And they told us you're the first provider that says no to uh one of our projects. So thank you for the opportunity. But by accepting this, we're taking a lot of risk. We don't know whether we are the right company, we don't know whether we can deliver the quality that is expected of our company. And therefore, we referred that deal to somebody else, to another specialized company in our orbit that's called Brains and Beards, that they did only that. So they had the same approach to quality and to being super laser focused on something, uh, but with different technologies. Therefore, we could complement each other very well. So that those initial projects that we turned down actually helped us to build the reputation of a company that is not only niche, but is quality and takes extreme care and agency and ownership of the projects that they work on. And the CTO of Rackiton at the time, after seeing how we behaved in this project, he then went on and hired us for five other companies throughout the lifespan of Marspace in these 12 years, right? This person is Sergio Gago, he's been a couple of times in the podcast, maybe five times already. So um he he liked that and he says he doesn't come across a lot of companies that do this, and he appreciates the honesty, and um and he then has you know been successful with the other project that we have been doing for him throughout the years. So if you want to build yourself a reputation, if you want to stay strong to your core values, and if you want to really walk the walk and not just talk the talk, this is what you ought to do. You have to choose your technologies, you have to choose um what's your niche, or if you're okay with it, go the other route, which is become a generalist, say yes to pretty much everything, and you can also grow very beautiful, healthy, profitable, and likable companies, right? But that's that's just not our style. That's why we decided to pick this, this um this way, the Marspace way. In fact, I remember that at the beginning of the company, uh some of the some of our colleagues in the industry, they wanted to work with us and they wanted to hire us, but we were most of the time turning them down because, oh no, sorry, we don't do this, we don't do that, we don't do native mobile development, we don't do PHP, we don't do Java. And um, and I remember a good friend of ours um who said, Look, guys, you're never gonna get hired. I don't think your company is gonna take off if you say no to everything. You are 100% remote, so you don't do in-office work, you're more expensive than your competitors, you only do Romian Rails and you only do web, you don't do mobile, right? And you don't integrate other solutions like SAP or or WordPress or Shopify or Salesforce back in the day, right? Or LiFree for all that matters. Um and I still I have this these words, they were really set in stone in my brain, and I was thinking, we're gonna make it anyways. Um luckily for us, I think that by choosing this this tech stack and committing to these technologies and to this specialization, it actually panned out really well for us. Why? Because the very few projects we got at the beginning, we did them and delivered them in time with a very high level of quality, and the clients became so happy with us that they gave us even more work in turn. And they refer us to other clients. And so because we were able to raise the bar on our requirements and our expectations, that translated, that transpired into the work with it. And therefore the clients perceived it and appreciated it and got the value out of it. Had we gone the other route, things would have been entirely different. I don't know. Maybe we would be in a similar position. Maybe we would be a company of 100 people right now, maybe we would be only 10. I don't know. I cannot tell you how would that be, but um, I'm pretty sure that you can learn from other companies. So basically, by uh by choosing this initial set of technologies, also we knew that at a certain point in time in the company we would have to open up this tech sack and maybe start doing other technologies. And this is a very tricky and difficult decision because first off, you don't want to open it too much too early, because then you dilute what you're offering, your value proposition, your expertise, your skill set, and even the way that you're able to coordinate all of these projects inside the company. Say that if you got a team of 10 and everybody's an expert in Ruby on Rails, and you start getting projects for Python, you say, like, oh, you know, it's not a far cry from Ruby on Rails, let's start doing Python. But there's only one person in the company that knows Python very well, you will not be able to satisfy that demand. Or worst of all, you will jump into the projects with this label of being an expert, a boutique, quality and whatnot, and you will do a mediocre job, right? I I I'm not saying you will do a crappy job. Chances are if you're good enough to be a quality um boutique company, you're most likely going to do that decent job in whatever other language, but you will not be the best. And therefore, you will not be perceived as an expert in that technology. And maybe they will the client perception, if they don't know you, will be, oh, these guys they say they're boutique, but they are really not. Look, they did a like a subpart job. Somebody else or my team would do it better. You don't want to do that. At the same time, you don't want to open up your tech stack too late. Because if you're growing the team and you are not diversifying in technologies, then you're not listening to the market. And you might be the strongest Ruby on Rails company in five years from now. And if Ruby on Rails, for whatever reason, stops being popular and loses its market share, then you've got 50 people that you cannot put to work in other stuff because uh all of a sudden everybody works with Python and JavaScript or Scala for that matter, and you're out of business. You don't want to do that. How did we do it? In the case of MarSpace, we started opening this up only when two things happen. First, is we had a client that we already knew, that we had been working on for some time, not a lot of months, but we already knew them. We were in their systems, in their tools. Um, we could have an honest conversation about the risks that would entail going into technology that we're not an expert in. And that technology is somewhat adjacent to what we want to do. Let me give you a few specific examples. The first time we went into mobile development, for instance, a very good friend of mine um hired us to do a project. It was a web-based platform for an HR agency. And we developed the web part of the project with Ruby on Rails. It was a pure Ruby on Rails application. I don't remember whether there was some JavaScript in the front. I think not. I think it was pure Rails, full stack. And while we were discussing how to solve a certain very specific set of problems they had with the uh it was a platform basically to do the matching between some jobs they had to do and their workers, right? And they had like thousands of workers that they had received an alert every morning saying you're going to work here, you're going to go work there, you're not working on the shift, you're going to be working at night, or you skip today and see you next week. And we thought that the best solution for this project was a mobile app. Because most likely these people, they would be on their phone while they received the notifications. They would not be using a they will not carry the laptop around. So we approached the client and we said, look, the solution for the problem that you have is a mobile application. But we don't do mobile applications. Therefore, we cannot, and we will not do the project. And the client looked at us at the eye in the eye and said, like, no, no, you're gonna build the project. I trust you. No matter what, I want you to do the project. And um, I I I will not look for another agency. So we had an internal meeting. Chavi Jordi and I, and the three founders came together and said, Look, I mean, if there's a time to start investigating or dipping our toes into the waters of mobile development, we might as well do it with this project because it's a client that we know. We are already building the web part of the project, therefore we'll get a bigger project as a result. And mobile, you know, that was year 2016, 2015, 2016, so one year and a half, two years after we created the company. And we knew mobile wasn't going out of business anytime soon. So, you know, we could build this particular project with uh Ionic at the time, so hybrid development, non-native development, that would have been a different animal, and we wouldn't we wouldn't have done it, to be honest. But Ionic, you know, experience with Angular, Cordova is not a far cry from Angular, uh, lots of similarities. The promise back then was if you know this, you know that more or less, you just need to adapt. The reality was a little bit more complicated than that. But the project went pretty well. So after that project, and it went well with Oliver in time, with the expected quality results, we learned a ton. We did a few more projects in mobile. There was a second specific example that was when we decided to integrate Node.js into our tech stack. Um that that was year 2017, end of 16, beginning of 17. A client approached us, or a potential client approached us to do some HTML CSS projects, um, you know, um, some redesigns, some UXUI, and we started working on the project. When we we were like a couple of weeks into the project, they said, uh, by the way, guys, this is in Angular. I've seen on your website that you also do Angular. Can you help us with that? I said, yeah, fine, sure, I will do it. So the project grew a little bit. And uh three months into the project, the client said, uh, look, we really are in a bottleneck right now. We could use your expertise in JavaScript. Uh our backend is in Node.js, could you do it? And we said, no, because we don't do Node. But let's discuss it internally. It was a big client, it was a pretty big consultancy firm. Therefore, it was in our best interest to work on that project. So we decided, look, uh a couple of people in the company, and that's something very important as well, had notions of Node.js or had to work with Node.js in the past, so we wouldn't be beginning from scratch. And we said, look, if we if we get the back end for this project, we will be the owners of the entire stack, right? So not only the design UIUX, but front end and back end. And that is very important because this is a long, long project, a big fucking project. And we could even increase the team. We had one person working in the team, then we would have like three or four people working in the project at the same time. So we went to the client, we had the very same honest conversation about like, look, we don't do this technology, but we're willing to explore it. For a few months, we'll be charging you um a discounted fee. And that's something that we, by the way, we did also with the previous project, but I failed to mention it. It just came to my mind right now. For a few months, we decided to reduce our fee with that particular profile, say be uh on the excuse that we were not an expert in that technology. And therefore, they all they they decided to split the risk. That was a good way to split the risk, and um, and we got at the project, right? And so we we we we worked for that company for like four years or something like that, and it was a very, very good decision. We had many others like that. We had a few others where we started doing like PHP or more modules in Java. So subsequently, I don't think we have incorporated those many technologies. Like these are the two biggest changes in which we have incorporated technologies because of client. Later on, we introduced React or we've replaced Angular with React, but that was a market change. That wasn't client-driven. We incorporated Python two, three years ago. That wasn't client-driven, that was a market change. But mobile and Node.js, that was that was mostly client-driven. Outside of that, we've had some other forays into other technologies with some of the clients that we have that sometimes, you know. Oh, by the way, guys, I have a this module in Java. Um, I know you're doing only Ruby and Rails, but this like small tweaks here and there, once or twice per year. Can you do it? Sure, we've done that. We just don't advertise it on the website because it really doesn't bring any value. It would give us some kind of projects and clients that we don't want. But if they are if they come our way anyways, we'd gladly take them. Um similarly, a client of ours that was that was Spin. Spin is uh or was an electric scooters company that in 2017 we started working with their uh backend team um with a couple of our developers doing Ruby and Rails. And uh by and large, we did Ruby and Rails for three years, four years. At a certain point, our two developers came to us and said, Look, um um I don't have any more Rails tests. The client told me that we're gonna be doing Go, Golang. And we said, like, well, fine. Like, I don't know. We we took a look at what was Golang. We we knew it, but not in sufficiently level of detail. And we decided it was it was interesting. The client really needed it. The guys wanted to learn that technology. It was not very far from stuff that we were doing with JavaScript, and we said, well, there you go, just just do it. We will not put it on on the website, it's never been on our website because we want to keep our niche and boutique position, um, but you guys are free to do it because mostly it's a client that we know, it's a client that respects us, it's a client that understands that the risk is shared and split, and because we also told them that it was in our interest to to do this. So if I think that in the 12 years of Mars based, we have never gone into a new client with a new technology, right? Because when you enter uh you start working with uh with a new client, you have the risk of getting to know that client, the risk of getting to know their sector and their platform, and you cannot, and you should not, at any cost, at the risk of learning a new technology or working with with a technology that that you don't know you're not conf comfortable working in. Um we I've got plenty more examples, but I think those define the way that we have approached the stack changes throughout the the history of the company. Um there are other considerations that I might want to cover in this in this in this episode, but basically the part that you know has got to do with operations and vision is sufficiently covered. The other thing that you really have to consider is team composition, right? Having a uh wider range of technologies might help you to choose from a larger pool of talent. At the same time, there are a few, uh there are some people that don't want to work for generalist companies. And I think that we have been successful in attracting top-tier talent that wanted to work only with Rubian Rails, precisely because we only work with Rubian Rails. Or later on, React, or right now, Python. But because we're a specialized agency, they really uh valued this, they really wanted to work for a company like this, and uh they uh they you know they applied for a job at Marspace instead of uh of another company. Um also we have you know we have a long record of having people work for us many, many years. Uh some people are turning 10 years uh into the company this year. We've got one employee David with 11 years into the company, and most of them are five to seven on average. So I think that in terms of of team loyalty, this also plays a big part. If you are niche, it's much more likely that you will, I don't like retain your talent. I don't like that word, but uh you will be more able to keep them around than if you're a generalist, because basically the they are much more of a commodity in that kind of company than they are in a company like Mars-based. In terms of marketing and sales, that is also interesting. Um, I think that being a generalist company for marketing is playing against you. Why? Because being a generalist company means that you have little to no differentiation between you and your competitors, right? So if you're not able to articulate your uh sufficiently different value proposition, the chances are you're gonna get like the scraps off the table and the leftovers from bigger companies, and you'll be perceived as a just another company. The one the kind of company that they call when they need multiple quotes, multiple proposals from multiple vendors. Whereas, on the other hand, if you're a niche company, if you're a boutique, that's our case, it's very likely that companies that they when they call you, it's because they really want to work with you. They want to work with Marspace, or companies that are very, very close to Marspace. For instance, when we started working for Walkie TV, sort of like the Spanish Netflix back in the day, um they were working already with another company that preceded us that was called Code Gram. If if you have been in the Ruby on Rails industry, uh they were a really cool company for many, many years. Um and Waki uh had been working with them, but they didn't have enough of a large team. And so the CTO, uh, when he got to know us, they said, like, oh, you guys are like Code Gramp. I really want to work with you. I know what you guys do. I'll check your website, you're basically the same kind of guys, say same kind of team size, same technologies. You're hired. And um that was cool because we didn't even have to go for like a long process. The the the reference tech was almost non-existent. It's if you guys are like these guys, I'm already working with, you're gonna be a good deal. And we're a good deal. We worked for them for many, many years, and um we still work with uh uh they are CTO at the time in in other projects. So um Jordi Miro has been on the podcast as well uh multiple times in Life on Arts. So um I think that if you are a niche company, chances are that it will play in your favor if you're marketing your company. It's much easier to articulate a branding strategy, uh clearer messaging, like we're the number one Ruby on Rails company from Barcelona or from Spain or from Southwestern Europe, or the number one React Native specialized boutique agency, or number one Shopify uh full-on end-to-end service provider for Shopify services, right? Um I think that for marketing, that's good. For sales, it's more or less the same. It's much more direct sales, much more intentional, much more, let's say the client is already convinced, so they are 50 to 70% already convinced and bought into the idea of working with you if they come to your website precisely because they know the kind of company that they want to work with. Generalists, they get more vague and broad and explorative kind of inquiries and conversations. And maybe their top of the funnel is larger and wider, but the conversion rates at every level of the funnel they are not as great. Whereas we receive fewer deals per month, but out of those, a higher percentage of them convert to every stage of the conversation, of the marketing funnel or the sales funnel. Um, sometimes we're able to go from first conversation to contract in 24 to 48 hours because they know already kind of company that we are, they know exactly what they want. They if the pricing is correct, if it's like a team augmentation or something like they they need a squad for a few weeks, we send the proposal and they're like, yeah, we know where we're what we're hiring here. We work with a similar company in whatever other location in the world. So it's easier to piggyback on somebody else's credentials, authority, or likeness, and uh that's gonna that's gonna play well in your favor. Good. One of the other considerations I have is is this a static decision? Is this something that is set in stone and never changes? No, the reality is not. You can go from being an niche company to being a generalist company and the other way around. It's complicated, we've never done it, even though we have explored it. Um, at a certain point in the company, a couple of times, we decided to enlarge our technological stack. We've never made the intent to become a generalist company. We did one time want to become a one-stop shop for our clients, but still specialize in our technologies, Ruby and Rails, JavaScript, and Python. But we never set out to say, like, we can work on any kind of technology. Now we do everything. Now we integrate other technologies with the team augmentations, we do SharePoint and stuff like that. But um I think that you have to re-evaluate this value proposition of the company because what was right 10 years ago might not be the right decision right now. Um let me be clear on this. We have been lucky enough that JavaScript has been, you know, on the rise for many, many years. Ruby and Rails hasn't gone away and will not go away for the foreseeable future, and Python has dramatically increased its market share in the last few years, but mainly because of AI and big data. So we're safe here. But if we had been working with some kind of language that went out of fashion, we would have had to change our positioning. Um, if we started only with Ruby and Rails and after 20 years, like we lost all of our deal flow overnight, all of our clients overnight, maybe the next step would be become a generalist company, open up to absorb any kind of project that came our way and start doing it with the team we had so that we didn't lose the team. Would maybe lose the team a little bit later on because they didn't want to work, they wouldn't want to work for a for a generalist company, but that's a completely different story. Um But that that being said, I think it's healthy to reevaluate your positioning every few years and to see if that still stands. At a certain point in the history of Marspace, we have said, like, oh, maybe Ruby and Rails shouldn't be our backbone of the of the of the tech stack, our main pillar. But after careful consideration, we decided to keep it, maybe put another like JavaScript at the same level. We did have Ruby on Rails and JavaScript at the same level for many, many years. Um now we're sort of back to only Ruby on Rails as the main technology and so Ruby on Rails over Node.js to be more specific. And if the client really wants to know Node.js, we'll do it, but at with a premium tack on it, right? With a with a bit of a markup on it, but because we're able to build much faster and better with Ruby on Rails. But that's it. Both technologies are still first-class citizens at Marspace. There's another thing in terms of team composition. I cover it briefly in the beginning of the of the episode, but if your team doesn't cover all of the technologies that you work with in the company, it will be much more complicated to make rotations. For instance, Ruby and Rails in JavaScript, it's pretty covered by almost all of our developers in the company. Pretty much everyone knows both technologies. Some might be stronger in Ruby, some might be stronger in JavaScript. Um, and the JavaScript people have had some adventures with Ruby and Rails and the other way around. However, two years ago or three years ago, I don't remember right now, we incorporated Python. Python is a technology that a few folks in the company have worked with. We've got two projects right now in the company, but uh they are but there's a minority of engineers in the team that know Python. Therefore, if we have to rotate people to these projects, we will not be able to put an expert to replace the one that is already working with a project, right? So it's uh it's complicated already for a niche company, it will be ten times more difficult for a generalist. Because if every project that you've got is a different tech stack and your team, you know, you got a few folks doing Java, a few folks doing PHP, a few folks doing C, stuff like that. The transition isn't immediate. The burnout from context switching is going to happen much more frequently because you're that kind of company that you're just putting out fires and you don't get you don't stay enough in the projects to become stable, know the code code base really well, and all of that. So rotations are perceived as a nightmare. In our kind of company, rotations happen every 12, 18, 24 months, sometimes longer. Therefore, rotations are exciting in our company. They are not a hassle, they're not like a threat that, oh my God, no, I'm gonna rotate three times this month. Right? So I think that's that's also very important in terms of the consideration. The other thing that I didn't cover when I mentioned sales, there's another important um thing in team structure, is that if you are a generalist company, most likely you have to build an outbound strategy for sales. Because literally every and any company out there is your client, can be your client. Therefore, you can just set up an army of people working in sales, SDRs, cold calling, cold emailing, running marketing campaigns to potentially every company out there because they can be your client. If you do everything and anything, that company there that needs an e-commerce, you will be their provider. That company that's an SAP integration, you will be their provider. The company that needs some A-B testing campaigns for the marketing pages, you can be their provider. So pretty much you're guaranteed to have every company out there qualifying as your customer. In our case, it's very difficult. When we started, we ran an experiment to see if we could do outbound. The reality is like nobody needed bespoke web-only Ruby and Rails development. So we failed miserably at doing outbound. And that's why we have for 12 years done exclusively inbound. Because the chances are that if you need Ruby and Rails, you're gonna damn well just go to Google or Perplexity or something like that and look for it or ask for recommendations. And you're gonna be working with these kind of companies that only do Ruby and Rails or only Python. So the team composition is very different. And the last consideration, I think that is a very important one, is that if you're ever going to sell your company, the more generalist you are, the less likely that you will get a good valuation from a potential acquirer. Why? Because you have less defensibility. What is your value proposition? If you're just another generic consultancy, they they can buy literally thousands of them overnight. But if they really want to acquire the Ruby and Rails specialized agency, there are not so many in the world. I would argue there are hundreds that do like they are in our range, they do this level of quality, they have this team composition, they work with these clients. So you have something else. You might have on top of the kind of clients that you work for, on top of your team assets. Um, most likely you have no IP as an agency. But if you're specialized, the team composition is something that can be paid for very, very well. So one way to sell your company in an agency is saying, like, hey, how long or how much money would it take for you to rebuild this team from scratch? A team of 20 odd engineers in our case, with so many years in the company, therefore, no new hires, no junior profiles, a very assembled team of developers and engineers. Years like in our case versus a generic agency that they can hire developers like 10 or 20 developers a year for every technology. They will be junior in every technology, and their rotation will be around 30 to 40% every year. In our case, it's close to zero for 12 years. We lost like four people in 12 years. That is extremely much more valuable than the equivalent of a generic company that wants to sell. So that's all for this episode. Hope you liked it. In the next episode, I'm gonna be covering remote, working remotely, having no office, how to hire, how to manage, how to sell, how to work remotely. I think I've got a lot to cover in our next episode. So thank you for your attention. If you like this episode, subscribe and hit the like button. And stay tuned for these building Mars-based series. We've got also the Road to CTO series on our podcast. And stay tuned for more Mars based news. Check our website, check our check our newsletter as well. And I'll see you in the next episode. Bye.