Start a project
From the lab

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.

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.

File list seen by an administrator: five files from two uploaders
An administrator sees every file and who uploaded it.
File list seen by a staff member: only her own two files
A staff member sees only her own uploads. The database query does the filtering, not the page.

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