Products built to still be running in ten years.
iLeaf designs and builds web, mobile and hybrid products, then keeps them running. Over 200 of the products we have shipped since 2011 are still in production and still maintained by us — including one acquired for $157M and another ranked the top app in its category. Long-term ownership shapes how we build.
Ask Lia about product engineeringWhat this includes
- Web applications
- Server-rendered and single-page applications with an emphasis on the boring parts: state, auth, migrations and observability.
- Native mobile
- iOS in Swift and Android in Kotlin, including offline-first sync for products used where connectivity is unreliable.
- Cross-platform
- Flutter and Kotlin Multiplatform where one codebase genuinely serves both, and native where it does not.
- Product design
- Interface and interaction design done alongside engineering, not thrown over a wall as a static file.
- Platform & APIs
- The services behind the app — versioned APIs, background jobs, webhooks and integration with whatever you already run.
- Long-term maintenance
- Dependency updates, store submissions, incident response and the unglamorous work that keeps a product alive.
How we run it
Every phase ships something usable on its own, so you are never holding a half-finished system waiting on the next milestone.
Cut the first release down
We find the smallest version that a real user can complete a real task in, and ship that. Scope grows against usage, not opinions.
Design and build together
Designers and engineers work in the same cycle, so what is drawn is what can be built and what ships is what was drawn.
Release continuously
Trunk-based development, automated checks and frequent releases, so a regression is one small change to find rather than a quarter's worth.
Stay after launch
Launch is the start of the expensive part. We plan for the years afterwards, which is why so many of our products are still live.
What we build it with
- TypeScript
- React
- Next.js
- SvelteKit
- Node.js
- Python
- Elixir
- Swift
- Kotlin
- Flutter
- PostgreSQL
- Directus
Questions we get asked
Do you take over products someone else built?
Regularly. We start with a read-only audit of the codebase, dependencies, data model and deployment path, then give you a written assessment of what is safe to change and what needs replacing first. Taking on unfamiliar code is normal work for a team that has maintained products for fifteen years.
Native or cross-platform?
It depends on what the product does. Heavy device integration, background processing or platform-specific interaction patterns argue for native. A largely shared feature set with the same interface on both argues for Flutter or Kotlin Multiplatform. We will tell you which case yours is before you commit.
Who owns the code?
You do, from the first commit, in your own repository. There is no proprietary framework you have to keep paying us to maintain, and no lock-in beyond the ordinary cost of changing engineering teams.
Let’s talk about product engineering.
Tell us what you are running and what it needs to do next. We will tell you honestly whether we are the right team for it.