Aervante
2026A private concierge membership. Members send one message. Everything else is the system.
Aervante is an internal venture, not a client commission — designed, built and shipped by this office. It is on the work page because the problems it posed are the ones a concierge, a marketplace or any service business poses, and because the whole thing exists: identity, two products, a data model and a live App Store build.
01The problem the interface had to solve
Concierge services fail at the intake. Most put a form in front of the member — category, date, party size, budget, notes — which is the service asking the member to do the staff's job. The premise here was the opposite: the member writes one line the way they would say it, and the structure gets extracted behind the message.
That decision set everything downstream. If the member never fills in a form, the structure has to be produced somewhere else, by someone else, without the member feeling the seam.
02One thread, not a queue
The member app is five screens — home, requests, community, chat, profile — and the whole product lives in the thread. A request arrives as plain language, is acknowledged immediately, and is confirmed by a person, usually inside two exchanges. The summary card is the seam made visible: it shows the member what was understood before anyone acts on it.
03The system behind the message
Every request runs a lifecycle staff control and members only ever
observe: pending → reviewing → quoted → confirmed → completed,
with cancelled and declined as terminal branches. Members create
pending and may cancel their own. Nothing else is theirs to
write — quoting, vendor details, payment state and the member-facing
confirmation are all staff-only, enforced in the database rules rather
than in the interface.
Requests are typed by category — dining, travel, drive, access, gifting — because triage, routing and reporting all depend on that one field being reliable. Membership runs three tiers: access, reserve and private client.
The staff console is the other half of the product and gets none of the member app's restraint. It is a working tool: inbox, requests, members, content, team. Where the member sees one confirmed dinner, a staff member sees the queue, the vendor, the quote and the deadline.
04The identity
Dark, quiet, and deliberately unlike the member app's competitors — an absolute-black ground, a single gold accent, and system type at generous spacing. The restraint is functional as much as aesthetic: the app is used at night, one-handed, in the ten seconds before someone puts their phone down. Anything decorative would be in the way.
05What shipped
- Brand identity, and the marketing site at aervante.com.
- Member app for iOS and Android — Expo and React Native, built to a phone-only frame.
- Staff console — Next.js, with server-side privilege so staff powers can never be granted from a client.
- A shared, typed data model used by the app, the console and the server functions alike, kept in lock-step with the database rules.
- Membership tiers, request lifecycle, and the payment states around quoting.
06What it demonstrates
The reason this sits on a design office's site rather than a developer's: the identity and the data model were decided by the same person, in the same week. The gold does not appear in the app because a brand deck said so — it marks the concierge's own voice, and the moment a request is about to leave the member's hands. Confirmation is green. Nothing else on the screen is coloured at all. That is the argument for hiring one person who can hold both ends.
Aervante is this office's own venture. Screens shown use sample data. Nothing here represents a client engagement, and no client information appears on this page.
start a project→