Principles of Software Engineering at Kombo


Introduction

At Kombo, we move fast. These principles, established by Niklas and Aike early on and refined since, guide our technical decisions. They work. Follow them to ship quality code and make an impact.

Doing things well

We build software that works and that we’re proud of. Not perfectionism, but craftsmanship.

We started Kombo to win. Winning in software means being 10x better than alternatives. That requires excellence throughout the organization. “Good enough” doesn’t win. Our customers compare our product to Apple.

High quality attracts exceptional engineers. The best engineers want to work on things they’re proud of, with people who care about their craft. This creates a talent accelerator where great engineers become exceptional.

When we compromise on quality, it’s a deliberate experiment or explicitly temporary. We don’t cut corners for convenience.

Simplicity

Simplicity is our core engineering principle. It lets us move fast and make fewer mistakes. Most other principles flow from this one.

Why simplicity wins:

  • Consistency: Repeat what works instead of reinventing. This increases velocity and reduces failure modes. When you write code, ask: Does this look like Kombo code? If not, make it look like Kombo code.
  • Fewer errors: Simple code is easier to debug and review. We prefer explicit, verbose code over clever abstractions.
  • Easy to change: Decoupled functionality enables fast iteration. Make decisions in one place, abstract the rest. See our upsert deduplication as an example.
  • Fast onboarding: New engineers ramp up quickly with simple tech and code.
  • Better developer experience: Straightforward codebases are more enjoyable to work in.

We avoid adding libraries and tech unless absolutely necessary. Libraries add complexity and bloat. We build what we need, making it easier to extend and debug. We limit new infrastructure and services to avoid maintenance overhead and bottlenecks. One programming language. One database (Postgres). One memory store (Redis). One hosting solution (GCP). One data warehouse. That’s it.

We use proven technologies (Postgres, NodeJS) and maintain a monorepo to deploy everything at once. Our CI/CD ensures the entire codebase is compatible and deploys together. Frontend, backend, and infra changes ship in a single PR.

Fullstack Mindset at Kombo

Every engineer works on frontend, backend, infrastructure, and directly with customers.

Benefits:

  • No dependencies: Engineers ship features end-to-end without waiting on others.
  • Holistic view: Understanding the full codebase reveals connections and conflicts early.
  • Resource flexibility: Anyone can work on any problem.
  • Better solutions: Different perspectives lead to better decisions.

We’re product-minded. Engineers understand customer needs and make technical decisions accordingly.

This means:

  • Cutting complexity: Understanding customer problems often reveals simpler solutions or eliminates features entirely.
  • Autonomous execution: Engineers make informed decisions without waiting for stakeholders.
  • Engagement: Understanding the product and customers makes work more meaningful.

Enforce Best Practices

Make it hard to do things wrong. Use strict typing, linting, and framework constraints. Mistakes erode customer trust and create more work.

Examples:

  • Auth: Middleware forces explicit permission specification. Unauthenticated endpoints require unsafe_ prefix.
  • Function arguments: Destructured object arguments make inputs clear.
  • Naming: No default exports prevents naming inconsistencies.
  • Database models: Enforced naming conventions and metadata requirements.

Thinking Long-Term

Engineers own the long-term consequences of their decisions.

  • One-way decisions: Think through irreversible decisions carefully. These shouldn’t be made alone.
  • Critical questions: Will this work in the future? Where will it break? What are the security implications?
  • Plan before building: Know exactly what you’re building before you start. Complex work requires design docs for review and buy-in. Avoids sunk cost fallacy. See: Writing design docs at Kombo

Understand our customers’ use-case

We don’t build a general-purpose API. We build a product that enables specific features in our customers’ products. HRISs and ATSs are highly customizable. Solving for every possible customization would make our product impossible to engineer. Focusing on specific customer problems eliminates most complexity. Every new feature must begin by understanding exactly how our customers will implement and utilize it.

Understanding customer use cases is hard from product requirements and call recordings. Every engineer should work directly with customers. That’s where the nuances become clear.

No Assumptions

When you control the whole system, you can validate everything. We don’t have that luxury. We wrap around HRISs and ATSs that we must treat as black boxes. Every company uses these tools differently.

Our value proposition is consistency: Kombo works the same way regardless of which integration is connected. This is only possible by validating everything instead of making assumptions.

midwit