AppointMe.Today was a multi-vertical, on-demand service marketplace built for Bangladesh's urban market — a super app connecting customers to vetted professionals across home services, health & wellness, beauty, vehicle services, and wedding & events, alongside a corporate offering.
The central design problem wasn't any single screen — it was structural. Every new service vertical had evolved its own ad hoc pricing logic and intake flow. A customer booking an AC repair moved through a completely different experience than one booking a facial. That inconsistency was eroding trust and making the platform impossible to scale.
My job was to design one repeatable booking skeleton — category → sub-category → service → schedule → select provider → pay — that could hold seven wildly different service verticals without any of them feeling shoehorned.
By October 2018, the first MVP was live. By June 2019, the platform had 80,000 active users, 5,000 active service providers, and GMV had grown from BDT 0.51M to BDT 35M in twelve months. The product and its design artefacts supported a successful $130K seed round.

Research focused on the two users whose problems had to be solved simultaneously — the customer who couldn't get reliable help and the skilled professional who had no consistent channel for work. With a small initial user base (under 20 participants across both sides), the methods leaned qualitative: 1-on-1 interviews, competitive analysis, and direct field observation rather than large-scale surveys.
Pain-point synthesis from both sides of the marketplace — customers describing breakdowns in everyday life (a no-show housemaid, a broken AC) and prospective providers describing barriers to being found and hired.
Benchmarked AppointMe against three direct competitors — Sheba.xyz, HelloTask, HM — across seven dimensions: service variety, cost, availability, repeat reliability, 24/7 coverage, customer satisfaction, and women's empowerment.
Direct observation during the April 2018 pilot — watching real bookings unfold in real conditions surfaced the two breaking points (disputed job times, invisible earnings) that interviews alone hadn't caught.
| Platform | Service Variety | Cost | Availability | Repeat Reliability | 24/7 Coverage | Women's Empowerment |
|---|---|---|---|---|---|---|
| AppointMeUs | ||||||
| Sheba.xyz | ||||||
| HelloTask | ||||||
| HM |
"I can't trust it'll show up." No-shows from informal providers meant scrambling with no fallback, no escalation path, no record of the commitment.
Every service felt like a different product. Booking a beauty service versus a repair meant completely different flows, trust signals, and pricing presentation.
Phone calls were the backup, not the plan. Most relied on WhatsApp or referrals — ad hoc, unverifiable, and slow.
"My CV doesn't get me work." Skilled professionals had no platform designed for their profession — job portals filtered them out rather than connecting them to demand.
Earnings were opaque. No consistent way to track what they were making relative to hours invested — leaving providers unable to gauge if informal work was worth leaving.
Verification was a credibility gap. Without a platform-endorsed trust signal, skilled professionals couldn't differentiate themselves from unvetted competitors.
The three pain points each pointed to a different design problem. Trust needed to be visible before booking. Provider credibility had to be baked into the onboarding flow. And consistency required a shared structural skeleton — one decision tree that every vertical, from AC repair to bridal makeup, could inherit without reinventing the experience.

Before booking: the "AppointMe Benefit" screen surfaces the service guarantee and damage protection (BDT 4,000–10,000 depending on category) so the customer sees the safety net before committing. After booking: if a partner doesn't respond within 5 minutes, the flow escalates automatically — directly closing the "no-show, no fallback" gap that appeared in every customer interview.

Customers got stuck on the timer screen with no reliable way to confirm a job had started or ended. Manual "start/end work" button presses left room for disputes — a partner could claim a job started before they arrived, with no neutral record either side could point to.
QR-code job bookending. Each partner is issued a unique QR code per job on their partner app; the customer scans to mark start, scans again to mark completion. This replaced a self-reported, disputable timestamp with a verifiable shared action.
Maps directly to pain point one — removes the single biggest source of he-said-she-said conflict in the service window, the moment most likely to break trust permanently.
Partners had no clear way to see what they'd earned relative to the hours put in — job history existed, but it didn't translate into a legible sense of "is this worth my time." Early-stage churn was accelerating as a result.
Earnings-per-hour on the home screen. The partner app's home screen was redesigned to surface daily earnings against hours worked — front and centre on login, not buried in a wallet or history tab.
Addresses pain point two at the retention layer — turning an abstract "the platform sends me jobs" into a concrete, ongoing answer to "is this paying off," which keeps a verified provider active instead of churning back to informal work.
Wireframes were produced at two fidelities: low-fi sketches to validate structural decisions fast (can this decision tree hold AC repair and bridal makeup at the same time?), and mid-fi digital frames to stress-test the layout and handoff the booking skeleton before the April pilot.


The visual design had one constraint that overrode all others: a customer booking a housemaid and a customer booking a wedding photographer needed to feel like they were in the same product. That meant building a design system before building screens — colours, type scale, and component patterns that could flex across verticals without losing identity.


