Our own builds
These are not client projects. We build them to test the way we work: specification first, every check written down, failure designed as carefully as success.
A file vault where every request passes eight checks
Secure file storage with accounts, sign-in, uploads and downloads.
- 1Client
- 2Proxy
- 3Shape
- 4Identity
- 5Authorization
- 6Duplicate
- 7Dependencies
- 8Effect
A request is refused at the first check that can refuse it. Nothing changes until all eight pass.
A file is visible only to the person who uploaded it and to administrators. That one rule is enforced on every request, in one place in the code, and never only by hiding things in the interface.


What it guarantees
- The same answer for every refusal. A file you may not see, a file that doesn't exist and a malformed address all return the same “not found”, so the system never confirms that a file is there.
- No double effects. A double click, a browser retry or a resubmitted form never creates a second copy. Each action carries a key, and a repeat gets the first result back.
- Uploads that can't half-happen. Size is limited while the file streams in, the type is read from the file's own first bytes, and a failed upload leaves nothing behind.
- Nothing worth stealing in the database. Passwords are hashed with argon2id, and sessions are stored only as hashes, so a leaked database hands out no live sign-ins.
- Quiet logs. Passwords, cookies and request bodies are removed before anything is logged.
How it was built
The requirements, the architecture, the security rules and the test scenarios were written first: the happy path, the failures, the edge cases and the bottlenecks. Every technical choice is recorded with the alternative that was rejected and why. The application was then built against that specification one module at a time, from setup to collaboration, with unit tests and end-to-end browser tests.
Next.js, TypeScript, PostgreSQL, Drizzle, Zod, argon2id, Vitest, Playwright
An AI extractor that is allowed to say “missing”
Structured data from unstructured text, behind a deterministic check.
Ask a language model for a field that isn't in the text and it will usually produce one anyway, inferred from whatever is nearby. The result looks right and isn't.
Two changes
- “Missing” is a correct answer. The model is told that returning “missing” is right when a value is absent, not something to avoid. It runs at temperature 0.
- A rule decides, not a model. A plain check confirms every required field is present and not “missing”. Nothing downstream sees the record until it passes.
When a field is missing, the run stops and says which one. A loud failure with a reason is cheaper than a plausible record that quietly spoils whatever uses it.
It is the same pattern we put in front of every AI step we deliver: the model proposes, a deterministic check decides.
n8n, OpenAI, deterministic pass/fail gate
Tell us what takes too long.
Describe the process and where it hurts. We reply within one business day with questions, not a sales deck.
Email office@noni-soft.com