Tranzzo Tech Radar

ADOPT — Technologies we have high confidence in to serve our purpose, also in large scale.

TRIAL — Technologies that we have seen work with success in project work to solve a real problem; first serious usage experience that confirm benefits and can uncover limitations.

ASSESS — Technologies that are promising and have clear potential value-add for us; technologies worth to invest some research and prototyping efforts in to see if it has impact.

HOLD — Technologies not recommended to be used for new projects. Technologies that we think are not (yet) worth to (further) invest in. HOLD technologies should not be used for new projects, but usually can be continued for existing projects.

🔨 How We Build

📐

API First

We design the contract before writing a single line of code. API specs are the starting point — not an afterthought. This keeps integration boundaries clear and lets teams move in parallel without stepping on each other.

🔭

Observable by Default

If a service isn't visible in production, it's very hard to operate. Tracing, metrics, and structured logs ship with every service — not added later when something breaks. Observability is a core part of delivery, not an afterthought.

🌿

GitOps

Git is the single source of truth for both application and infrastructure state. Everything lives in Git, goes through a PR, and is applied through pipelines. Changes are auditable, reviewable, and reversible.

🔒

Security as a Foundation

Secret rotation, dependency scanning, and audit trails are part of the workflow — not a checklist before a release. Security works best when it's built in, not bolted on.

⚙️ How We Operate

👑

Full Ownership

The team that builds a service also runs it in production. Design, development, deployment, on-call — all theirs. This closes the feedback loop: the people making technical decisions are the same ones who feel the consequences in production.

🔍

Proactive Monitoring

We don't wait for merchants or users to report problems. Dedicated monitoring covers system health, conversion metrics, and individual merchant behavior around the clock. Not every alert becomes an incident — but every alert gets evaluated.

🐤

Canary Deployments

Changes roll out gradually, validated with real traffic at each step before expanding. Smaller blast radius, faster rollback if something goes wrong.

🚨

Incident Response

When something goes wrong, we have a clear structure: defined roles, automatic escalation, and a dedicated space for real-time coordination. After every significant incident, we run a blameless postmortem — looking at systems and processes, not people. Every postmortem ends with concrete action items so the same failure is much less likely to happen again.

🌱 How We Grow

📖

Write It Down

Design decisions, runbooks, architectural choices — if it's not written, it tends to exist only in someone's head. We try to capture enough context so that knowledge doesn't leave with the person.

🧭

Technology Decisions

New technologies go through a structured path: Assess → Trial → Adopt. The Tech Radar makes those decisions visible across the org — so everyone understands not just what we use, but why and at what stage.

💡

Room to Grow

New ideas get a fair hearing — regardless of who brings them. We invest in people moving forward: engineers have a clear path toward more complex work, and internal transitions between teams happen in practice, not just on paper. Making mistakes is part of learning, not a reason to hold back.

🤖

AI as a Working Tool

We've integrated AI into our SDLC — automated code review and coding assistants. What convinced us wasn't the hype — it was seeing engineers voluntarily adopt tools that actually made their work better. We share what works and drop what doesn't.