Case study
Real estate agent app
A mobile app on the App Store and Play Store that owners can put in customers’ hands. New agents get a path to start and grow — including coaching they pay for.
Sole engineer · 2024 – 2026 · iOS and Android
Before
Two owners in real estate. No app. Nothing they could put in a customer’s hands in the stores.
Now
A phone app in the App Store and on Google Play. New agents start and grow — including coaching they pay for.
Context
Two owners in real estate asked for a product they could take to other agents — a thing people open on a phone, in both stores. I sat with them on what it had to do. New agents get a path to start and grow; paid coaching and tools sit behind the same login. I built the phone app, the admin site, and the API on one database.
Constraints
- An agent can only see their own people and their own work. That has to hold even if the app asks for the wrong id.
- The phone cannot poll all day. Battery and the API both lose.
- One database has to serve the phone, the admin site, and the API. Three faces, one record of truth.
- The owners needed it in the App Store and on Google Play.
What I built
- 1.Phone — What the agent opens. It displays. It does not decide who sees what.
- 2.Admin — Where owners change wording, choices, and what is on a screen.
- 3.API — The door between the phone, the admin, and the book of record.
- 4.Cache — Remembers what this person already saw so the phone is not asking all day.
- 5.Database — One book. It will not hand over someone else’s row.
The phone does not go get data on its own. Cache decides what is still good to show. Login and the API talk to the servers. Those pieces do not wait on each other to start. The database is what stops one agent seeing another’s book.
Hard problems
Your data, not theirs
If only the app is polite, one missed check leaks a book of contacts. The database refuses any row that is not yours. The app can ask. The database still says no.
Memory that does not lie after sign-out
The phone shows what it already has first, so it feels instant. If something changed, the screen updates when the new copy arrives. Sign out, sign in as someone else — you never see the last person’s data.
Layers that do not do each other’s jobs
Each piece has one job. They can ask each other for help. They cannot take over that job. They agree what they share so access does not leak and behavior stays predictable. The admin site is where owners change what the phone shows — wording, choices, what is on a screen. A lot of that is just data. You do not ship a new API every time a sentence changes.
Outcome
- Stores
- App Store and Google Play
- Who it is for
- New agents — start, grow, paid coaching
- What they hold
- Phone, admin, one API, one database
- Isolation
- Agents only see their own book
Close
- What this proves
- A full product — phone, admin, API — on both stores, from requirements through launch.
- What I would keep
- The database still decides whose data it is. The phone does not go around that. Cache stays tied to the person. Owners can change wording without a new API.
- What is still open
- The admin can change a lot of what the phone shows without a new API. Calculated things still need a real call. That split is the line I kept.