KAIHITO comes out of practice — not out of a consulting model.

About

What KAIHITO means

開 — to open, to unlock人 — human being

KAIHITO combines two Japanese words: 開 (kai) — to open, to unlock, to begin — and 人 (hito) — human being. Opening and people. Together they describe what we do: open up systems so people can actually work with them.

Technology alone opens nothing. A system only becomes effective once people understand it, trust it and let it into their day. That is why people are not at the end of a project, but at its centre.

The red seal is our mark of quality. In Japan, the hanko stands for a personal commitment: whoever seals, stands behind the result. We place it where we take responsibility — not as decoration.

Mark of quality: where it appears, we carry responsibility.

The story behind it

KAIHITO grows out of running an IT company: responsible for delivery, sales, marketing and team at the same time — with a daily view of what actually makes initiatives fail.

That is where the focus on leadership, organisation and a way of working that enables performance without consuming people comes from. Async collaboration, clear decision paths and psychological safety are not ideals here; they are the conditions under which complex projects work.

KAIHITO FlexCo will be founded in September. Until then, this site is mainly one thing: a place where the position can be read.

Why KAIHITO works differently

We are not a full-service agency offering everything at once, and not a pure code supplier that disappears after go-live.

Independence is not a side effect for us, it is part of how we build: data, identity and business logic stay with the client. We favour open source and self-hostable building blocks so nobody ends up dependent on a vendor whose pricing, data location and exit risk they cannot steer.

And we say what an initiative will not solve. We prefer one core slice into production over a concept phase — and afterwards someone inside the organisation should be able to answer for it, not us indefinitely.

How we scope — and where we stop

We work in bounded cuts with a fixed window: a tenant and permission model, an audit-proof history for one process, provability ahead of an audit. Complexity gets cut until something workable stands — not until everything has been considered.

Foundational work without a fixed point drifts. So we tie it to an initiative someone inside the company actually wants: a deal, an audit finding with a deadline, a customer with security requirements. And we only work as a business-and-tech tandem. If nobody from the business carries the decisions with us, we say so early.

What we are not the right answer for: general contracting for your entire IT, business-critical core systems that require references at a comparable scale, pure capacity at an hourly rate, and “modernisation” without a concrete trigger. We would rather say that upfront than in month three.

What you should measure us against

The same questions we would ask in a client's position — and our answer to them.

Knowledge transfer
Decisions are captured as ADRs, operational knowledge is documented and mirrored in the team. The goal of every mandate is that we become replaceable.
IP and rights
Code, data, identity and business logic are yours — contractually and technically. We build on open source and self-hostable components so no dependency risk arises that you cannot steer.
Handover and operations
Whoever builds also runs it at first. The mandate ends on plan with a named internal owner, not by fading into maintenance hours.
References, honestly framed
KAIHITO is young. We show anonymised practice examples and name the scale we have actually worked at — instead of claiming one we do not have.
Provability over certificate logic
A vendor certificate is not evidence about your system. What counts is what your software itself can present in an audit.
See the provability hub

Network and ways of working

Implementation happens through a network of experienced architects and engineers we know and have worked with. No anonymous capacity, no handover to an unknown team.

  • Async by default: decisions are documented and re-readable
  • Clear ownership per topic, by name rather than by role
  • Experienced architects and engineers instead of junior scaling
  • Honest statements about what an initiative will not solve

Roles in the core team

  • Architecture & JVM

    Domain boundaries, event modeling, domain-driven design and architecture decisions that hold up in production.

    Java, Kotlin, Spring, event sourcing, CQRS, domain-driven design

  • Platform & backend

    Production readiness: deployment, observability, security and operability from the first sprint.

    Kubernetes, Docker, CI/CD, PostgreSQL, EventSourcingDB, Keycloak

  • Full-stack & delivery

    From frontend to pipeline: features that reach users and handovers that hold.

    TypeScript, Angular, Node.js, REST/GraphQL, DevOps automation

Location

KAIHITO works out of Vienna, Austria — with clients across Austria, Germany and Switzerland.

Collaboration runs async and remote, with on-site sessions in Vienna and the DACH region where they matter: kickoffs, event modeling workshops and decisions with many stakeholders.

This becomes concrete in our services — and in the foundational article Why digitalisation projects fail at the transitions.