Product
Before the first screen exists, it is clear who uses it, at what point in their day, and what should be faster than it is now.
Web and mobile apps
I build tools that simplify a specific process: quoting, requests, customer service, team work. I start from that process, not from picking a stack.
More than code
Technology is the last of three problems to solve. The first two decide whether it is worth writing at all.
Before the first screen exists, it is clear who uses it, at what point in their day, and what should be faster than it is now.
The hard part of an app is not the feature, it is the path to it. I design flows, not a collection of separate views.
Architecture built for integrations and scale, so version two does not mean writing everything again.
What I build
Instead of a list of twenty items — the ones I put my name to.
Tools that run in the browser, with no install and no app store.
iOS and Android where camera, location or offline access actually matter.
The shortest route to a version you can put in front of users and test the assumptions.
Calculators, dashboards and panels that take manual work off the team.
From idea to product
The later an assumption changes, the more it costs. That is why most of the work sits at the start.
MARS — a complex product broken down into its parts
The app for Alvernia Planet has two independent modes, its own user paths and mission stages. A fourteen-page functionality document was produced for the build — mode by mode, screen by screen. You can page through it on the project page: it shows how I structure a product of that scale before it exists.
Selected work
Selected launches from this category.
You do not need a finished spec. The problem is enough — we'll map out the rest together.