For almost 7 years, I built Tomorro, a contract management platform, as cofounder and CTO.

The experience changed me. I grew, learned a lot and shared the journey with people I loved working with. I learned these lessons by doing, from the people around me, from my team and sometimes by getting things wrong. These are the ones that stayed with me (in no particular order).

1. Building a company is an adventure

And I loved it. It is demanding, all-consuming and exciting. The company is always somewhere in your mind. Every day brings a new subject and many have little to do with tech. That variety is part of what makes the adventure so interesting.

Being naive can be a strength at the beginning. I did not know exactly what lay ahead or how many walls I might hit. I was ambitious and ready to give it everything.

It is a bit like a junior engineer building something quickly and imperfectly but still creating value while a senior engineer is working through the architecture, specifications and constraints. I like working with both because they bring different strengths. In the same way, not seeing every obstacle can help you start, persist and recover when things get hard.

That energy needs somewhere to go. For me, running was a way to clear my head and create distance from a company that was otherwise always present.

The responsibility is hard to share completely, so surrounding yourself well matters: people inside the company who take real ownership and peers outside who help you step back.

2. Your role must keep evolving

At first, the CTO builds the product (back then, without AI). With the first engineers, the role becomes technical leadership. As the team grows, it shifts towards management, organizational strategy and alignment with product and business.

Scaling breaks everything

What works with 1 person no longer works with 5. What works with 5 no longer works with 25. Each stage requires redesigning the organization and redefining the CTO role before it becomes a bottleneck.

You also need to know when to lift your head. Staying close to the details matters but the role is no longer only to solve today’s technical problems. It is to see what the company will need next and help the team prepare for it.

3. Keep running experiments

Keeping things as they are is more comfortable. It avoids friction and creates a sense of calm. But comfort is not progress.

Keep moving forward. Try something, observe what happens, learn from it and adjust. This applies to both the organization and the product. The goal is not to get every experiment right. It is to learn faster and keep what works.

Test the organization

There is no perfect organization and there is no final organization. Teams, responsibilities and practices need to evolve with the company. Test new ways of working, see how people respond and adapt them to the current scale and context.

Keep the product alive

A product is never finished either. Put changes in front of users, listen to their reactions and use what you learn to improve the next version. Remaining static is often more dangerous than trying something that does not work.

Make change part of the culture

This mindset has to become part of the culture. People should feel encouraged to question how things work, propose experiments and share what they learn.

Change still needs to be handled with care. A reorganization can create fatigue and a product change can worry customers. Explain why it is happening, prepare people and give them room to participate. Keep the company moving without making every change feel like a new crisis.

4. Clarity is key

Build a shared language

At Tomorro, we created a shared domain definition: a common vocabulary for the problems we were solving and the concepts behind the product. The same words then carried the same meaning in product discussions, technical decisions and conversations with customers.

This removed unnecessary translation between teams and forced us to clarify what we were actually trying to solve. A shared language creates consistency across the company and the product.

It also creates consistency in the code. The concepts used by customers, product teams and engineers can be reflected in the domain model instead of being translated at every layer. This shared context is increasingly valuable for AI agents too: precise concepts and consistent names help them understand the system and make better changes.

Repeat the vision

The founders need to present the vision clearly and convincingly, again and again, until it becomes a shared story. The goal is then for the team to explain it in their own words and believe in it.

Clarify responsibilities

Responsibilities need the same clarity. We introduced a RACI and kept updating it as the organization evolved. It was not a document to complete once and forget. It gave people a common reference for who owned a decision, who contributed and who needed to stay informed.

Revisiting it together helped surface misunderstandings, align expectations and give people the confidence to act without constantly asking for permission.

5. Make room for the team

The best initiatives often come from the experts closest to the problems. Encourage them, give them visibility and make it safe to propose something that was not part of the original plan.

Trust people with real responsibility and delegate outcomes, not only tasks. Give them the context and boundaries they need, then leave room for them to find a better path than the one you might have chosen.

Autonomy does not mean stepping away completely. Stay available, provide support and make ownership explicit without turning every decision into an approval.

6. Build a strong tech culture

A strong tech culture is not defined by a stack, perks or a list of values. It is what the team does by default when no one is watching. It comes from repeated behaviors: trust, ownership, curiosity, knowledge sharing and high standards.

Connect tech to the company

A tech team should not become a factory separated from the rest of the company. Engineers need to understand the customer problem, the product and the business impact of their work. Technical excellence matters when it helps create a useful, reliable product.

Balance speed with quality

