HOW WE BUILD
The idea is very simple
The problem until now — “we can fix it, but we cannot ship it”
Suppose a small mistake is found in how data is imported. We already know how to fix it. And yet, until now, we could not deliver that fix until the next bundled release date — sometimes two weeks away. In the meantime, a small defect tended to stay in place. We can fix it, but we cannot ship it. For those of us who build the product, that was deeply frustrating.
Why is faster safer?
When people hear “make it faster,” many feel it must mean “sloppier, and therefore more dangerous.” In fact the opposite is true. To take a familiar example: the apps on your phone are updated a little at a time, many times over, without your noticing. Serious trouble is rare precisely because small fixes are applied steadily.
Conversely, if six months of changes go out all at once and something breaks, it is hard to tell which change caused it, and the impact is larger. Fixing in small, frequent increments makes mistakes easier to notice, and makes it easy to revert if anything happens. That is why fast means safe. What we aim for is a state where a fix can be delivered safely the same day.
The reason
The smaller a change is, the smaller the blast radius if a defect does occur. Shipping small and often is, in the end, safer than shipping large changes in a bundle. Speed is not the goal; it is the means by which safety is raised.
The mechanisms that keep it safe
Four mechanisms are what make “fast yet safe” possible.
Automated checks
Before a person reviews anything, computers run test after test.
A first read by AI
To reduce what people miss, AI checks for problems first.
Try it on a small part first
Rather than going to everyone at once, we deliver to a very small share first, confirm there are no problems, then widen it.
Revert immediately
If something does go wrong, it is returned automatically to its previous state.
One more thing that matters. Because we handle medical information, a record of when, who, what and why something was changed is kept automatically and without gaps. It is in fact more reliable than when the work was done by hand. Moving fast and keeping proper control are two things that do go together.
What this means for you
KarteCo’s development rule is this: alongside fast development with AI, when there is a fix, we can change and correct things sooner and more safely. That is the rule that matters most.
FOR ENGINEERS
The technical picture (overview)
Not a deep dive. Details live in the design documents.
Architecture overview
The target is Dev fix → Stg verification → production release in about one hour, implemented as four pillars and five layers.
Four pillars
Microservices
Domain split / independent deploys / data owned by the service. In short: keep changes small.
Fully automated CI/CD
IaC / immutable / trunk-based. In short: take hands off the process.
AI verification
Code review / test generation / regression judgement. AI first, a person last. In short: speed without dropping quality.
AI operations (AIOps)
Continuous monitoring / anomaly detection / automatic rollback. In short: raise the speed of defending it too.
Five layers
The one-hour pipeline (overview)
From commit through production monitoring in about 60 minutes. People touch only two points — the commit and the approval. Everything else is fully automated.
Commit
Build & unit tests
AI verification
Deploy to Stg
Stg verification
Approval
Production (canary)
Monitoring
TOTAL about 60 min
The reason
The only rate-limiting steps are the ones that are not automated. Take people out of the manual work so they can concentrate on the judgement (the approval), and hand verification, deployment and monitoring to AI and automation. Only then does one hour become a realistic number.
Safety devices and quality gates (overview)
Safety devices (why fast is still safe)
- Canary: a few per cent first, then widen in stages
- Blue-green: switch over and back instantly
- Automatic rollback: revert automatically once a threshold is crossed
- Immutable: rebuilt every time, so it can be reverted
Quality gates (fail-closed: when in doubt, stop)
- G1 CI: unit coverage ≥ 80%
- G2 AI verification: 0 critical findings, 0 high-severity vulnerabilities
- G3 Stg: all E2E passing, performance regression < 5%
- G4 / G5 Approval / production canary metrics within range
Compliance & roadmap (overview)
Compatibility with Japan’s three-ministry guidelines for handling medical information is secured by treating automation not as “fewer records” but as “records kept reliably.” Change management, approval trails, least privilege and traceability are all captured as evidence automatically — which in fact makes audit conformance higher than under manual operation.
| Phase | Main measures | Lead time reached |
|---|---|---|
| Phase 0 Foundations | IaC / containerization / CI in place | days → 1 day |
| Phase 1 Automation | Automated CD / automated Stg verification / canary | 1 day → half a day |
| Phase 2 AI verification | AI review / test generation / regression judgement | half a day → hours |
| Phase 3 AI operations | AIOps / automatic rollback completed | hours → 1 hour |
- The one-hour release is designed for safety, not for speed.
- The key is the four pillars: microservices × automated CI/CD × AI verification × AI operations.
- In stages, fail-closed, and keeping the records. We do not go for one hour in a single leap.