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.

What the Full-Stack Mindset Means to Us

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.

Why Talking to Customers Is Non-Negotiable

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.

Building a System That Works

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.

Engineers as Owners

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:

• Customer communication
• Technical implementation and design
• Testing and deployment
• Support and documentation

Weekly check-ins with product ensure we’re on track, but there’s no micromanagement. The engineer decides how to solve the problem and when to ship. This means they’re responsible not just for writing code but for ensuring that customers successfully adopt the features they develop.

Lessons We’ve Learned Along the Way

Initially, we tried giving projects to any engineer with the assumption they’d get all the context and ask the right questions. Unfortunately, that wasted time and made us slower because engineers were often slowed down by uncertainty when others on the team already had a lot of context. We solved this by using RFCs to document ideas and problems. Now, whenever we start a new initiative, we crowdsource ideas and concerns across the team to uncover all the knowledge we already have.

While we expect all engineers to have a basic understanding across various areas, individual strengths and interests vary significantly. Early on, we assigned tasks without much thought, which didn’t always yield the best results. Aligning projects with specific skill sets makes us much more effective and faster today.

We’ve also learned that hiring engineers who fit this mindset is harder. We look for people who are not only technically skilled but also comfortable engaging with customers and taking full responsibility for their projects.

Building the Future at Kombo

At Kombo, our full-stack mindset has transformed the way we build products and work as a team. By prioritizing customer interaction, eliminating boundaries, and fostering a culture of ownership, we’ve created an environment where engineers thrive and deliver exceptional results. We’re proud of what we’ve achieved and excited to keep growing this unique engineering culture.