We Pointed StackGrit at X-Road. Estonia's Digital Backbone Scored a C+.
X-Road scored a C+. 72 out of 100.
The data exchange platform that runs national digital government in Estonia, Finland, and Iceland. Six years of development. 54 contributors across three companies. 310,000 lines of code spanning a dozen deployable services. A UN-certified Digital Public Good. And the codebase comes out as a C+.
We pointed StackGrit at the X-Road monorepo — every Java file, every Vue component, every database migration, every commit. The analysis finished in 65 minutes and cost $8.50 in tokens. Here are the findings worth pulling out, and why each one shows up in almost every long-lived codebase.
Want to dig into the report yourself instead? Open the full X-Road analysis →
The scorecard
Architecture and Data Model land at B. Technologies pulls a B-. Code Quality, Security, and Team all sit at C+. Test Coverage drops to D+ and drags the overall grade down.
For comparison, React — maintained by Meta — also scored a C+. The patterns that show up in long-lived codebases at this scale are surprisingly consistent regardless of whether the project runs a JavaScript ecosystem or a country.
Zero circular dependencies across 65 modules
This is the headline architectural finding. The X-Road codebase is split into 65+ Gradle subprojects organised in a strict hexagonal pattern: core-api defines interfaces, core implements them, infra-api-rest and infra-jpa are adapters, application wires it all together. Module boundaries are enforced at build time by ArchUnit rules — accidentally make core depend on infra-jpa and the build fails.
In a 310,000-line codebase, zero circular dependencies is rare. Most enterprise Java projects at this scale carry dozens. This is the difference between “we can refactor module X this quarter” and “we’d love to but it’s load-bearing for everything else.”
The architecture diagram in the screenshot above came directly from the report — generated from the actual module dependency graph, not a hand-drawn slide.
The report did surface seven concrete architectural findings, sized by effort. The biggest is structural: JPA-annotated entity classes live in the core module instead of infra-jpa, which leaks Hibernate into the supposedly framework-free domain layer. The hexagonal architecture’s headline benefit — being able to swap persistence technology without touching the core — is silently undermined by a directory choice. The fix is mechanical (move files, update imports) and estimated at 2-3 days.
The dual-framework migration that doubles the surface area
X-Road is mid-migration between two backend frameworks. Spring Boot 4 powers the admin services. Quarkus 3 powers the runtime services — proxy, signer, monitor, configuration client. Both are first-class. Every cross-cutting library now ships in pairs: lib/rpc-spring and lib/rpc-quarkus, lib/vault-spring and lib/vault-quarkus, lib/properties-spring and lib/properties-quarkus.
It isn’t an accident. Quarkus’s lower latency suits the proxy/signer message path; Spring Boot’s ecosystem fits the admin tier. But every security patch must apply twice, and onboarding requires dual-framework expertise.
There’s no documented end date for the migration. A senior team can carry this indefinitely — but the cost compounds with every new shared concern.
Three thousand-line classes in the admin layer
ServiceDescriptionService.java is 1,355 lines — one class handling WSDL parsing, REST description parsing, OpenAPI parsing, validation, and persistence, with a cyclomatic complexity of 54. TokenCertificateService.java is 1,159 lines covering certificate lifecycle, OCSP, and key operations. ClientService.java is 1,053 lines with around 40 public methods.
These aren’t badly written. They’re well-named, consistently error-handled, and follow project conventions. The codebase has only 10 TODO/FIXME comments across 9 files in production code — genuinely impressive for a 6-year project. But these three classes are doing too much. Every new feature gets appended to a file that’s already over a thousand lines, and merge conflicts, slow tests, and onboarding friction follow.
The report also flagged 148 @SuppressWarnings annotations across 123 files in the main source tree. Some are defensible — PKCS#11 APIs force checked exceptions you can’t avoid — but at this volume the pattern suggests static analysis warnings are being suppressed rather than resolved, which slowly erodes the value of having SonarQube in the pipeline.
A 24% test coverage problem in exactly the wrong place
X-Road has a mature, multi-layered testing setup: JUnit 5 with Mockito, Testcontainers for real database integration tests, Cucumber for BDD acceptance tests, Selenide for browser tests, and ArchUnit for architectural constraint enforcement. The proxy service has more test files than source files — 177 to 155.
But the signer module — the service that holds private keys, talks to hardware HSMs, and signs every X-Road message — has 30 test files for 198 source files. 15%. The frontend SPAs sit at under 1%. Two new Data Space modules added in 8.x have zero tests at all.
The most security-critical service in the system has the lowest test coverage. That gap shows up in almost every codebase we analyse, and it’s there because test coverage tracks where the friction is, not where the risk is. Friction is in CRUD admin features. Risk is in cryptography. The natural pull of a sprint always favours the friction.
A team transition the code won’t tell you about
X-Road has been developed in partnership between NIIS, Nortal, and previously Gofore. The git history shows that the original Gofore team — seven developers, around 3,500 commits between 2020 and 2022 — has entirely churned out. The current active team is roughly 10 contributors, primarily Nortal-based with NIIS stewardship. The transition itself isn’t a problem on its own — successful long-term projects survive plenty of vendor changes. What the report flags is the knowledge concentration that came with it.
The matrix above shows where each currently-active contributor sits across the codebase. Two cells are striking. justasnortal is the only meaningful contributor on Runtime Services — 82.7% of the proxy and signer cores by code blame. Ovidijus Narkevicius is the primary owner of Shared UI — 87.2% of the component library that both admin SPAs depend on. Both have a bus factor of one.
The contribution patterns view adds a layer the matrix doesn’t show: the kind of work each person is doing.
Ričardas Bučiūnas drives build infrastructure and tooling — about half of his commits are chore/CI work, which is critical but invisible. Ovidijus carries the entire frontend with a healthy 30% feature / 18% fix ratio that suggests sustainable balance, but a heavy review load as the sole owner of shared-ui. Mikk Bachmann shows up as a refactoring/migration specialist — large average commit size (1,692 lines) with a 41% feature ratio is a recognisable signature for someone doing big structural work.
This is the kind of finding code analysis catches that a static analysis tool never will. SonarQube doesn’t know about contractor offboarding. Looking at git history with the right questions, you can see knowledge concentration shifting in real time — and you can see what each remaining contributor would actually be missed for if they left tomorrow. That becomes a maintenance risk long before any tests start failing.
What X-Road does well
A C+ doesn’t mean X-Road is fragile. The architectural foundations are excellent — zero circular dependencies, formally enforced module boundaries, and a hexagonal layering that keeps a 310,000-line codebase navigable. Authentication uses Argon2id. Audit logging is dual-layer: every administrative action is captured by both Spring annotations and PostgreSQL triggers. The npm dependency tree has zero known CVEs. There are no hardcoded production secrets anywhere in the source. Error handling is disciplined — zero empty catch blocks across the proxy and signer cores. The multi-layered testing infrastructure, when it’s used, is well-chosen and modern.
The findings above are what every long-lived critical-infrastructure codebase accumulates. Spring Boot apps at scale grow god classes. Cryptographic modules tend to be undertested because writing tests for HSM integration is hard. Multi-vendor projects carry the scars of org changes. None of this is a sign of bad engineering. It’s a sign of six years of real work shipping real software for three real governments.
What the technical debt is actually costing
The most useful part of the report wasn’t a finding — it was the ledger of what the debt is costing, and what would change if specific pieces were paid off.
Three god-class services slow down feature delivery in the Security Server admin module. Every cross-cutting change has to be implemented twice for the dual-framework split. The legacy ee.ria.xroad package namespace lingers across new code, creating import confusion. Two stalled dependency migrations (HttpClient 4.x → 5.x, javax.annotation → jakarta) leave deprecated libraries running alongside their replacements.
Each of these has an effort estimate attached. Splitting the three god classes: 2-3 weeks. Completing the HttpClient migration: 2-3 days. Removing deprecated libraries already shadowed by replacements: 1-2 days. Concrete numbers a tech lead could put in a sprint plan tomorrow.
That’s the difference between a code analysis tool and a code health report. The tool finds problems. The report tells you what to do about them.
If X-Road has these issues, so does your project
X-Road is built by experienced infrastructure engineers, audited by national security agencies, and deployed in production for three governments. It still has god classes, undertested critical modules, and a bus factor that’s invisible without git history analysis. Your project probably has similar issues. The difference is whether you can see them before they become someone else’s problem.
StackGrit’s AI code analysis covered X-Road’s full 310,000-line codebase in 65 minutes. The full report includes the architecture diagram, per-module health cards, complexity hotspots, knowledge risk analysis, prioritized recommendations with effort estimates, and a security audit.
See the complete X-Road analysis →
Want the same analysis for your own codebase? First report is free, no credit card.