For regulated mid-sized companies · Stuttgart, Germany

AI does the groundwork.
Your team decides.

We build software for your business processes. It records who decided what, and on what basis. Any later change to that record can be detected.

New projects start from November 2026. We are happy to talk now and show you Approval in a short call.

Approval first checks whether the software is already approved for the same use; if it is, that approval and its conditions apply and no new review starts. Otherwise it stores the vendor documents, and a new vendor’s sources and identity are checked first. A model extracts facts with supporting quotes; a quote that is not in the documents is rejected, and a person accepts, corrects or rejects each fact before the model drafts two assessments. The data protection and security officers each review and sign their part; one refusal rejects the request. The request, every document version, every decision and every signature are recorded in a tamper-evident log. When a vendor document changes, the affected fact is invalidated, the approval is out of date and a re-assessment supersedes it; an approval nearing its end is renewed from the current facts.

An example: Approval, one of our applications

A department requests software. Approval reads five vendor documents, drafts both assessments and puts them in front of your officers.

  1. Facts extracted for your reviewFive documents, fourteen facts, each with its quote. A quote the document does not contain is rejected.
  2. Your team decidesThe model proposes and drafts. A person accepts each fact, and only the officers can sign.
  3. The evidence is recordedThe request, each document version, each decision and each signature is a ledger entry, chained by hash, so none can be changed quietly afterwards.
  4. It notices when the facts changeA changed document invalidates the facts it no longer supports and reopens the approval based on them.

This shows the process used in Approval, with fictional requests, documents and figures.

The same division of work fits your own processes, as a new application or inside software you already run.

  • Custom software

    We build your application in weeks.

    Security, data protection and the review of AI proposals are already built into our template. Coding agents add your process on top of it; automated checks send back whatever breaks its rules, and we review what passes. It runs on your infrastructure, you own the code, and there is no platform subscription.

  • AI oversight

    AI that changes data only after a person approves.

    For software you already run: a model prepares a proposal, a person reviews and signs it, and a hash-chained ledger records the decision. Open-source libraries in your own stack.

Custom software

The agent writes the code. The rules it works under are ours.