With a single developer building across Android and web simultaneously, the handoff system had to eliminate guesswork entirely. Every screen shipped with a paired spec document. Reused components meant no new design debt per vertical — the booking card, time picker, and provider card were specified once and inherited everywhere.
Every screen delivered with full spacing, states, and component references — so the developer could build without a follow-up call.
All spacing values defined in 8px base grid
All states documented — default, loading, empty, error
Touch targets annotated at 44px minimum
Responsive behaviour noted per component
Shared patterns for booking cards, time pickers, provider profiles, and confirmation screens — specified once, reused across all 30+ categories.
Booking card variants: service, confirmation, history
Provider profile card with verification badge states
Time picker component with conflict and unavailable states
QR-code scan screen with success, error, and timeout states
Consistent naming, file structure, and component organisation kept the design library navigable as scope expanded across verticals.
Shared file structure — one source of truth per surface
New verticals assembled from existing components — no rebuild required
Layer naming convention matched developer component names
Each new service category was documented with its pricing logic, intake questions, and inclusion/exclusion rules mapped to the shared booking skeleton.
Pricing model (fixed, per-unit, quote-based) documented per vertical
Intake question sets (AC tonnage, sofa-seat count, etc.) per service
Inclusion / exclusion rules for each vertical's scope

Founding team assembled. UX discovery begins — stakeholder interviews, competitive analysis, and service documentation audit running in parallel.
Limited pilot in Dhaka with a small cohort of customers and providers. Field observation uncovers the two critical iteration points: disputed job times and invisible earnings.
Provider-side Android app launched with full onboarding flow, document verification, skill tests, and QR-code job start/end system in place.
Web platform live — extending booking access beyond app install, targeting corporate customers and web-first users.
Full customer-facing Android app launches with 30+ service categories, 600+ active verified providers, and emergency phone support. Company incorporated in Bangladesh.
AppointMe.Today formally incorporated in Singapore — marking the international expansion milestone alongside continued Dhaka operations.
GMV reaches BDT 35M (from BDT 0.51M), active users hit 80,000 (from 2,000), active providers reach 5,000 (from 65). $130K seed round closed. 80% process automation, 40 strategic partnerships, full Dhaka coverage.
BDT millions · July 2018 – June 2019
Booking assignment, partner matching, and payment processing automated — reducing manual ops overhead as volume scaled 68×.
Corporate and B2B partnerships formed, extending the platform beyond consumer bookings into enterprise service contracts.
Service available anywhere in Dhaka by June 2019 — from initial pilot zones to full metropolitan coverage in under 12 months.
Average active provider generated ~BDT 140K in sales over a half-year (~BDT 24K/month), translating to ~BDT 40K annual platform revenue per provider at 15% commission.
Android app, responsive web, and emergency phone support — ensuring no customer was blocked by device access or app install friction.
Fundraising ask: BDT 20M for 20% equity at BDT 100M valuation. Design artefacts and prototypes directly supported the pitch and investment narrative.
Investment pitches live or die on whether investors can see the product before it exists. The prototypes, user flows, and design artefacts built for AppointMe's pitch communicated the product vision with enough clarity and craft that investors could feel the experience, not just read about it.
The 68× GMV growth and 77× provider growth weren't just business outcomes — they were the delayed signal that the early structural decisions were correct. Standardizing the service taxonomy (category → sub-category → service) is what let the platform scale to 30+ categories without rebuilding the booking flow each time. The IA decision shows up directly in the speed of vertical expansion.
The trust mechanisms tied to specific pain points — the QR-code job verification and the earnings home screen — weren't cosmetic. The fact that provider retention held as volume grew 77× suggests that early, narrow fixes compounded into platform-level retention.
One honest gap: there's no user satisfaction score (NPS/CSAT) in the materials. The competitive slide claims "Very high" customer satisfaction, but that's a pitch deck assertion, not a measured result. I'd want to run structured CSAT tracking from month one in any future 0→1 engagement — and the absence of it here is the thing I'd do differently.
IA is product strategy. The decision to standardise the taxonomy before designing any screen determined how fast the platform could grow. Vertical expansion became assembly, not invention.
Trust needs a specific address. Vague "trust signals" don't work. The QR code and the 5-minute escalation each solve a specific, named failure mode — and that specificity is what makes them hold under real conditions.
Provider retention is a design problem. The earnings home screen isn't a nice-to-have — it's what closes the gap between "I have a profile" and "I keep showing up." Supply-side design is the underfunded half of marketplace UX.
Measure satisfaction from day one. GMV and user counts are necessary but lagging indicators. A fast NPS loop would have let iteration happen on the right things, not just the loudest ones.
Every screen shipped with production-ready specs — spacing, all states, responsive behaviour, and component references — so the sole developer could build across Android, web, and partner app without back-and-forth.
Consistent naming, file structure, and component organisation kept the design library navigable as the product grew from pilot to 30+ categories across three platforms in eight months.
Shared patterns for booking cards, time pickers, provider profiles, and confirmation screens meant each new vertical was assembled from existing parts — new categories launched without new design debt.