What we chose not to build
No Kubernetes, no service mesh, no event bus, no dashboard for end users, no document management features. Each omission was a decision with a reason, and the reasons are more useful than the list.
Architecture writing tends to describe what was built. The decisions that shaped a system more are usually the ones about what was left out, and those are harder to find written down because an absence produces no diagram.
Here is our list, with the reasoning, because the reasoning transfers even where the conclusions do not.
No Kubernetes
The expected load is not large. A partner base generating a few hundred deposits a day per platform produces something on the order of a handful of database inserts per minute at peak. Events run to a few multiples of that. Retrievals are rare by construction — a court-ready bundle is assembled deliberately, not continuously — and the worst case we modelled still resolves to a small fraction of one request per second.
Postgres does not notice this. A single primary with a read replica carries it with room for growth of two orders of magnitude before the topology needs revisiting.
Against that, an orchestrator introduces a control plane to operate, a networking model to debug, upgrade cycles to survive, and a category of failure that has nothing to do with our problem domain. It buys elasticity we do not need and scheduling we do not need, and it charges for both in operational attention that a small team does not have spare.
The API runs as a compiled binary on a few machines, under a process supervisor. Deployment is copying a binary and restarting. When something breaks, the debugging surface is the application and the database, which is where the bug will be.
We are aware this reads as unfashionable. The relevant question is not whether an orchestrator is good technology — it is — but whether this workload is the kind it was built for. It is not.
No microservices, no service mesh, no event bus
The same reasoning, applied to decomposition.
Splitting a system into services buys independent deployment and independent scaling, and charges for them in network boundaries, partial failure, distributed tracing, and eventual consistency where you previously had a transaction.
For an evidence system, the last of those is not a cost we can pay casually. When a deposit is stored, several things must happen or none of them must: the ciphertext lands in object storage, the row is written, the audit entry is appended, the receipt is signed. A design where those are separate services communicating over a bus has converted a transaction into a saga, and a saga into a set of compensating actions that have to be correct in circumstances nobody tested.
There is one process handling API requests and one handling background work. They share a database and a transaction boundary. When the system grows past that, splitting will be a real project — and it will be a smaller project than unpicking a distributed design that was wrong from the start.
No dashboard for end users
Lethra has no interface for the person whose document it actually is, and this is a product decision rather than a scope cut.
An end-user dashboard would mean accounts, sessions, password resets, support, and a relationship with individuals we have no contract with. It would also mean holding enough about those individuals to authenticate them, which cuts directly against holding as little as possible.
What the individual gets instead is a receipt they can verify without an account: a code on their document, a page that answers plainly, and an offline verifier for anyone who wants to check the whole chain themselves. No login, no data held about them for the privilege, nothing to breach.
The partner gets a dashboard, because the partner is who we have a contract with. It is deliberately thin — keys, usage, deposit metadata, certificates, audit export — and it is not where the product lives. The product is the API.
No document management features
No folders. No tagging beyond the metadata a partner supplies. No search across content. No previews, no thumbnails, no versioning, no collaboration, no workflow.
Every one of those requires reading the content, and we cannot read the content. That is not a limitation to be engineered around later; it is the property the whole system exists to provide.
This has a commercial consequence worth stating. It means we cannot compete with document management systems on features, and a buyer comparing feature grids will find ours short. The grid is the wrong comparison — a DMS is for documents people work with, and this is for documents nobody should be working with, held so that their existence and their destruction can be proved. Different products that happen to both involve files.
No self-serve signup, for now
There is no path from landing page to running integration without a conversation.
Partly this is stage. But the durable reason is that the first thing a partner has to get right is which artefacts they are the record-keeper for, and that is not a question a signup flow can ask usefully. A team who integrates without having answered it has built on an assumption, and the assumption surfaces at the worst moment.
The conversation is not a sales gate. It is the part where we find out whether the platform actually needs this, and say so if it does not.
No blockchain
Included because it comes up, and because the reasons it comes up are reasonable.
The requirement — an append-only record, tamper-evident, verifiable by parties who do not trust the keeper — genuinely does describe what a distributed ledger provides. The mismatch is in what else it brings.
A ledger solves for the absence of any trusted party, at the cost of consensus overhead, and it makes deletion structurally difficult. Our problem has a trusted-enough party available in the form of an independent timestamping authority, and deletion is not an inconvenience in our system but its central obligation. A design that makes forgetting hard has failed at the harder half of the requirement.
Transparency logs give the same tamper-evidence with none of that. The pattern is established, auditor-legible, and does not require anybody to hold a token.
What all of these have in common
Each is a case where the expensive option would have been defensible in a design review, and where the cheap option is correct for this workload at this stage.
The failure mode we were guarding against is specific: a small team building infrastructure that would be appropriate for an organisation ten times its size, and then spending its attention operating that infrastructure rather than on the parts of the problem that are actually hard. The hard parts here are key custody, provable destruction, and evidence that survives us. None of them get easier because the deployment topology is sophisticated.
Every one of these decisions is reversible, and several will be reversed. The order matters more than the choices: build the simple version, run it, and let the operational evidence justify the next thing. A complexity added because it might be needed is a complexity nobody can later argue for removing.