Engineering culture

This is how we think about building software. It is not a rule book, and a team with a good reason to work differently should. It is the default we bring to client work, and the reason our engineering feels like amarti wherever you meet it.

What we value

• Full-stack ownership. We take a problem end to end, not just our own layer of it. The person who builds a thing helps run it.
• No blame. When something breaks we fix the system that let it break, not the person who was nearest. The blameless incident review is how we do that in practice. Successes belong to people; problems belong to the system.
• Pragmatism. The simplest thing that solves the real problem beats the clever thing that impresses. We optimise for the team who inherits the code, not for our own enjoyment.

How we build

• Operability first. We build things someone else can run, watch and change after we have gone. If only we can operate it, we have not finished. Choose monitoring whose pricing does not discourage you from monitoring, and expect a healthy dashboard to look boring.
• Services, not just software. What matters is the thing working in production, not the code admired in isolation.
• Non-functional needs are part of done. Security, performance and reliability are designed in from the first slice, not bolted on before go-live. Secure engineering and delivery quality go into how.
• No ivory towers. The people who design a system also write code on it. Decisions are made close to the work, by the people doing it.

How we choose tools

• The right tool for the job, not the one that looks good on a CV.
• Modern, not trendy. We reach for what is proven and boring enough to trust, and we are wary of hype that has not earned its place yet. Elegance does not offset a small community and thin documentation; those become the operational burden of whoever inherits it.
• Cloud-native by default, because that is where our clients run and where the leverage is. Managed services come before self-run ones: you probably do not need Kubernetes, and if you do, you need a managed one.
• Open and honest about trade-offs. When we pick something we say what we gave up to get it, and we write down why, so the next person is not left guessing.

The practices behind all of this are written up in the knowledge base.