Approve and put it liveNot yet
waiting for a human, indefinitely
a person approves every release
The agent can open a change. It cannot ship one. There is no setting for this, because a setting is a thing that gets switched off on a busy Friday.
apps that do not freeze at launch
we don’t ship apps. we ship apps that keep evolving.
Most apps start dying the day they launch. We design and build yours for web, iOS and Android, and it arrives already able to change itself: you describe what you want in a sentence, agents do the work, you approve it, it ships. No quote, no thread, no waiting three weeks.
worked with
- Renault
- BNP Paribas
- Voodoo
- L'Oréal
- wethe.fan
- KlubX
- Yumcall
- Sleepi
- Yolonce
- Winit
- MyTeacher
the work
apps we built, and still ship to every week
mobile and web, all of them still moving
myteacher
Wwethe.fan
Yyolonce
yumcall
sleepi
klubxBbump
Ddailymotion
Bbrainqraft
Ddebatium
Eeliott
Wwizz
myteachermyteacherWwethe.fan
Yyolonce
yumcallsleepiklubxBbump
Ddailymotion
Bbrainqraft
Ddebatium
Eeliott
Wwizz
myteacher3
surfaces we ship
web | ios | android
10 min
request → preview
typical, not best case
1
credit per change
refunded if it fails on us
100%
releases you approve
no exceptions, ever
why this matters
an app that cannot change is already dying
The usual story: an agency ships, invoices, and moves on. Six weeks later you spot something small. It needs a scope, a quote and a slot in someone’s calendar, so you let it go. Then you let the next one go. A year in, your app is exactly what it was on launch day and your competitors’ are not.
We build the ability to change into the thing we hand over. Not a retainer you have to justify every month. A product that is still moving in year two because moving it costs a sentence.
handed over
the same app it was on launch day
4.8in the stores
shipped at launch
built by maidai
still moving in year two
4.8in the stores
shipped at launch
launchlaunch daytwo years
illustrative of the pattern, not a specific client
we build it
A small senior team, one project at a time. No account manager between you and the people writing the code, and no discovery phase that bills for three months and produces a slide deck.
- 01
we scope it properly
A week of real conversations, not a questionnaire. What the app has to do, who it is for, and most usefully of all, what it does not need to do in version one.
- 02
we design and build it
One codebase across web, iOS and Android. You see it running the week we start, and every week after that, so the first time you use your app is not the week before launch.
- 03
we put it in front of people
App Store and Play Store submission, the web app on its own domain, analytics, error reporting, and the deploy pipeline your app will keep using long after we are done setting it up.
02 | you run it
try it right here
This is the actual flow, running in the page. Click through it, or let it play. Staylo is a stand in for your app, so there is nothing to learn before the change makes sense.
portal.maidai.ai/apps
the part worth asking about
an agent with the keys is a real risk
So it does not get all of them. Four things hold it back, and none of them are configurable by us or by you.
deploy configsecretsthe pipeline itself
it cannot reach the dangerous parts
Deploy config, secrets and CI are out of bounds. A change that touches them is stopped before it ever leaves the machine, not caught later in review.
nothing brokeevery phonestill fastyour tests
one red is enough. it never reaches you.
your own tests are the bar
Typecheck, lint, build and your test suite all have to pass. If they do not, the change never reaches you, and the credit goes back.
github.com/yourcompany/yourapp
your account, your billing, your keys. we are a collaborator.
it is your repository, always
The work happens in your own repo, on a branch, through the pipeline your team already uses. Walk away tomorrow and every change we made is still just code you own.
after launch
one credit, one change
Building the app is quoted per project. This is what keeping it moving costs afterwards. Billed per change, never per token or per hour, and refunded whenever a run fails on our side.
solo
One app, steady upkeep
$299/ mo
- 25 changes a month
- one app
- unused credits roll over
- failed runs refunded
- about $11.96 a change
most chosen
studio
A small portfolio of apps
$999/ mo
- 100 changes a month
- up to 5 apps
- unused credits roll over
- failed runs refunded
- about $9.99 a change
scale
Agency volume, priority queue
$2,499/ mo
- 300 changes a month
- up to 20 apps
- unused credits roll over
- failed runs refunded
- about $8.33 a change
Busy month? Top-up packs start at $149 for 10 credits, and they never expire.
questions worth asking
- do you only work on apps you built?
- The studio work and the control room are sold together, and that is how we prefer it, because we know the codebase we wrote. Bringing an existing app in is possible, but it starts with a paid audit rather than a login, because we will not put an agent near a codebase we have not read.
- what exactly is a credit?
- One credit is one change, from the sentence you type to something you can look at and approve. If the run fails on our side, whether that is our infrastructure, our guard rails or our own mistake, the credit goes straight back automatically. You are charged when the agent did the work and your own checks had their say.
- do I need to know anything technical?
- No. Describe the change the way you would to a colleague. If a request is ambiguous enough that guessing would waste a run, you get a question first instead of the wrong thing shipped.
- what happens when it gets something wrong?
- You see the result before anyone else does, and nothing reaches your users until you approve it. If it is not right, one sentence sends it back with your note attached.
- how long does a change take?
- Most land in five to fifteen minutes. The first minute is spent setting up a copy of your app, which the interface says out loud rather than pretending it is instant.
- and if we stop working together?
- You keep everything. The code is in your repository under your account, deployed through your own pipeline, on your own domains and store listings. There is no part of your product that only runs because we are still being paid.