FÁBIOFIORITA

Projects

Three products I designed, built and shipped on my own. The two on the App Store have 2,500+ downloads.

Player one

How I work

Seven rules I hold every change to, and where each one has shaped real work. Open a level to see it in practice.

1. LVL 01Prove it works▸

   Done means I ran the real thing and watched it work: the server, the browser, the phone. A passing type check is not a feature.

   In practice

   • ▸Automated checks that start the real server on its own database, sign in through the real one-time code, drive the web app and a phone simulator, and keep screenshots as evidence before a change is called done.
   • ▸Proof is part of every review: the checks that ran and the screenshots taken sit next to the code, and they are flagged as out of date the moment the code changes after them.
2. LVL 02Strongest layer first▸

   When a mistake repeats, I fix it in the types, then a lint rule, then CI. Documentation comes last, because a failing build cannot be skipped.

   In practice

   • ▸A set of house rules for a whole codebase, each one enforced as a lint rule or a check that fails the build, with no way to silence it. Every rule ships with a test that proves it fires. Rolled out by turning the code red, then green.
   • ▸The architecture is checked, not described: dependency rules between packages, a custom lint plugin, duplicate and dead-code checks.
3. LVL 03Isolate parallel work▸

   Work that runs side by side shares nothing by accident: not a branch, a port, a database or a device.

   In practice

   • ▸A worktree tool that gives every task its own checkout, its own set of ports and, for migrations, its own database, so several full stacks run side by side without stepping on each other.
   • ▸One client reaches servers on many machines, local or remote, and every review belongs to the worktree it came from.
4. LVL 04The codebase is the memory▸

   People and tools copy what they see. When a new way replaces an old one, every caller moves and the old way is deleted in the same change.

   In practice

   • ▸One source of truth for the AI coding tools the whole team uses: instructions next to the code they govern, in every package, instead of a separate setup per person.
   • ▸Rules that the web and the phone apps each re-implemented moved into shared modules, so both read one definition and there is no second copy to drift.
5. LVL 05Model the domain▸

   Name the data shape first and let the structure carry the rules. One owner for every piece of state.

   In practice

   • ▸The five list formats are modelled once, on the server. The iPhone app and the ChatGPT app read the same lists and follow the same rules.
   • ▸A server, a web app and a phone app over one shared domain layer. The phone sends answers and shows the result the server worked out; it computes nothing on its own.
6. LVL 06Adopt before build▸

   Use what the project already has, then a well-known library. Build only what makes the product different.

   In practice

   • ▸An audit of a phone app that handed its hand-rolled navigation and state back to the router and native stacks. Each change was checked on a device, and the one that misbehaved was reverted.
   • ▸Version 5 moved storage and iCloud sync onto an established library instead of keeping custom sync code, so the effort goes into reminders, not plumbing.
7. LVL 07Experience first▸

   When what is easy to build and what is good to use disagree, the person using it wins.

   In practice

   • ▸Critical Alerts that sound through Silent and Do Not Disturb, because a missed dose matters more than a quiet phone.
   • ▸A review that follows the decisions in reading order instead of listing files alphabetically, because that is the order a person understands a change in.

Log

• I stopped babysitting my agent, and it finally fixed the feature I’d fought for weeks5 Jun 2026 · 9 min
• Sharing my experience migrating a Flutter app to SwiftUI27 Jan 2024 · 2 min