A strong culture combines ambition with pragmatism. Move fast but do not make quality someone else’s problem. Testing, maintainability, observability and security are shared responsibilities.

The team needs enough judgment to know when a simple solution is sufficient and when a shortcut will become too expensive. High standards should help the company move, not become an excuse to wait for perfection.

Learn together

Knowledge should circulate instead of staying with a few people. Review work, share context and make time to explain decisions. Discuss mistakes and incidents to learn from them, not to assign blame.

People also need to feel safe challenging an idea, including one coming from a founder or a more senior engineer. Seniority should raise the level of the team, not concentrate every decision.

Build it deliberately

Culture appears in everyday choices: how people react to mistakes, handle disagreement, make trade-offs and help each other. Leaders shape it through their example, hiring, onboarding, feedback and the behaviors they recognize.

What leaders encourage, reward and tolerate becomes the culture. It cannot be written once and considered finished. Like the organization, it needs to evolve as the team grows.

Make security a shared responsibility

Security has to be part of that culture too. Protecting customer data is everyone’s responsibility. Teams need clear rules, regular education and the confidence to raise concerns early. Security works better as a shared habit than as a final approval gate.

7. Stay close to customers

Customers evolve. Their tools, expectations and problems evolve with them. Understanding them once is not enough.

Talk to them regularly, listen to the words they use and watch how they actually work. They are the fastest way to reconnect your work with reality.

Go beyond demos and support tickets. Use their tools, understand their workflows and experience the friction around your product. The closer you get to their daily reality, the clearer the real problem becomes.

8. Embrace AI without overreacting

I will not repeat that AI is transforming technology, organizations, roles and individual ways of working. That is already clear and the change will only accelerate.

New tools and models appear every week. We cannot overreact to every announcement but we cannot ignore them either. Stay curious, keep testing and evaluate each change against the value it creates.

Experimenting does not mean adopting everything. Test a tool with a clear purpose, understand where it helps and decide whether its value justifies changing the team’s habits.

Experiments will create some chaos and that can be useful. They break habits, create movement and reveal new ways of working. The goal is not to avoid that chaos. It is to learn from it without turning every experiment into a permanent change.

Teams need support through this transition. AI is changing so quickly that security systems and policies cannot always adapt at the same pace. Awareness, ownership and individual responsibility then become essential.

Give people time and access to experiment within clear security boundaries. Teach them how to protect customer data, recognize risks and know when a tool should not be used. Explicit context, shared guidelines and expert judgment become more important, not less.

The same principle applies again: be an enabler, not a blocker. Create safe ways to explore AI and help the team learn from what works.

AI makes it possible to build faster. It also makes it easier to build the wrong thing faster. It should extend judgment, not replace it. Running out of tokens should never mean running out of ideas or the ability to build.

9. Be an enabler, not a blocker

I had to repeat this to myself again and again. At the beginning, over-rationalizing can slow everything down. The company has to move before every question has a perfect answer.

The first reflex should be to find a way forward, not only expose constraints. That does not mean abandoning architecture, security or quality. It means choosing trade-offs consciously and preventing accidental debt.

Being an enabler does not mean saying yes to everything. It means helping the company move while staying true to the principles that matter.

10. Celebrate the wins

This was probably one of my weaknesses. I would reach a milestone and immediately start thinking about the next one. I did not take enough time to feel proud of what we had achieved or create momentum around it.

Some people do not need to pause after a success but others do. Leaders should not assume that everyone experiences achievement in the same way. Celebrating recognizes the effort, gives people energy and creates a shared sense of progress. Make time for it. After so much effort and commitment, people deserve that recognition.

11. Data should guide decisions

Data is often underestimated. Every meaningful initiative needs a way to understand its impact and performance. Metrics need to be collected in a usable form, understood and actually used.

This needs to become part of the culture, not an exercise performed after a decision has already been made. Many kinds of data can help teams make better decisions as long as access and confidentiality are controlled.

AI evaluations follow the same rule as any other production initiative. Quality, cost, latency, reliability and user impact must be measurable so that effort and energy go towards what truly matters.

12. Do not avoid difficult conversations or decisions

Sometimes the most useful way to move forward is to say no. Know when to say it and learn how to explain it. Leadership is not about pleasing everyone or adapting every decision to every individual preference.

Some decisions will be difficult and unpopular. Stay true to your principles, be comfortable defending them and accept responsibility for the consequences.

13. There is always another finish line

Founding a company has no real finish line. A chapter does.

Leaving Tomorro felt like finishing an ultra-trail. You cross the line exhausted and think: never again.

The next morning, you sign up for another one.

My next one was the Pacific Crest Trail.