PRESENTATION
A presentation
My name is Diego Garciacelay and I am the founder of Primate.
When someone asks me what Primate does, the simplest answer is usually that we implement Odoo. It's a correct answer, but I realized a while ago that it's not enough.
Over the years I've discovered that implementing an ERP is just one of the tools we use to try to achieve something much bigger. What truly excites me isn't the software. Nor is it the technology.
What I'm passionate about is building better companies.
Companies where people can work better, make better decisions, develop better products and, as a result, have a better quality of life.
I didn't reach that conclusion the day I founded Primate. I discovered it over the years, through successes, mistakes, conversations, and many questions. And it will probably continue to change for many more years.
This document attempts to capture that moment along the way.
It does not attempt to explain how a company should operate. Nor does it try to convince anyone that there is only one right way to build an organization.
Just try to answer a question.
What kind of company are we trying to build?
And, perhaps more importantly, why do we want to build it that way?
BEFORE WE BEGIN
A necessary self-criticism
I want to begin with some self-criticism.
For a long time I thought that a company was built by making good decisions.
Today I believe that a company is also built by helping others understand why those decisions exist.
For years, many decisions seemed to stem from intuition or personal preference. Those who worked with me knew some of my ideas, others they intuited, and many simply remained in my head.
I assumed that culture was transmitted through coexistence.
Today I don't think it's enough.
If a company relies on people interpreting what its founder thinks, it is still actually relying too much on the founder.
Looking back, I think that was one of my biggest shortcomings with Primate. Not for lack of trying. But because I never found the time—or perhaps I never understood the importance—to stop and write down what kind of company I wanted to build.
This document attempts to begin correcting that error.
Not because I think I've found the answers. Quite the opposite. Today I feel like I'm still learning how to be an entrepreneur. Primate is also still learning how to become the company it wants to be.
Therefore, this document is not intended to be an unchangeable manual. I hope it will change. I hope it will evolve. And, above all, I hope it will cease to be "my" document and become a document for everyone who builds Primate.
I don't want people to learn how to implement my decisions. I'd like us to learn together how to make better decisions.
Nor do I expect everyone to share this exact vision. I would like them to understand it, question it, enrich it, and participate in its development.
I firmly believe that the best companies are not those where the founder is always right. They are those where the best ideas find space to emerge, regardless of who they come from.
If this document succeeds in generating conversations, questions, and better decisions, it has probably fulfilled its objective much better than if it simply gets us all to agree.
CHAPTER 1
Why does Primate exist?
It took me several years to answer this question.
When I founded Primate, I probably would have answered that I wanted to build a company dedicated to implementing Odoo. It was a logical answer. After all, that's what we did every day.
Over time I understood that that answer described our activity, but not our purpose.
Implementing Odoo was never the goal. It was always the means.
Today, I believe Primate exists to help build better companies. And when I talk about better companies, I don't just mean more profitable, larger, or more efficient companies. Those things are important and necessary. A company that doesn't generate results can hardly sustain itself over time.
But I believe a truly successful company is one that generates financial results while improving the lives of those who build it every day. That means organizations where people work better, make better decisions, depend less on individuals and more on processes, and where technology ceases to be a problem and becomes a tool.
That principle applies to us as well. It wouldn't make sense to help our clients build better companies if, to achieve that, we were building a worse one within Primate.
When we talk about quality of life, we're not just talking about those of us who work at Primate. We're also talking about our clients. And about all the people who work in the organizations that trust us, because in one way or another they are also part of the impact we seek to generate.
I don't believe a successful implementation ends when a system goes into production. I believe it ends when people are working better because of it.
Time as a form of respect
There's one idea that runs through virtually every decision we make at Primate. An idea that, at first glance, might seem minor, but which, over time, I've learned to consider one of our most important principles.
Time.
We develop products. We invest in artificial intelligence. We automate processes. We document. We seek reusable methodologies. We try to standardize implementations. These are very different initiatives, but the more I think about it, the more convinced I am that they all pursue the same goal: respecting people's time.
Every repetitive task we automate saves someone else time. Every well-written document prevents someone else from having to go through the same process again. Every product improvement prevents the need to redevelop the same solution. Every better-designed process reduces errors and frustrations.
I believe that respecting a person's time is one of the most concrete ways to respect that person.
Technology as a tool
We work with technology every day. But I would like us to never forget that technology is just a tool.
We don't do artificial intelligence because it's trendy. We don't implement Odoo because we like the software. We don't automate processes to demonstrate technical expertise.
We do all of this because we believe it can improve people's lives.
That distinction seems simple, but it completely changes how decisions are made. A company that treats technology as an end in itself tends to over-engineer, overcomplicate things, and lose sight of the user. A company that understands it as a means tends to simplify, ask questions before building, and measure success by the real impact it generates.
Technology should never be the end. It should always be the means.
CHAPTER 2
How we think
Over time I understood that companies are not built solely with good people, good products, or good opportunities.
They are built, above all, on a shared way of thinking.
Strategies change. Markets change. Products evolve. People do too. But the way an organization analyzes problems, makes decisions, and learns from its mistakes ends up defining its identity far more than any strategic plan.
This chapter does not aim to establish rules. It aims to explain some principles that, at least for now, I try to use when thinking about Primate.
Questions before answers
It always struck me that most organizations reward those who have quick answers.
Over the years I've discovered that many times the best decisions stem from a good question. Why are we doing this this way? What problem are we really trying to solve? Is there a simpler way? Are we adding value or just adding work?
I try to surround myself with people who ask questions. Not because questioning is an end in itself, but because questions force us to think. And thinking before acting is one of the most important responsibilities we have.
Build before you solve
Solving a problem creates value. Solving it in a way that makes solving the next one easier creates even more.
Every project should leave behind more than just a solution to the client's problem. It should leave behind knowledge. Documentation. Reusable code. A better methodology. Automation. A product improvement. If every project forces us to start from scratch, we're growing much more slowly than we could be.
This idea seems reasonable, but it's difficult to sustain in practice. The client's urgency and the pressure of the project always create incentives to solve problems quickly and move forward. That's why it requires a conscious and repeated decision: to invest even if we don't see an immediate return.
Intuition as a starting point, not as an argument
I deeply believe in data. But I've also learned that many important decisions are made before there's enough data to justify them. Often, they stem from an observation, a conversation, or an intuition.
I don't think that should replace evidence. I think it should be transformed into a hypothesis. If it works, we learn. If it doesn't work, we learn that too.
The important thing is not to turn intuition into dogma. Intuition that isn't tested ceases to be a sign and becomes a bias.
I try not to fall in love with my own ideas. I try to fall in love with the lessons they teach.
Learning as an organization
People learn. The difficult part is getting the company to learn.
An organization learns when knowledge is no longer dependent on a single person. When mistakes are documented. When an improvement made for one client also benefits subsequent clients. When sharing what we know ceases to be a voluntary act and becomes an integral part of how we work.
I would like Primate to be a company that learns faster than its competitors. Not because we have more talent, but because we transform every experience into collective knowledge.
Trust as a foundation
I believe the best organizations operate on a foundation of trust, not control.
Trust allows for autonomy. It allows for honest debate. It allows for admitting mistakes without fear. It allows for asking for help when we need it.
But trust also demands responsibility. Keeping your word. Communicating promptly. Taking ownership of your own mistakes. Treating those who think differently with respect.
Autonomy is a consequence of trust. And trust is built much more slowly than it can be lost. That's why I would like us to always cherish it as one of Primate's most valuable assets.
Think long-term
Many decisions that seem good in the short term end up being bad decisions when viewed from a distance of a few years.
That's why I try to ask myself a question every time an important decision comes up.
Does this build the company we want to have in ten years?
I don't always have the answer. But the question helps me distinguish between decisions that optimize the moment and decisions that build something lasting.
Because I feel that, ultimately, we're not just executing projects. We're building a company.
CHAPTER 3
How we make decisions
One of the hardest things for me to learn as an entrepreneur is that a company isn't built solely by making good decisions. It's built by making decisions consistently.
This means that two different people, faced with the same problem, should be able to reach similar conclusions, not because they think alike, but because they use similar criteria to analyze the situation.
That is one of the main objectives of this document. I don't expect everyone to make the same decisions I would make. I would, however, like them to understand the perspective from which I am making them.
The strategy is built every day.
We often talk about strategy as if it were a document that is written once a year. I don't see it that way.
Strategy is built every day. Every project we accept. Every development we decide to undertake. Every hire. Every improvement we implement. Every opportunity we let slip by.
All of that is also strategy. And each of those decisions, however small it may seem, helps define the kind of company we are.
Not every opportunity is a good opportunity
As a company grows, more and more opportunities arise. The challenge is no longer finding a job. It becomes choosing the right job.
An opportunity can be profitable and, at the same time, take us further away from the company we want to build. That's why I try to ask myself a few questions before moving forward:
Does it bring us closer to the company we want to be?
Does it generate reusable knowledge?
Does it strengthen any of our products or methodologies?
Does it make the customer more independent?
Are you building something that will still have value in a few years?
I don't expect all the answers to be yes. But I do believe that these questions help us look a little further ahead than the next project and remind us that we're building something that should last.
A company before a project
Every important decision should answer a very simple question.
Are we optimizing the project or are we building the company?
Often those two things coincide. Other times they don't. When they don't coincide, I try to remember that projects end. Ideally, the company continues to grow for many years.
And that difference completely changes the way decisions are made.
CHAPTER 4
How we understand success
For a long time, I thought that a company's success could be measured by looking at some fairly traditional indicators: Revenue, Profitability, Number of customers, Number of employees.
Over the years I began to feel that those indicators were important, but insufficient. Not because they had ceased to matter, but because they didn't answer the question that interested me most.
Are we building a company worth being a part of?
I believe that financial success is essential. A company that isn't profitable can hardly sustain itself over time, invest, grow, or make an impact. But I also believe that a company can be profitable and still be failing in what truly matters.
That's why I would like success at Primate to have several dimensions.
A successful client
A successful customer is not just a customer who uses Odoo correctly.
It's an organization that works better thanks to the work we did together. It makes better decisions. It relies less on people and more on its processes. It finds information more easily. It wastes less time. It gains autonomy.
I would like our clients to feel that, after working with us, they don't just have a better system. They have a better company.
A successful project
Delivering a project on time is important. Doing so within budget is too.
But I believe a truly successful project leaves much more than that. It leaves a relationship of trust. It leaves lessons learned. It leaves improvements for our products. It leaves better methodologies. It leaves documentation.
Every project should improve the client. But it should also improve Primate. If we finish a project exactly as we started it, we waste a huge opportunity to grow.
A successful person
I never liked associating commitment with the number of hours worked.
I believe a person generates far more value when they think, propose, build, and help improve the organization than when they simply stay busy. I don't want working longer hours to be a reason for recognition. I want generating more value to be the reason. And, if possible, to do so by gaining quality of life instead of losing it.
A successful company
If one day Primate's revenue is ten times higher than it is today, but to achieve this people live with more stress, have less time for their families, and enjoy their work less, I will honestly feel that something went wrong.
My aspiration is different. I want Primate to grow. To develop products. To reach new markets. To incorporate new technologies. To generate better results. But I want that growth to happen by improving the lives of the people who are part of that process.
I know that finding that balance isn't always easy. There are times of effort, of pressure, of projects that demand more than expected. But the difference lies in whether that's the exception or the rule. In whether the stress is temporary or permanent. In whether people feel that the company's growth is also their own growth, or that they're moving in opposite directions.
That's what's worth pursuing.
CHAPTER 5
The company we built together
For a long time I thought that building a company was almost exclusively the responsibility of the founder.
Over time I changed my mind.
Today I believe that a founder can start a company, set a direction, and help define a way of thinking. But a company truly begins to exist when it ceases to depend on a single person.
I don't want Primate to be a company where the best decisions only happen when I'm around. I don't want people to wait for my input to move forward. And I certainly don't want to become the bottleneck in the organization.
I would like Primate to be able to make good decisions even when I'm not around. And I believe that only happens when people share a way of thinking, not when they simply receive instructions.
That's why this document exists. Not to dictate policy, but to try to explain the reasoning behind many decisions. If someone understands how we think, they can probably reach a different conclusion than I did and still make a good decision. And that seems much more valuable to me than simply doing what someone else said.
Building doesn't depend on the position
For many years I heard people talk about leadership as if it were simply a consequence of occupying a certain position on an organizational chart. I never felt entirely comfortable with that idea.
I believe a person doesn't lead simply because they have people reporting to them. They lead when they help make the organization better.
Every time someone finds a better way to do a process, documents learning, develops a tool that avoids repetitive work, shares knowledge, questions a decision with respect and arguments, or helps another to grow, they are building Primate.
For me, building is also about leading. We all have the potential to lead. We all have the potential to build. And we all have the responsibility to do so.
What do we expect from ourselves?
I don't expect everyone to have the same skills or to work the same way. I don't even expect everyone to share my exact way of thinking.
What I would like is for us to share some principles about how we want to work. Not technical agreements. Cultural agreements.
I value curiosity. People who investigate, test, experiment, and try to understand the problem before asking for an answer. Not because asking for help is wrong—on the contrary, asking for help is a strength—but because a curious organization learns much faster than one where all the answers always come from the same sources.
I believe in sharing knowledge. Knowledge generates far more value when it's no longer the sole domain of one person. Every time someone learns something important and shares it, the entire company grows. I'd like to see this move beyond being seen as occasional help and instead be understood as an integral part of the job.
Documentation is important to me. Not because I like documents, but because I want to prevent someone else from having to go through the same process. Good documentation doesn't just save time. It also reduces errors, fosters independence, and makes learning easier.
I value respecting other people's time. When we arrive prepared for a meeting, when we write a clear message, when we document a solution, we are showing respect. We often underestimate the impact of these small actions. However, over time, they end up defining the quality of an organization.
And I care about learning from mistakes. I don't expect us to never make mistakes. I expect every mistake to offer a lesson. That every problem forces us to improve a process. If the only result of a mistake is frustration, we waste a huge opportunity. But if the mistake yields knowledge, then it also yields value.
Culture is built through behaviors
It's easy to write principles. It's much harder to live by them.
I'm not interested in this document becoming something we quote in a meeting and then forget when urgent matters arise. I'm interested in these ideas gradually becoming reflected in the way we work.
It's in how we respond to a message. In how we approach a meeting. In how we give feedback. In how we treat a client. In how we argue when we have different opinions.
Because culture never ends up being what a document says it is. It ends up being what people do every day.
And ultimately, that's what we're really trying to build.
EPILOGUE
An invitation
If you've made it to this page, I want to thank you for taking the time to read this document.
I don't know if I'll still think exactly the same way in five years as I do today. In fact, I hope not. That would be a sign that I'd stopped learning.
Nor do I expect everyone who reads these pages to agree with every single idea presented here. That was never the goal.
My intention was much simpler. To try to put into words the company I'd like to build. Not for others to copy, but so we can discuss it, question it, improve it, and, hopefully, build it together.
I firmly believe that the best organizations are not those where everyone thinks alike. They are those where people share a purpose, trust one another, and are able to debate respectfully to arrive at better decisions.
If this document succeeds in becoming the start of those conversations, it will have accomplished far more than I imagined when I began writing it.
Because, in the end, Primate isn't going to be built thanks to this document.
It will be built thanks to the decisions we make after reading it.
And I hope that, in a few years, we can look back and discover that many of these pages no longer exactly represent who we are. Not because they were wrong. But because we will have continued to grow.
Building a company is a process.
And, at least for me, that process never ends.
Building Primate