01 Overview
A count kept in people's heads, and an app that had to keep it for them without overwhelming them.
Each row is a layer: what was wrong, what it cost, and what we did about it.
| What was going wrong | What we did about it | |
|---|---|---|
| Design problem Nothing existed but a brand and a style scape, and the core screen had to take 12 to 24 location entries a day from users who aren't glued to their phones. 12–24 a day timeline entries per user, each one to accept or decline. | One intention per screen: a timeline with room to breathe, overviews on the home screen, and the evidence first on every entry. | See the work |
| Engineering problem No website at all, and a product that had to win investors as well as users. 0 pages no site to market the app or explain it to investors. | Every component coded once from the app's design system, wired into WordPress, and checked in staging against the Figma mockups. | See the work |
01.1 The timeline
In before the developers, out once they could carry it alone.
We started with the founder and a style scape, designed the app as the developers built it, and added the website and launch materials in the final months.
- 2022December
We start with the founder, before there's an app, a site or a developer team.
- 2023February
The first screen is signed off.
- April
The client's developers start building the app in Flutter.
- May
Their first builds come back to us.
- December
The website starts, with the PDFs and marketing materials alongside it.
- 2024May
Our work ends with the app in TestFlight; the client's Flutter team carries it to launch.
01.2 Context
A founder who'd seen the problem from a cockpit, and a brand with nothing built on it yet.
What the work started from, before any screen existed.
What it does
Records the user's movement between countries automatically, keeps day counts current against each tax residency rule and the limits set for them, and captures evidence as they travel, metadata intact. Every assumption, correction and change goes into an audit trail built to withstand tax authorities.
Where it came from
The founder was a pilot. He'd watched people keep the count in their heads, miss it and overstay, and seen all the trouble that follows. He had already built a black box for businesses; this was one for people.
What a miscount costs
A few days too many in one country can make someone a tax resident there: tax on income from everywhere, back-dated bills and penalties. And the proof falls on the traveller, which is why every entry carries its evidence.
Who it's for
Internationally mobile people: high net worth individuals, pro athletes. They're the most exposed to tax issues, and with that much money, a government will pursue them if they break a rule.
The users, as we met them
Lawyers and billionaires not aligned to tech. Our working assumption: they aren't glued to their phones, and they don't explore apps the way we do.
What they had
The branding and a style scape, full of very rich people, which told us who the users were and set the aim of premium. No app, no website, no developer team: just the founder and us.
How we came in
We'd worked on the founder's earlier products. He knew we could do it and wanted the vision to come alive.
02 Design solution
Premium came from how simple it felt, not from how rich it looked.
Premium meant a polished, well-thought UX: clean, easy to understand, easy to digest. We stopped cramming everything into one screen. Each screen has one intention and focuses on it, so an app that logs a dozen entries a day still reads at a glance.
02.1 The work
Every screen, shown whole.
The app in one long run that pans as you scroll: the timeline where each entry is accepted or declined, the evidence on every entry, and the scheme cards that swipe like a passport.
02.2 The design process
Every screen went through the founder to the developers, and anything they couldn't build came back to us.
We never met the developers. Screens went through the founder, who walked us through every concept first, three or four times a week. Builds came back as screenshots, later on TestFlight on our own phones. Silence meant the mockups were followed; the founder only came back for an opinion or a developer's flag.
- Design the screen
- The founder's review
- Flutter buildBack to 01
- Build reviewBack to 01
- TestFlight
Caught at 03 Flutter build
The ring went solid, and the text in its centre was reworked around it.
The scheme cards' radial progress ring had a gradient Flutter couldn't render.
- The result
- Built as designed, gradient removed
- Who, and where
- The client's Flutter developers, flagged through the founder.
Caught at 03 Flutter build
Sent back to us and designed into the system like the rest.
A pop-out or a page missing from the mock-ups. They wouldn't guess what it looked like.
- The result
- App design ran on to May 2024
- Who, and where
- The client's Flutter developers, mid-build.
02.3 Design decision
Light instead of dark, overviews instead of everything, and the founder's knowledge instead of our guesses.
Three calls shaped the app: the look luxury expects, how much the home screen carries, and whose picture of the user we designed for.
| The call | The easy answer | What we chose | What it cost, and what it bought |
|---|---|---|---|
| Light or dark | A dark, black app, the look luxury brands lean on. | Light mode, which sits better with the brand colour, with the UX leading over the aesthetics. | The usual luxury signal. By Chris's account, it cost little. A more approachable, relatable UX that's easier to digest. |
| The home screen | Every country's count and every recent location, all on the first screen. | Overview sections, one or two lines each, with a link to the rest. | Every full list sits one tap further away. A first screen that reads at a glance, even for someone who travels a lot. |
| Whose picture of the user | Put ourselves in the user's place, as we usually do. | Lean on the founder's knowledge of his market, three or four meetings a week. | His time every week, and our own read of the users set aside. Screens that did justice to rules we'd never met, like the UK SRT and Schengen. |
03 Engineering solution
A marketing and investor site, coded once from the app's own design system.
The site was built from scratch to sell the app and win investors at once. Chris wrote the front end of every component; Jake wired them into WordPress with Elementor. The founder reviewed it in staging, against the Figma mockups.
03.1 The wiring
From the design file to a live page, in one picture.
The build on one page: the design system in Figma, the components coded from it, and WordPress putting them together into pages the founder reviewed in staging.
- Navigation
- Hero
- Featured
- FAQ
- Photo gallery
- Brand wall
- Blog cards
- Footer
The founder's review: matches the Figma mockups
03.2 The parts
Components coded once, pages built from them, and one design system under both.
What we built for the site, what each part does, and where it runs. Chris's front end, Jake's WordPress side.
| The part | What it does | Where it runs |
|---|---|---|
| Components | Navigation, heroes, featured sections, FAQs, footers, a photo gallery, a brand wall: every section the site needed, coded once. | Chris's front end, wired into WordPress by Jake. |
| Blog | The list, the cards and the post pages, built from the same components. | WordPress, through Elementor. |
| Pages | Home, partners, founding partners, the product page and the blog: about eight pages that sell the app and speak to investors. | WordPress, through Elementor. |
| Design system | The brand colours and type styles, carried over from the app. | Figma, shared by the app and the site. |
03.3 How it fits together
One design system under the app and the site.
The site took the app's brand colours and type styles as they were. Only the scale changed: headings and font sizes that work on a phone don't work on a page.
03.4 The engineering process
Pixel perfect to the Figma mockups before the founder ever opened staging.
Every page was coded to match its mockup exactly, wired into WordPress, then sent to the founder in staging. He expected to see what he'd seen in Figma, and nothing slipped past that.
- Design in Figma
- Front-end code
- Wire into WordPress
- The founder in stagingBack to 02
- Live
04 Field notes
We didn't make it look rich. We made it easy, for people who can't afford to miscount a day.
What came of the work that no other section holds.
In Chris's words
"Designing an app targeted for billionaires and high net worth individuals, it's much trickier than I thought, because they need to feel the premium of the product." In his view, premium is what they respond to most.
Working with the founder
He walked us through every concept we didn't know, patiently. "He gives me the information, and I was able to deliver something that gives justice to that information." Chris counts it among his biggest takeaways.
The hardest word
Schemes. Chris wasn't well travelled then, and terms like the UK SRT and Schengen were new. The scheme cards ended up laid out like a card passport, swiped sideways, each showing the days spent in a region or country.
Beyond the app
The app store previews, PDFs explaining the product to investors, and LinkedIn posts to promote it and draw investment, with Dave's illustrations and icons throughout.
In hindsight
Chris would learn more about high net worth individuals: their lifestyle, struggles and pain points. AI agents weren't good enough then. Now he'd have an agent build a persona and interview it.
What to take from it
Simplicity and ease of use, UX first. Designing for the rich takes the skill to make premium designs that attract the rich.
How it ended
Nobody felt the need to replace us. The work ended in May 2024, once the client's Flutter team could take over. The app launched after and is still live; the site has since been redesigned by others.
05 Team and stack
Three people across design and engineering.
Built on WordPress and Elementor. Made with Figma.
- Built on
- WordPress · Elementor
- Made with
- Figma
Chris Javier Oliveros
UI/UX Designer, Frontend Engineer
Designed the mobile app's UI/UX, then designed the website on the same branding and wrote its front-end code; designed the PDFs, the marketing materials for the client's LinkedIn and the app store previews.
Jake Christian Oliveros
Lead Developer
Owned the WordPress side: wired Chris's front-end code into WordPress and helped publish the site.
Dave Mark
Graphic Artist
Made the illustrations and icons for the website and the PDFs.
