Build · Hyperpersonalised Apps

One contract. An app for each person.

The organisation fixes the interface and the rules. We generate the application each person needs, when they need it, inside those rules.


Overview

Most software is built once for an average user who does not exist. We take the interface an organisation already provides, its API contract, component library and permission policy, and generate an application for one person from their stated need. The result is a declarative spec drawn by a fixed renderer, so it can be validated, versioned and audited like any other release. Generated code never runs. The model composes approved parts, it does not invent new ones.

What it includes

The work, named plainly.

Your contract is the boundary

An OpenAPI or MCP definition lists every operation a user may call. A component library fixes the look. A policy file maps roles to data. Nothing outside those three can appear in a generated app.

Built from a sentence

A person states what they need in plain language: approve supplier invoices from a phone, see the cases due this week. Their role, device and accessibility settings shape the result. The app exists within the minute.

Validated before it is shown

Every generated spec is type-checked against the component schema, every bound operation is checked against the role policy, and every write gets a confirmation step. Fail one check and the app is not rendered.

Versioned like a release

Each app is a stored artefact with a history. The person refines it in conversation, the diff is kept, and the organisation can promote a personal app to a shared template.

Generated where the data lives

The need, the context and the resulting app stay on private inference hardware inside the organisation’s boundary. No prompt leaves for a public endpoint.

Private AI systems

How we work

Engineered once. Maintained indefinitely.

  1. Catalogue the operations, components and roles the organisation already has
  2. Write the contract, policy and component schema the generator must obey
  3. Define the validation gates: types, permissions, confirmation, accessibility
  4. Generate against written needs and measure what fails the gates
  5. Pilot with a named group and review every generated app
  6. Roll out with versioning, audit and a route to shared templates

Speak with us

Tell us what your people keep asking for.

We reply within one working day, from an engineer who can read your API contract.

Send securely