Writing code has become cheap. Coding agents are fast, but left to themselves they pick the wrong tools, skip requirements and leave gaps that show only in production. So no agent of ours starts from an empty folder. Every agent uses our template, libraries, instructions and automated checks. We maintain all four.

  1. @octabits-io/create

    An application template

    Every application starts with row-level security on every table, sign-in through your identity provider, AI steps a person approves and a log from which each change can be undone. The agent adds your process to this template.

  2. @octabits-io/*

    25 tested libraries

    Queues, encryption, data-subject requests, events and the audit log come from our open-source packages, each with its own tests. The agent wires them in instead of writing its own. All of them run on your Postgres, so none adds a sub-processor.

  3. AGENTS.md · skills/

    Rules and recipes it reads first

    The template gives the agent instructions: how to add a table, how to change one that already holds data, how to add an AI step. Each recipe ends with a command to check the result. Claude Code and Codex read the same files.

  4. pnpm guard

    Automated checks after each step

    When the agent ends its turn, the guard checks the rules: every table scoped, organisations isolated from each other, migrations safe on tables that hold data, no model call that bypasses the disclosure rules. What fails goes back to the agent. The same checks run before every merge.

  5. Then we review every change

    We read every change that passes the checks before merging it. The agent writes most of the code; what goes into your application is decided by people.

Recorded development

Watch an agent use the template

We asked Claude Code, Anthropic’s coding agent, to build a customer management application from a fresh copy of our template. It needed companies, contacts and a company picker. Deleting a company had to preserve its contacts. It chose the data model and worked without intervention for just under nine minutes. The thirty-five-second excerpt is followed by a recording of the finished application.

Claude Code builds customer management on the octabits starter: the task, the skills it reads, the migration, the guard with 9 of 9 checks, its review, a smoke test that fails and one that passes, and its closing message.

The recording is abridged. ⋯ marks omitted passages and … shortened commands; the remaining text is unchanged. The full run, unedited (8.7 min, asciinema)
The recording shows the resulting application: we add a company, select it for a new contact and find the contact on the company page. Deleting the company preserves the contact. The records are hidden from the other organisation.

What the agent did

  1. Before writing code it read the starter’s skills for adding a table and for changing one that already holds data.
  2. Its migration only adds, so every existing contact stays valid. The guard passed 9 of 9 checks, with no destructive statement.
  3. It noticed that the database link alone would accept another organisation’s company, so the server checks it before saving.
  4. It tried deleting a company on the running app and the contact stayed. Its first attempt at that check failed on a shell error; the cut shows it.

The guard has grown since the Codex run, from 6 checks to 9: it now also replays every migration over tables that already hold rows. The run took 40 turns and cost $2.38, as shown at the end of the recording.

How it works

From your process to a running application

  1. 01

    You describe the process

    Tell us how the work gets done, what data and documents you use, and who approves the result. A spreadsheet you use today is a useful starting point. In the first call, we outline how to build your application with our existing libraries.

  2. 02

    Agents write the code, we review it

    Coding agents write most of the code inside our template. Automated checks send back whatever breaks its rules, and we review every change before it is accepted. You can use the first version within a week.

  3. 03

    You run it on your infrastructure

    The application uses your servers, Postgres database and sign-in provider. Your staff review AI proposals, and the log records their approvals. You own the code.

Half a day
for Approval’s first version
25
open-source packages, MIT
0
signatures by a model
None
sub-processors of ours
Reynt
in production on the same parts

AI oversight

Every AI step reviewed by a person, and recorded

Approval uses the oversight kit to review software requests, as shown in the diagram above. The model drafts assessments with source references. The officers review and sign them, and each decision is logged. We can integrate the same libraries into your existing software.

Available from November 2026

Approval helps you review and approve software

AI prepares the assessment for your officers to review and sign.

Approval helps regulated organisations assess and approve software. It collects vendor documents, extracts facts with source references and drafts security and data protection assessments. The responsible officers review, edit and sign the documents. Approval runs in your own datacentre on your Postgres database.

Signatures by a model
0
Runs
On premises
Database
Your Postgres
Our sub-processors
None
Languages
German, English
Example review: proposed changes with source references, followed by the log entry created when the officer signs.

Pricing

Development at a fixed price, with monthly maintenance.

You own the application code. There are no licence fees or limits on users and workflows. The platform packages will be released under the MIT licence.

Development

Fixed price

per application, in the written proposal

  • Your application running on your infrastructure and Postgres database
  • Sign-in with your identity provider, e.g. Microsoft Entra ID
  • Tests, CI and documentation; the code is yours
  • A first version within the first week, done in 4–6 weeks

Maintenance

Monthly

a flat fee, no charge per user

  • Platform package updates and security fixes
  • Support from the people who built your application
  • No limit on users or workflows
  • A separate fixed price for each additional application

For business customers. After a first call you receive a written proposal with scope, duration and price, usually within two working days.

Open source

The platform our products are built on

Approval and Reynt use our open-source libraries. We group them into two kits. The build kit handles row-level security, field encryption, data-subject requests, queues, events and telemetry. The oversight kit adds review of AI proposals and records the decisions. The packages run on your existing Postgres database. Each comes with tests and documentation explaining its uses and limits, and all of them will be released as open source under the MIT licence in November 2026.

octaflowDurable workflows on the Postgres you already have.Documentation →

Also maintained:cert-manager-webhook-porkbunWildcard certificates for Porkbun domains on Kubernetes.

How we build

16 engineering patterns

We explain the patterns we use, with examples from our code and the trade-offs involved. They apply across programming languages.

  • Errors as values
  • Functional core, imperative shell
  • Make illegal states unrepresentable
  • Parse, don’t validate
  • Architectural fitness functions
  • Put the invariant where it cannot be routed around
  • Crypto-shredding and blind indexes
  • Append-only ledger, single writer
  • Anti-corruption layer
  • Store-and-forward, backoff with jitter
  • Boring infrastructure
  • Programs as values
  • GitOps and a signed supply chain
  • Negative documentation
  • Intent-revealing commits and a work ledger
  • Encoded procedures

In production

Reynt, our booking platform

We develop and operate Reynt, a booking platform with thirteen packages, four APIs and three frontends. AI coding agents write most of its code. We began publishing individual libraries after using them in production in Reynt.

Automated checks enforce the architecture boundaries, the database enforces key constraints, and integration tests run against a real database in CI. These checks support our review of agent-written code.

Reynt in numbers

Packages
13
APIs / frontends
4 / 3
Tests
Integration, real DB
Tenant isolation
Postgres RLS
Hosting
EU

Contact us

Tell us briefly what you are working on and where you need help. Email is the fastest way to reach us; the person who would work with you will reply.