A real delivery process, run by AI agents

1. Start with the wizard

Describe the app in a few sentences — or in a long brief. Add the documents you have: requirements, regulations, API specs, brand files, mockups (up to 20 files, 100 MB). The wizard asks clarifying questions written for your idea, then shows the details it will build from: a name, a description, the features and the intelligence level. The agents read your documents before they plan; the documents stay out of your project's repository.

It asks which apps the project has — a web app for phones and computers, a phone app for Android and iPhone, an admin web app for your team — and you can pick several: they live in one project. When the app has a public website, it also asks whether you have a domain for it.

2. The board and your approvals

The Product Owner agent turns your brief into a board of epics, stories and tickets, and rates each ticket light, standard or deep so the right model does the work.

Anything that needs you — a build plan to approve, a question, a design — waits in the dashboard's alert bar and reaches you by email too. A build plan is approved in one click.

3. Approve a look before any interface is built

A designer agent draws static screens for each app in the project. You approve a look; the junior developer then turns it into the app's interface components.

4. Build and QA

The architect sets up a TypeScript monorepo. Developers build the features, one specialist in the code at a time so changes do not collide.

QA checks each ticket against its acceptance criteria and writes and runs tests, browser tests with Playwright included. A security reviewer reads risky changes and reports what it finds; it never edits code.

5. Release and deploy

When you ask for a release, the DevOps agent declares what the project deploys. The platform cuts a tagged release, scans it for leaked keys and builds it once.

A person presses Deploy to send it to test. The platform migrates the database, publishes the release and checks that it answers.

Only a release that ran on test can be promoted to production — the same build, not a rebuild. If a production deploy fails, the code goes back to the previous release; database changes are not undone.

6. Your phone app, from testers to the stores

A project can have one phone app for Android and iPhone, built with React Native and Expo, with the API it calls. While the agents build it, you try it in the dashboard at a phone's size, and QA tests it there.

Each deploy to test or production builds and signs it for both platforms. Your testers install the Android build from a link or its QR code. For iPhone, your organization connects its App Store Connect key once; OneActor then uploads each build, and TestFlight gives it to your testers.

You publish it from your own Apple Developer Program and Google Play accounts: you upload the Android build and send it for review in Play Console, and submit the iPhone build for review in App Store Connect. The dashboard lists the steps that are yours, with what to enter. Each store decides on its review, and its fees are paid to Apple or Google.

7. Your own domain

Every environment has an address of its own. To use a domain you already own, connect it under Environments › Domains: its DNS stays where it is, and you add the few records the page shows — one to prove the domain is yours, one for the certificate, one for the site.

The next deploy puts the site on it, with its certificate: production at www.your-domain, test at test.your-domain, so you can check the domain before going live. Connecting a domain costs nothing. Buying one through OneActor is not offered.