When we started Kombo, we built products the way founders build in the early days. Nobody gives you a spec, but you talk to them to understand the problem and come up with a solution that will make them happy. When doing that, you own their problem end-to-end.
We kept doing it this way as we grew. We learned that when you put an engineer in front of a customer and let them understand the problem firsthand, they are much more inclined to solve the right problem in the right way. We made that the central part of our engineering philosophy.
You talk to customers. Before starting on a feature, you schedule customer calls together with a product manager to understand what they need. You gather context firsthand. This shapes how you approach the technical solution. You substantially shape the design because you understand the problem better than anyone else. We have a very technical product, so who is better suited to design it than an engineer?
You work on initiatives with a product manager and senior engineers. The team helps you succeed. When you're stuck on a technical decision, senior engineers review your approach. When you're unsure about a customer need, the product manager has context. When you need to understand how something works, someone on the team built it and can explain it. You're involved in the entire process: customer conversations, technical design, implementation, deployment, and support. You will develop the skills and ownership to move independently over time and own bigger and bigger problems. The goal is to be able to take a customer problem and ship a solution without depending on others.
Full-stack at Kombo goes beyond the tech stack. It means end-to-end ownership of the problem. Nobody at Kombo says, "That's not my responsibility, give this to the backend team." When something blocks you, you handle it. When your feature needs support, you provide it. When customers have questions, you answer them.
This works because we eliminate unnecessary boundaries. Single programming language (TypeScript) for frontend and backend. Monorepo. Trunk-based development so you can ship fast without waiting for release cycles. Internal transparency so you can find any information you need. You can focus on solving problems instead of navigating organizational complexity.
You own problems, but you're not alone. Before starting an initiative, you write a short RFC that invites the team to challenge your assumptions and share knowledge. This saves you from running into problems others have already solved. When you're blocked, you ask for help. The team works together to make sure everyone succeeds.
When you own an initiative, you decide how to solve it. You're responsible for customers successfully adopting what you build. You move fast because you don't wait for approvals or handoffs.