Process - How a project actually runs
Three phases: agree on what goes into the first version, build in small changes that arrive with proof, and ship through the same channels that publish the studio’s own apps. The post about one night of building in the cloud shows this loop running.
Phase 01
Discover
It starts with a conversation about the problem and the people who will use the product. At this point the constraints matter more than the goals: deadline, budget, sensitive data, and whatever already exists and has to keep working.
That leads to the platform decision: a native iPhone app, the web or both, and whether AI comes in, on the device or in the cloud. When the doubt is about the interface, a prototype answers faster than a meeting.
The result is a written scope: what goes into the first version, what waits, and the project’s rules in a file that both people and agents read before they touch the code.
Included in this phase
- First-version scope
- Platform choice
- Prototype when in doubt
- Map of what leaves the device
- Project rules in writing
Phase 02
Build
Each task becomes a Claude Code session in the cloud, with the repository cloned and a single change to make. Several run at once, and each one ends in a pull request.
For iOS apps, Revyl builds the app on a Mac in the cloud and opens a simulated iPhone that the agent itself uses: it taps, scrolls and takes the screenshots that go into the pull request as proof. On the web, every pull request gets a Vercel preview.
Tests run alongside: Swift Testing in the apps, bun test on this site. No change reaches review without saying what built, what was seen working and what was left out.
A small change with proof is easier to review than a big one with a promise. One night of working this way produced 19 merged pull requests across two apps, with Xcode closed the whole time.
Phase 03
Deliver
Before a version goes to the store, the Mac has the final word: the full test suite runs there, on a real build, because the cloud simulator does not catch everything.
Signing and upload belong to Xcode Cloud: an approved pull request is enough for it to produce the signed build for TestFlight and the App Store. On the web, a merge publishes to Vercel.
With the app come the pages App Review asks for, privacy, terms and support, written from what the code actually does. After launch come the updates for each new iOS release, and the fixes.
Included in this phase
- Proof on every change. Simulator screenshots or a Vercel preview on every pull request, plus the full suite on the Mac before a release.
- TestFlight and the App Store. Signed builds from Xcode Cloud, with the store listing and screenshots reviewed for each version.
- Privacy and support. Privacy policy, terms and support page in Portuguese and English, matching what the app does.
Our values - What we hold on to
Rules that came out of the studio’s own apps and hold for any project.
- Proof before merge. A change reaches review with what built, what showed up on screen and what was left out.
- Code does the math. A model reads and organizes. Numbers, rules and rankings stay with tested code, as in Prandial.
- Data on the device by default. Weightics, Zenoney and Prandial keep their data on the iPhone. Only what a feature needs leaves it, and the policy says what.
- Native when it is an app. SwiftUI on the iPhone rather than a wrapped web view, so the app behaves the way the platform expects.
- New tools start at home. A new tool is tried on the studio’s own apps first, and the blog says what worked and what did not.
- Work you can see. Every change is a pull request you can open, with the preview and the screenshots attached. Trade-offs show up as they happen.
Made to order - Bring the problem to the bench.
A rough idea is enough to start. You’ll talk directly with the person who will build it.
Bench
São Paulo GMT−3