// 01
Greenfield Flutter builds
We take a product from a blank repo to the stores - architected from the first commit on Screen · State · View, tested and typed, not a prototype you have to throw away before launch.
flutter · ios · android · web · desktop
Production-grade Flutter, end to end
One product team, one codebase. We build your Flutter app and the whole stack around it - the backend, the cloud, the realtime layer - so the product moves as one thing instead of three vendors negotiating an interface. We've shipped on Flutter since 1.0, and every app sits on the architecture we open-sourced - readable, tested, and yours to extend when we hand it over.
why this exists
One codebase, the whole stack.
Most apps need more than an app. They need a backend, a realtime layer, auth, payments, and somewhere for all of it to run - and the moment those live with a separate team, the seams show: the API lands a week after the screen that needs it, and nobody owns the gap. We build the app in Flutter and the stack around it - Kotlin and Ktor on the server, Firebase and GCP for cloud, gRPC between them - so the product moves as one thing, not three vendors negotiating an interface.
Every app we build sits on utopia_hooks in Screen · State · View - the architecture we hold ourselves to on every build. One honest caveat: Flutter web is the right call for app-like products, not for an SEO-heavy marketing site. If that's what you need, we'll tell you so rather than sell you the wrong tool.
Every app we build sits on utopia_hooks in Screen · State · View - the architecture we hold ourselves to on every build. One honest caveat: Flutter web is the right call for app-like products, not for an SEO-heavy marketing site. If that's what you need, we'll tell you so rather than sell you the wrong tool.
what we do
The full stack, first commit to production.
// 02
One codebase, every platform
iOS, Android, web, and desktop from a single Flutter codebase. One team, one set of tests, one feature shipping everywhere at once instead of drifting between platforms.
// 03
The backend and cloud around it
The app is rarely the whole job. We build the rest of the stack too - Kotlin and Ktor services, Firebase and GCP, gRPC between client and server - so one team owns the app and what it talks to.
// 04
Performance & OTA delivery
We profile and tune until it holds 60fps on real devices, and ship fixes the same day with Shorebird over-the-air updates - patch a live build without waiting on a store review.
// 05
Hand-over, no lock-in
What you get is conventional Flutter your team can read, test, and extend - documented, on a published open-source architecture. Nothing gated behind us; you leave any time and keep everything.
concept to hand-over
How we build it.
- 01
Discover
We work out what you're actually shipping - the product, the platforms, the backend it needs - and tell you, in writing, what it takes and where Flutter is and isn't the right call.
- 02
Architect
We lay the foundation: Screen · State · View on utopia_hooks, the data and cloud model, the service boundaries - the decisions that are expensive to change once features pile on top.
- 03
Build
App and stack together, screen by screen, with tests and CI from the start. You review as we go and see it run on real devices, not in a deck.
- 04
Ship
We take it to the stores and the web, wire up monitoring, and set up Shorebird so the next fix reaches users over the air instead of waiting on a review queue.
- 05
Hand over
The code is yours - readable, documented Flutter on an open architecture. Your team extends it from here, or we stay on. Either way there's no lock-in.
common questions
Questions we get asked.
Is the backend and cloud included, or just the app?
Both, if you want them. We build the Flutter app and the stack around it - Kotlin and Ktor services, Firebase and GCP, gRPC between client and server - so one team owns the product instead of you coordinating a separate backend vendor.
What does "you own the result" mean in practice?
The code you get is conventional, documented Flutter on a published open-source architecture - nothing gated behind us, no dependency on a proprietary platform. You can extend it with your own team or move to another vendor at any point.
Is Flutter web actually viable for our product?
For an app-like product, yes - the same codebase that ships iOS and Android runs in the browser. For an SEO-heavy marketing site, no - we will tell you Flutter web is the wrong tool rather than build it anyway.
Who handles app-store submission?
We do, as part of shipping - we take the build through to the stores and the web, then wire up monitoring so you see it run on real devices.
What happens after handover if we need changes?
The codebase is documented and conventional enough for your own team to pick up. If you want us to stay on instead, we can - either path is open because nothing about the handover locks you in.
talk to us
Tell us what you want to build. We'll tell you how we'd ship it.
No sales call, no pitch deck. A founder reads it and replies within 24 hours - send the idea, the spec, or the half-built repo.
Read our case studies