One of our core principles of engineering at Kombo is our full-stack mindset. For us, this goes beyond just the tech stack. We believe in looking at the whole picture when building digital products.
At Kombo, the full-stack mindset means engineers owning their work end-to-end. It’s not just about writing code; it’s about talking to customers, understanding their problems firsthand, and taking responsibility for delivering the right solutions. This approach has shaped how we build our team and how we work together to create impactful digital products.
One thing YCombinator hammered into our brains is to talk to customers and make them happy. That’s all that matters. My co-founders and I approached every new hire with a similar entrepreneurial mindset; everybody had to do similar work to what we were doing. This was a lot of fun, and we decided to keep working this way.
When our team grew, every engineer had to talk to customers, handle support for their features, project manage the implementation, and make decisions along the way. We were used to working with entrepreneurs and expected that from every team member. Keeping this was not a straightforward path; we had to correct it many times, but in the end, I’m proud we kept this engine running.
Today, most of our engineers operate their day and prioritize completely by themselves due to their high degree of ownership. It’s amazing to see that the company seems to run itself. I’m proud of what our team has made a reality; this is only possible through a team effort.
I never experienced anybody at Kombo saying, “That’s not my responsibility; you have to give this to the backend team.” We try to eliminate as many boundaries as possible. We’re all in the same boat and want Kombo to succeed. When there’s nobody you depend on to make something happen, you can only be blocked by yourself. Anything that usually blocks engineers is then done by engineers as well.
Technically, everyone can take on any problem, and that lets us approach new projects much more aggressively.
We keep things radically simple to avoid creating unnecessary boundaries. We use a single programming language, TypeScript, for both frontend and backend development. This reduces complexity and helps engineers switch contexts easily. Our codebase is organized in a mono repo with a single Docker container deployed with multiple entry points for different services. This setup simplifies deployments and minimizes overhead.
We also follow trunk-based development, enabling quick merges without waiting for lengthy QA or release cycles. This keeps our development agile and responsive to change.
Internal transparency is another key part of our system. All our metrics are visible to everyone on the team, and they can even query the underlying data themselves. Conversations are public by default (not in DMs unless sensitive), and meetings are recorded and shared internally. We use Notion for note-taking, documenting, and planning work. Need to find something? Slack and Notion search will find it for you.
When we spot a problem or opportunity, an engineer takes ownership. They talk to customers first – something I learned the hard way after building two products nobody wanted.
The assigned engineer starts by talking to customers and the team to gather context. They write a short RFC explaining the problem and proposing a solution. The team challenges assumptions and shares knowledge.
Once aligned, the engineer owns everything: