How a prompt becomes an app

Viber has run inside one organisation since October 2025, behind its own sign-in, for staff who need a dashboard, a calculator, a tracker or an assessment form and would otherwise wait for a developer. It is not a public service. A request goes through seven steps, and only the first and last involve the person who asked.

1. 01

   Describe

   Plain language. Attach screenshots, a design file's frames, a ticket from the tracker or a CSV whose columns and sample rows are read.

2. 02

   Plan

   A first model pass writes no code. It lists only the new files the request needs, given everything built so far.

3. 03

   Generate

   A second pass writes those files onto a fixed scaffold, so the model writes only what is specific to the request.

4. 04

   Build

   A worker builds the app in a container and type-checks it. Errors go back to the model for a fix.

   check runs today

5. 05

   Review

   A model reads the result against a list of best practices and lists what to improve.

   check runs today

6. 06

   Preview

   The app is deployed to a URL behind the organisation's sign-in and a screenshot is taken.

7. 07

   Refine

   Ask for a change in chat, edit an element on the page, or edit the code. Each round is a version you can return to.

8. 08

   Does it do what you asked?

   Not checked by the platform yet. The research programme's next item.

   planned

The scaffold

Every app starts from the same base: a current web framework, a shared component library, sign-in already wired to the organisation's identity provider, and a build pipeline. The model is told what exists and instructed not to recreate it. That is why a first version usually appears in minutes, and why the apps look like one family. The base also means the model's mistakes land in a smaller area, the application code, where the type-check can catch them.

What is checked today

• The app builds and passes a type-check before you see it. If it does not, the errors are sent back and the model repairs the files.
• A model reviews the generated code against a list of best practices and reports what it would change. These are suggestions; nothing is blocked on them.
• Uploaded images are checked for type and size, and their bytes are checked against the declared type.
• API keys and other secrets live in a per-project store and are injected at build time, so they do not sit in the generated code.
• The platform tells every user not to upload sensitive, confidential or regulated data, and describes itself as experimental.

What is not checked yet

Nothing in the pipeline asks whether the app does what the request meant. A tracker that saves to the wrong field, a form that any signed-in colleague can read, a calculator that rounds where the spreadsheet did not: all of these build, type-check and preview cleanly. The Software from intent programme's next two items are exactly these checks: acceptance tests written in the same plain language as the request, so success can be judged without reading code, and checks for common data-handling and access-control failures before an app is handed over. Until they exist, the person who asked for the app is its only test.

The models

Several third-party language models are available and chosen per request. They are reached through the organisation's own cloud accounts rather than a public service, so prompts and generated code stay inside its environment. Which model wrote a given version is recorded with the version.

Access

Viber is not open to the public. It runs inside one organisation today, and OneThought AI sets it up inside others by arrangement. Write to connect@scalingtruth.org with the subject "Viber".