Jobs, courses, housing and the paperwork: one app instead of four rumors
A React Native app for people working abroad, holding the four things they actually search for (work, training, housing and official guidance) behind one account.
The brief, in specifics
- Industry
- Professional Services
- Duration
- 16 weeks
- Cooperation model
- Fixed price, phased
Client name withheld under NDA. Engagement details are shown to the extent our agreement permits.
Four record types
Jobs, courses, property and essential information each keep the shape that makes them useful.
Jobs, courses, property and essential information are four record types with four detail views, because a job needs salary, employer and a way to apply while a property needs rent, deposit and photographs. Flattening them into one card shape would have made every one of them slightly wrong. What they share is the directory and the search; the record stays their own.
- Four record types with four purpose-built detail views
- Shared directory and search, unshared record shape
- Nothing flattened into a lowest-common-denominator card
A job in the detail sheet a job needs: weekly pay before tax worked out from the hourly rate, a 4 on / 4 off night shift pattern drawn across its 8-day cycle, average hours, what the job asks for, and apply.
Signing in on a new phone: the old number can't receive a code, so the email link is the way in, the account moves to the new number from inside the app, and saved items, applications, documents and searches come back with it.
An account that survives a new phone
Verification and recovery built for an audience that changes handsets often.
Verification and recovery were built for an audience that changes handsets and numbers often. A new SIM in a new country shouldn't cost someone their saved jobs and submitted applications. Recovery works from email as well as phone, and an account can move to a new number from inside the app, with no support conversation in a second language.
- Recovery by email as well as phone number
- A number change is self-serve, not a support conversation
- Saved items and applications survive a new handset
Built for modest devices
A virtualized list, built for the phones in the audience's hands.
FlashList virtualizes the directory so a thousand records scroll at frame rate on a three-year-old mid-range Android, the phones this audience actually holds. Images are sized for those screens instead of downscaled from desktop assets, and the app was profiled on real low-end hardware, not a simulator.
- Virtualized lists holding frame rate on mid-range Android
- Images sized for the target screens, not downscaled desktop assets
- Profiled on real low-end hardware, not a simulator
The directory with three filters switched on (jobs, nights, within 5 miles) and every row beneath them obeying all three, in fixed-height rows built for a virtualised list.
Official guidance as six numbered steps with your own documents checked against them: two ready, a passport expiring before it is needed, two missing, one waiting, and the changed step flagged under the notice that announced it.
News where people already are
Announcements sit beside services, where people will actually see them.
Announcements and news sit inside the directory alongside services, because a channel people have to remember to open is a channel that goes unread. Time-sensitive items (a visa deadline, a rule change) surface at the top of the screen people were already using for something else.
- Announcements inside the directory, not a separate feed
- Time-sensitive items surface where people already are
- No channel that depends on being remembered
One account, everything saved
A course with its timetable, its funding and who runs it, and the application already sent, held on the account instead of on the phone.
Saved items and applications persist on the account, not in a browser someone loses.
Saved items, applications and search history live on the account instead of in the app's local storage, so they survive a reinstall, a new phone, or the loss of the browser someone had been using. That was the single most requested thing from the audience: the previous tool lost everything the moment a handset did.
- Saved items and applications held on the account
- Survives reinstall, new handset or a lost browser
- The audience's single most requested change
What we were brought in to do
The goal was to support workers living away from home. We built the app that puts jobs, courses, property and official information in one place, with an account that survives a change of phone.
An app for workers living away from home, whose essential information was genuinely scattered: a job board in one place, a landlord's number in a group chat, a course on a poster, and official guidance in a language they were still learning. The cost of that fragmentation falls hardest on the people least equipped to absorb it, which is what made consolidating it worth a build.
Mobile Engineering
Where the old way broke
The information people need is real but scattered: a job board here, a landlord's number in a group chat, a course advertised on a poster, and official guidance in a language they're still learning. The cost of that fragmentation is paid by the people least able to afford it.
Beyond the scattering, the audience's own circumstances broke the usual assumptions. Handsets are changed and lost often, and every previous tool had kept saved jobs and submitted applications on the device, so a new SIM in a new country meant starting again. The phones are also modest, and a directory that scrolls badly on a three-year-old Android is a directory nobody uses twice.
One directory with four record types, each opening the detail view its own kind actually needs, plus a verified account so saved items and applications survive a lost or replaced handset.
What we built together
- 01
Modeled four record types, each with its own shape
Four types were settled before any interface work, because a single card shape would have made each of the four slightly wrong in a different way.
- 02
Gave each type the detail sheet it needs: a job isn't an apartment
Each type opens the detail view its own kind needs, so nothing is flattened into a shape that serves all four badly.
- 03
Built email verification and recovery properly, because a lost handset is common
Recovery works from email as well as phone and a number change is self-serve, because for this audience a new handset and a new SIM are routine.
- 04
Used a virtualized list, because these directories are long and the phones are modest
The directory is virtualized and its images are sized for the target screens, profiled on a low-end handset bought from the target market instead of on a simulator.
- 05
Kept news beside services, since that's where announcements are actually read
This was tested by putting a visa-deadline notice in both places for two weeks; the directory placement was read by an order of magnitude more people.
Phase by phase
Phase 1: Four Types, Not One
A Job Is Not A Flat
Modeled jobs, courses, properties and essential information as distinct types, because forcing them into one record shape loses what makes each one useful.
- Content Model
- Four Detail Sheets
- Directory Schema
Phase 2: The Account
Surviving A Lost Phone
Built registration, email verification and password recovery to a standard that assumes the handset will change, because for this audience it frequently does.
- Auth Flow
- Email Verification
- Recovery
Phase 3: The App
Modest Phones, Long Lists
Built the tabs and directory with a virtualized list, because the audience's devices aren't the ones on the design team's desks.
- Tab Navigation
- Virtualised Directory
- Detail Modals
Phase 4: News In The Same Place
Where Announcements Are Read
Put news alongside services, inside an app people already open, because that's where an announcement actually lands.
- News Feed
- Announcements
- Content Publishing
A property with the whole monthly cost worked out, beyond just the rent (council tax, energy, water and broadband added, bus fare to a saved job alongside) and what it takes to move in.
Operational results after launch
4
Record types modelled
4+
Sources replaced
Self-serve
Account recovery
Low-end devices
List performance target
Record types modeled and sources replaced are counts. Account recovery being self-serve is a capability claim. The list performance target is stated as low-end devices, not a frame rate, because the handsets the audience actually carries set the target.
Client name withheld under NDA. Figures are approximate, drawn from the engagement’s own reporting.
About our collaboration
- 01
We resisted flattening the four record types into one directory shape, and that was the main design pressure throughout. A job and an apartment need different detail views, and merging them would have made the app tidier and less useful. Account recovery was treated as a core feature from the start.
Phased, with the four record types settled before any interface work, because flattening them into one card shape would have made all four slightly wrong. Performance was tested on the audience's actual devices: a low-end handset from the target market was bought in week two and every build was checked on it.
What we'd carry into the next one
- 01
Forcing four kinds of record into one shape loses exactly what made each of them useful.
One card shape for four record types loses the specific field that made each useful, and the loss is invisible until someone tries to act on the listing.
- 02
For some audiences a lost handset is routine, and account recovery becomes a core feature instead of a support path.
For this audience, losing a handset is ordinary, which moves account recovery from a support path to a core feature.
- 03
Build for the devices the audience owns, not the devices the team develops on.
The devices on a design desk aren't the devices in the audience's hands, and the gap is exactly where a long directory stops being usable.
- 04
An announcement lands where people already are, not in a channel built for it.
Putting announcements where people already are beat building a channel for them, because the channel would have required an intention nobody has.
Official guidance, six numbered steps
Not a page of rules to decode. Your own documents, checked step by step.
A permit renewal as the app holds it: each step carries its rule, and the documents on the account are checked against it, so a passport that runs out thirteen days too early shows as expiring before anyone joins a queue. Pick a step, or use the arrow keys once one is focused.
Renewing your work permit · updated 12 Sep 2026 · checked Thu 17 Sep
Illustrative guidance: invented rules, not a real procedure
Step 2 · Passport valid long enough
Rule: Your passport must be valid for 6 months after the day you apply.
Your documents against this step
- PassportExpires 4 Mar 2027ExpiringNeeded to 17 Mar 2027 — 13 days short
The date rule, drawn to scale
Check timings are illustrative. The documents are the ones held on the account, so the same check comes back on a new phone.
From a published listing to a long list that still scrolls on a modest phone
React Native with Expo and Expo Router, TypeScript and Firebase. Each step exists because this audience changes handsets often, carries modest phones, and was piecing things together from four different sources before.
- 01 · PublishRecords, news and announcementsListings and guidance are published into one directory, and news goes in beside them, never into a separate feed.
- 02 · ModelFour record typesShared directory and search, unshared record shape: a job keeps pay, employer and apply; a property keeps rent, deposit and photographs.
- 03 · IdentityFirebase accountEmail verification at sign-up. Recovery works from email as well as phone, and moving to a new number is done in the app.
- 04 · StateHeld on the accountSaved items, applications and search history live on the account, not in local storage, so a reinstall or new handset loses nothing.
- 05 · DeviceExpo app, virtualised listFlashList renders the long directory and images are sized for the target screens. Builds were checked on a low-end handset from the target market.
Current guidance, a way back in, a phone that copes
Announcements in place, self-serve recovery & low-end devices as the target
A rule change lands where people already look
Essential information is its own record type in the same directory as the services. Time-sensitive items, a visa deadline or a rule change, surface at the top of the screen people open for work and housing, not in a channel they would have to remember.
Nobody to call is not a lock-out
Recovery works from email as well as phone, and moving the account to a new number is self-serve in the app, not a support conversation in a second language. Saved items and applications are held on the account, so they come back too.
Built on the phone people carry
The directory is a virtualized FlashList and images are sized for the target screens. A low-end handset from the target market was bought in week two and every build was checked on it, not on a simulator.
Serving people whose jobs, housing and paperwork are scattered across group chats and noticeboards? Scope your build in 3 minutes.
Scope your buildNearby engagements
AI & AutomationA private legal assistant grounded in verified precedents
A private knowledge assistant that searches internal case files and precedents, providing cited answers legal teams can verify in seconds.
Legal & Law Firms · 14 weeks
Product DesignAn onboarding flow that guides trial users to value
A redesigned SaaS trial onboarding experience with progressive checklists, sample data, and inline guidance that turns signups into active subscribers.
Professional Services · 10 weeks
Product DesignA design system that brought speed and consistency to 4 product teams
A token-based design system in Figma and React that eliminated component duplication across 4 product squads and cut the time from design handoff to merged frontend.
Professional Services · 14 weeks
Let's talk
Running a large platform, shaping a first MVP, or getting a product ready for a funding round? Tell us where you are. We'll shape the process around it, and stay with you after launch.
