Sole developer on a national SSO platform for six months, with Claude writing most of the code

bhagatashisha — Sat, 01 Aug 2026 09:02:59 +0000

Solution architect, 17 years in. From roughly March 2026 to July 2026 I was the only hands-on developer on the identity and single-sign-on layer for a Gulf country's national port community system — the platform that fronts its ports and logistics sector. It's live in production.

I want to be precise about "sole," because it matters: other people committed to both repos — CI, automation tests, a few fixes, downstream integration work. I authored ~80% of backend commits and ~70% of frontend. Nobody else did hands-on feature development on the core system. That's the honest version.

Volume, straight from git log --numstat:

602 commits, ~184,000 lines changed across 1,423 files
Backend: 383 Java files / ~21k LOC, 19 controllers, 83 REST endpoints
Frontend: 152 TS/HTML files / ~15.3k LOC, 62 Angular components
6 external integrations, each with a real and a mock adapter
4 environments, 2 independent penetration tests remediated

My own written estimate to leadership in April, before any of this was contentious: 3–4 engineers over 3 months without AI tooling.

Architecture

Hexagonal (ports and adapters) + CQRS. The domain package has zero Spring or JPA imports — greppable, returns nothing. That's the actual test of whether hexagonal is a design decision or a buzzword, and most codebases claiming it fail that check.

domain/         Pure domain — models, value objects, events, ports. No framework imports.
application/    Use cases — Commands (writes) and Queries (reads), DTOs, assemblers.
dataprovider/   Adapters — JPA entities, Spring Data repos, SOAP clients.
web/            Inbound adapter — controllers, DTOs, mappers, JWT filter, SAML handler.

Every feature is a paired XxxCommand/XxxCommandImpl (transactional writes) and XxxQuery/XxxQueryImpl (read-only). Every external dependency sits behind a port with a real and a mock adapter selected by Spring profile — which meant QA and UAT ran full end-to-end flows without depending on government systems being up. They frequently weren't.

One JPA detail worth stealing: @Version optimistic locking with a find-then-update save pattern, specifically to dodge Spring Data's null-version-means-new-entity behaviour producing duplicate-key errors. Easy to get wrong, painful to debug.

User lifecycle is a real state machine (PENDING_VERIFICATION → ACTIVE → LOCKED/INACTIVE) using the State pattern, so invalid transitions fail at the domain layer rather than being guarded by scattered if statements in the UI.

The four problems worth reading

1. Java's X.509 parser rejected the government certificate

AVA not a sequence — a malformed but entirely common real-world encoding that the JDK's strict parser refuses outright. I wrote a manual metadata parser on BouncyCastle's X.509 factory instead.

Then the ministry rotated their signing certificate in production and it went down anyway. So I made the certificate hot-reloadable with on-failure refresh. It rotated again twenty days later — that time the system self-healed instead of paging anyone.

2. Intermittent 500s that everyone blamed on the network

Tester in India, servers in Oman, so "it's latency" was the immediate consensus.

I checked instead. The configured timeout was 60 seconds. Real India–Oman round-trip latency is 100–250ms — roughly 240× shorter. Even severe degradation can't produce a 60-second delay. And a 500 or 503 is generated by the server, after it has already accepted the connection, so by definition it isn't a network-path problem.

The government APIs were simply unstable. That conclusion justified retry-with-backoff instead of weeks chasing a phantom network issue.

Buried in the same integration: their production API returns "WORKING" for an active work permit, not "Active". One string mismatch silently blocked every real user from registering.

3. Three clocks that could race through a payment

A 10-minute invoice expiry, a ~2-minute frontend polling window, and a 60-second backend reconciliation job. A slow 3-D Secure confirmation could outlast the frontend's patience even on a successful payment.

The fix was two backend schedulers acting as a safety net independent of whether the browser is still open, plus two independent finalization paths — the bank's own server-to-server callback (authoritative, works even if the user closed the tab) and the SPA's polling (fallback) — both funnelled through a single idempotency guard so downstream sync fires exactly once no matter which path wins.

Related, and dumber: a direct browser GET to the bank's payment endpoint silently dropped the POST body. Fix was a backend-rendered auto-submit form so the browser never GETs that endpoint at all.

4. Chrome blocks TLS renegotiation for XHR but not for navigation

Every API call died with net::ERR_FAILED while SAML redirects worked perfectly.

That asymmetry is what made it expensive — a system where authentication redirects succeed and every subsequent API call fails looks exactly like a backend auth bug. It was infrastructure config.

The rework nobody warns you about

16 distinct revert-and-rebuild cycles across both repos. Two favourites:

The downstream token-exchange handshake went through four different protocols in one afternoon — two-step, service-JWT bearer, app_secret bearer, no auth header — then got reverted twice more over the following days before settling on a single-step exchange.
A business-line normalization rule: four strategies built across four PRs in a single day, all reverted the same day once the counterparty confirmed their API wanted the value exactly as stored, pulled out of main entirely, then rebuilt a third way two weeks later.

None of that was AI's fault or mine. It's what happens when you integrate against teams whose own requirements aren't settled yet.

Where Claude actually helped, and where it didn't

It wrote most of the code. Not just scaffolding — the adapter pairs, the CQRS command and query implementations across dozens of features, the JPA mapping conventions, Angular components, large parts of the integration clients. That compression is the entire reason one person covered a 3–4 person scope.

It found none of the four problems above. Every one started with knowing what to suspect. The certificate failure surfaced as a generic SAML error. The 500s were confidently misdiagnosed by everyone in the room. The clock race never appeared in testing. The TLS bug presented as an auth problem.

You can't prompt your way to a fix for something you haven't correctly identified — you describe symptoms you have already interpreted, and the interpretation is the job.

There's also a version of this nobody mentions: I hit model usage limits repeatedly across five months. Rate limits were a real schedule constraint, not a footnote.

What I'd do differently

Test coverage is about 23% instruction coverage on the backend. That's low and I'm not going to dress it up. With a second engineer I'd have invested in automated coverage far earlier, and had someone review the downstream integration protocols before implementation rather than discovering the mismatches through four rounds of live rework.

Happy to go deeper on any of it.

DEV Community: bhagatashisha