# Notorious mistakes we have made as a Software Services Company — Icalia Labs Blog > Ten mistakes Icalia Labs made in its first 3.5 years as a software services company, from pricing and contracts to culture, hiring, and mentors. Pre-AI era · 2016. Written before AI was part of how we build. The fundamentals still hold; tooling and workflow advice may be dated. Originally published on [Medium](https://medium.com/icalia-labs/notorious-mistakes-we-have-made-as-a-software-services-company-83f00e56ffbc) on April 18, 2016. Lightly edited for clarity. 1. [Home](/) 2. / 3. [Blog](/blog/) 4. / 5. [Software Development](/blog/topics/software-development.html) [Software Development](/blog/topics/software-development.html) # Notorious mistakes we have made as a Software Services Company Ten mistakes Icalia Labs made in its first 3.5 years as a software services company, from pricing and contracts to culture, hiring, and mentors. ![Eduardo Lopez De Leon](/assets/eduardo-lopez.webp) Eduardo Lopez De Leon · Co-Founder & CEO April 18, 2016 · 7 min read ![Black-and-white photo of a person with curly hair working on a laptop at a shared table with colleagues](/assets/blog/notorious-mistakes-software-services-company-cover.webp) 3.5 years as a company: a short period of time, but with many lessons learned to share. We didn’t have any formal support to handle unexpected and hard situations along the way. Now that we have lived through them, here is a list of the most important situations to share with the world, in the hope that any services company in the same field that is just starting out can take them as valuable input. The most hardcore mistakes we have made as a Tech Services Company are: **1\. Wrong pricing for our work and effort.** What’s the price of a piece of software? What’s the value of that software being executed in the right context by the right team? What’s the cost of not properly implementing software? And what’s the value of good software for those companies that have had problems deploying good software in the past? All the considerations to build, deploy, and maintain software the right way certainly have value. All procedures around recruiting, hiring, retaining, and motivating (also perks and incentives) the right team for the right software have value. The company culture embedded within the processes, practices, and conversations to build the right product has value. Being a small team of engineers and designers matters. It is the very first step in building a culture, a service, and then a company. If somebody is looking for a team capable of building software, that means he wants to win against time, effort, and strategy in building a team; he needs execution. The execution capabilities you and your team are developing are part of that value. You are not a freelancer. You are a team, with value for your clients that needs to be charged the right way. **2\. Working without contracts, both with clients and providers.** One of the worst things you can do is avoid formality in a business relationship and not sign a contract. A contract is just an artifact to develop confidence between the parties. It doesn’t mean you are going to bring attorneys to every conversation about the relationship itself. Having a contract where all parties agree on the terms maintains sanity and develops confidence faster. Also, it gives you a backup for any anomaly or irregularity that could happen in the future. It doesn’t matter how small or big the parties are. Encourage the signing of a contract, preferably a contract proposed by the one providing the service. We have faced problems where a company bigger than us, asking for our services, tried to impose a contract. The reality is that if X is asking for the services of Y, it makes more sense for Y to propose a contract, because Y is the one providing the service. **3\. Not building our culture from the very first day.** Values, rituals, and a manifesto to accomplish the mission and achieve the vision. The way you recruit, the way you talk to the world, the way they see you as a company: everything happening around a business relies on the culture it defends and promotes. Normally, when you start, you forget to think about the basic elements of a culture, but once you want to grow and scale your team and your value, you realize the [culture is the backbone of your entire business](https://medium.com/@bchesky/dont-fuck-up-the-culture-597cde9ee9d4#.oqfs5rmz9). Competing with big companies for the right talent is not a battle you win with money, because of what they can offer; you win it with the culture and the vision you can share with others. Remember: [the first 10 employees define your company culture](https://web.archive.org/web/20160419001830/http://startupclass.samaltman.com:80/courses/lec11/) and [you should feed them with only 2 pizzas](http://blog.idonethis.com/two-pizza-team/). **4\. Agreeing on equity and working for early-stage [bootstrapped startups](https://en.wikipedia.org/wiki/Bootstrapping#Business).** Many of these cases were from first-time entrepreneurs. Nevertheless, someone wanting to share equity with our company before starting a project is a sign of a low-quality lead. Lack of investment, lack of validation, and fear of taking risks are examples of the problems we see when negotiations start with these kinds of proposals. It is always exciting to hear new ideas flowing, see entrepreneurs’ enthusiasm, and be part of a new vision looking to change an entire industry. There are many success cases of companies doing this, but the best scenario is when the founding team has a background building other companies, or the idea aligns in some way with your company’s vision and you feel it is the right moment to build something like that. Otherwise, pass. When it comes to business, if you are going to provide value to any product or new business, you need to assess the risks in every term of the relationship. Ironically, we are a bootstrapped company, just like [many others](http://37signals.com/bootstrapped). **5\. Working on client products from scratch with all design done by third parties.** Other companies in the process will block the guarantees we offer. We have lived this in the past, and the difficult thing is helping the client realize that coordinating more entities and actors at the beginning of product development is a real challenge, and most of the time it doesn’t end well. Delays and misunderstood features, to name a few, are possible situations. The fewer communication channels while building a product, the better the outcome is going to be. **6\. Considering one region as the only target market.** We started in one region — our headquarters country: Mexico. Many people started to contact us to build great software with them and change the way industries have worked for the past decades. This was part of the very first acquisition channels we had for getting in touch with interesting leads: basically, word of mouth and our network. But why stay just there? We received many similar needs from other clients around the world, derived from clients’ referrals and networks, word of mouth, open source efforts, and being connected with communities like WeWork, to mention the most effective. The interesting part was dealing with the culture, language, and diverse backgrounds of both sides. Thanks to our efforts in open source, and the connections from the company network, we started working with great clients around the world, discovering new technical and business challenges. With the power of the Internet and the many tools leveraging it, collaboration and software development can happen both co-located and remotely. **7\. Not having mentors from the first year of the company.** Mistakes can be advised against. People with experience who have built teams, companies, and visions have the right profile for the advisors you need to have behind you. The same goes for investors — you need people who become part of the team, not people demanding what they think it should be. Advisors mainly advise, and help you have more perspective and input when you need to make a decision. **8\. Lacking a hiring procedure and clear profiles of the people we needed.** This was something we noticed during the first years. Growing our team and the capabilities to detect great talent weren’t scalable. What’s more, the way we were executing the talent evaluation wasn’t considering important elements of our culture. We ended up firing people who didn’t fit the type of talent we believed was going to push the entire company to achieve the vision. Right now, we have established a 3-hour procedure for technical, creative, and management roles, where culture and values are the first thing we assess, followed by an activity where we test the person in a real work environment. **9\. Focusing only on first-version products, rather than helping clients keep building them.** It wasn’t obvious, not only in terms of revenue but also in terms of impact, that keeping long-term relationships with clients and partners would be part of a trustworthy link that would enable the impact we wanted to see out there with the products and software we were going to build. Being part of only the initial development of an MVP, prototype, or feature enhancements wasn’t going to help our clients, nor help our vision be achieved. We have switched many of the conversations to start with an initial task to develop trust and confidence between us, and then think long-term, looking forward to helping them and having the impact they want to have as well. **10\. Rarely asking where the software industry was going to be 5 or 10 years from now.** This is a rhetorical question every company should be asking about its particular industry: Where is our industry going to be in 5 years? What are we doing to see the industry at that point? What should we do to be part of that evolution? Frequently asking this question — every year, quarter, month, even every day — allows us to be continuously aligned with user, client, and industry demands. It also allows us to propose and create things that don’t exist, in the way we imagine them existing, in order to move the entire industry forward. Changing the answers as time passes is normal, but keeping that question as part of the mindset lets us be part of the future we want to see. This list will surely grow; mistakes won’t stop, and that will be a good sign. Putting an end to all the possible mistakes you can make as a company means putting an end to the capacity, willingness, and vision to innovate. Making mistakes comes from trying things you have never done before, but if you don’t take the risk, who will? _What other lessons have your companies learned in their early stages? Let’s start an open conversation so both sides can benefit from our experience._ ![Eduardo Lopez De Leon](/assets/eduardo-lopez.webp) Written by Eduardo Lopez De Leon · Co-Founder & CEO Strategy, brand presence, and partnership development at Icalia Labs. Startup and corporate experience. YC Founder. [LinkedIn](https://www.linkedin.com/in/elopezdeleon/) [X](https://x.com/edolopez) [GitHub](https://github.com/edolopez) ## Related reading [ ![](/assets/blog/monterrey-office-overhead.jpg) September 22, 2026 ### How to Hire Software Engineers in Mexico: A US Guide A practical guide for US companies hiring software engineers in Mexico: hiring models, legal setup, vetting, onboarding, and the mistakes to avoid. Nearshore Hiring ](/blog/how-to-hire-software-engineers-in-mexico.html) [![](/assets/blog/distributed-software-teams-in-management-consulting-cover.webp) Pre-AI era February 26, 2021 ### Adapting a distributed software team capability in Management Consulting Argues that management consulting firms need a software development practice and explains how distributed teams help them win deals and scale. Nearshore Hiring](/blog/distributed-software-teams-in-management-consulting.html) [![](/assets/blog/holistic-agnostic-specific-problem-solving-cover.webp) Pre-AI era April 20, 2020 ### Holistic, Agnostic & Specific at solving problems Why being holistic, technology-agnostic and industry-specific makes software engineers and teams better at solving problems. Forward-Deployed Engineering (FDE)](/blog/holistic-agnostic-specific-problem-solving.html) ## Need engineers who already ship like this? We embed senior nearshore engineers directly into your team — same time zone, same standards, no ramp-up theater. [Book a discovery call →](/contact.html#book) [Explore our open source](/developers.html)