From a scoped request to a signed build
Four phases, each with something you can check. Timelines depend on the category, and the first honest answer about feasibility arrives before you pay.
- 01
Scope and price
1 to 2 working days
You pick a category in the portal and answer four short steps: what the app does, which platform, who it is for, and what already exists. We reply with inclusions, exclusions, the revision count, and a price we will hold to.
- You: Send the website, the accounts you already run, and any non-negotiables.
- Us: Check feasibility, flag store risk, and calculate the price on the server.
- 02
Build
Category dependent
AI-assisted tooling produces the first pass of screens, data models, and tests. A developer then owns the decisions: navigation, state, error handling, and every integration with a real system.
- You: Answer questions in the project thread and share assets as they exist.
- Us: Ship installable builds early, not a reveal at the end.
- 03
Review on device
Across the build
Installs go to a real phone. You try the flows that matter, report what feels wrong, and the included revisions cover the agreed scope. Anything outside scope is quoted before it is built.
- You: Test the flows your customers actually use.
- Us: Fix, harden, and re-check on both platforms.
- 04
Handover
After sign-off
You receive signed builds and the project files. Store submission stays in your own developer account, with a checklist of what each store asks for and where the review risk sits.
- You: Keep the developer accounts in your name.
- Us: Prepare the build, the listing assets you provided, and the handover notes.
What keeps a build honest
These are the rules that stop a fast build from turning into a fast mess.
Prices are calculated on the server
The portal never trusts a number from the browser. Category, platform, and scope resolve to a price the same way every time.
Scope changes are quoted first
If a request moves outside the agreed scope, it becomes a small quote rather than a surprise on the invoice.
Store outcomes are never promised
We can prepare a build that meets the published requirements. We cannot promise a reviewer will accept it.
What we need from you
Nothing exotic. The earlier these exist, the fewer rounds a build needs.
- A working website URL, or a clear description of the product if it is a new app.
- Access details for any system the app must talk to, shared privately in the portal.
- Brand assets you already have: icon, logo files, and any tone-of-voice notes.
- Store developer accounts in your name, so the app is yours from day one.
- Not required: a finished design system, a pitch deck, or a fixed deadline invented before anyone has seen the scope.
The first phase takes one sitting.
Four steps in the portal, then a scoped reply with the price and the revision count.