ServicesniikoProcessChangelog
Get niiko

engineering notes

Where we are pointing: the architecture bets we are making on purpose

2026-09-02 · Vorluno

There is a class of architectural decision that is cheap on the first day and effectively impossible later. Not "hard" — impossible in the practical sense that the migration would have to run across live customer data under a deadline set by somebody else. We keep a written list of those and treat them as non-negotiable from the first commit, and it is the closest thing we have to a statement about where the product is going.

Every record carries the organisation it belongs to, and isolation is enforced by the database itself rather than by remembering to add a filter. Business data is never deleted — status flags and reversible history, with one nominated exception for the right to erasure, which is why every data subject gets their own encryption key at creation: destroying that one key makes their data unreadable everywhere a copy exists, including the append-only stores and backups a delete statement can never reach. Money never moves without a double-entry ledger, and card numbers never touch our infrastructure. No event exists without a schema in a shared catalogue, so a producer cannot quietly change the shape of something three modules consume.

The bet underneath all of them is the same: the expensive failures in a multi-tenant product are not features that were built badly, they are properties that were assumed instead of enforced. Isolation assumed. Auditability assumed. Deletability assumed. Each is trivial to guarantee before there is data and brutal to establish afterwards, and each one buys optionality — the ability to sell to a customer whose procurement asks the question, without a quarter of remediation first.

Where we are pointing next follows the same shape. The capability layer under the agent exists so that autonomy can be granted in units small enough to reason about, which is the precondition for letting an agent do more, not less — you cannot responsibly widen what an agent may do until you can describe the boundary. The knowledge catalogue exists so the agent learns from what a business actually wrote down rather than from a prompt someone tuned. And the discipline of stating what each check cannot see exists because the systems worth building will keep outgrowing the tests that were written for them.

What we are deliberately not betting on: that a larger model will make the boundary unnecessary. Better models make the agent more useful inside the boundary and change nothing about who is accountable when it acts. The parts of this system that will still be load-bearing in five years are the unglamorous ones — the ledger, the keys, the event catalogue, the line between a suggestion and an action — and they are the parts that had to be right before anyone was watching.

← All notes

A software studio in Panamá, shipping in English worldwide. The team behind niiko.

Product

  • niiko
  • Modules, in depth
  • Changelog
  • Roadmap

Modules

  • Miira
  • CRM
  • Ciita
  • Kiipu
  • Fiilz
  • Riinda
  • Niima
  • Inbox
  • Notes

Developers

  • Engineering notes
  • Documentation
  • Status soon

Company

  • Services
  • Embedded team
  • Process
  • About
  • For investors
  • Tools
  • Contact
© 2026 Vorluno · Panamá · Privacy · Terms// shipped, not staged.