How do you help developers fall in love with your maps before they hate your setup?
Building a direct, self-serve developer platform so engineers could go from "curious about GrabMaps" to a working integration — in minutes, not days.
This case study is protected
This project is covered under a confidentiality agreement and isn't available for public viewing. If you're a recruiter or hiring manager, I'd love to walk you through it personally — just reach out and I'll get you access.
Good APIs. Terrible first impression.
If you wanted to use GrabMaps in late 2025, you had to go through AWS first. That meant signing into Amazon Location Service, picking the right region, creating Map, Place Index, and Route Calculator resources — and wiring them together before you ever saw a single tile on screen.
For AWS-native teams, this was "slightly annoying but fine." For everyone else, it was a deal-breaker. You had to buy into an entire cloud platform just to try a map.
But the old onboarding asked developers to do this:
By the time developers saw a map, some had already given up. The product — strong POI quality, real-time traffic, solid routing, SE Asia coverage — was hidden behind infra and process.
- — Setup fatigue. For non-AWS devs, ALS was a tax paid before touching GrabMaps. "Hello world" was buried under console work, IAM config, and unfamiliar docs.
- — No sandbox. There was nowhere to poke the APIs, see real responses, and quickly answer "Is this good enough for my use case?" without committing to infrastructure.
- — Generic positioning. From the outside, we looked like "another map provider"—not Grab, the company that actually runs transport and delivery across Southeast Asia.
One product. Two very different front doors.
We weren't designing "for developers" in the abstract. Two distinct audiences needed the same underlying APIs to feel completely different.
The serious developer
Building fleet dashboards, logistics routing engines, internal tools. They care about data quality, honest docs, and a fast path to their first working request.
The semi-technical builder
Ops folks, business owners, "vibecoders." They care about maps but don't want SDKs. They want to describe what they need and see it appear.
Developer interviews sharpened the picture. An interactive sandbox on the homepage isn't a gimmick — it's how devs judge capabilities fast. Automatic API key injection was praised; nobody misses copying tokens around. And we learned an important boundary:
Playground is for developers. It's an onboarding and discovery surface, not a standalone B2C product. One-off curiosity doesn't equal retention.
Three approaches. Two dead ends. One that worked.
The right experience didn't arrive all at once. Each iteration taught us something real about how developers think — and what they resent.
"Just show the AI everything"
Exposed all available query metadata to the agent. Transparent in theory — overwhelming in practice.
Auto-enabling routing for new users
Good intention — "more people see routing, more people use it." Developers disagreed, loudly.
Progressive disclosure + anchored results panel
Results moved to a persistent left panel. Chat stays in its column. Devs always know where their output lives.
Every "yes" had a "but."
- — Playground: developer tool or consumer product? We could have gone harder on the consumer angle — food trails, city tours, travel itineraries. But without deep consumer growth loops, it risked becoming a one-time toy. We made the call: Playground serves developers first, as a discovery and onboarding surface. Consumer is a future bet, not this launch.
- — Billing reality limited what we could build. Early infrastructure wasn't purpose-built for a polished, self-serve B2B experience. That constrained granular usage insights and flexible quota models at launch. We optimized for "reliably bill people at all" over "get fancy later."
- — Shipped intentional, not complete. Racing to hackathons and GrabX meant deferring things like full Playground docs, advanced templates, and rich support flows. We made peace with that — better to ship a coherent core than a bloated half-product.
Show value first. Stay in control.
The solution had a clear spine: reduce Time to Hello World, let developers evaluate at their own pace, and never make them feel like they're filling a form.
From landing page to live API — in two steps
The homepage connects directly to an interactive sandbox. The sign-up flow is a modal layered on top, not a separate auth experience. Land, sign in with Google or GitHub, and your API key is automatically injected — no token hunting, no config copying.
Dashboard: from "I see a map" to "I know what to build"
Once logged in, the dashboard surfaces example projects and usage patterns — making the leap from curiosity to first integration feel obvious, not intimidating.
Playground: the no-code front door
For builders who think in prompts, not SDKs, the Playground is the entry point. Type "best Thai food near Orchard" and see a curated, AI-generated map. Each result is a clear bridge into the docs and API references that made it possible.
Documentation as the product
The mindset shift that shaped everything else: documentation isn't supporting material — it's the product. Every friction point between discovery, sign-up, dashboard, and first successful integration was treated as a design bug. Competitive analysis of teams like Stripe reinforced this: their excellence isn't just the APIs — it's how they tell the story in product and docs together.
From "where do I start?" to "I built something."
Early developer feedback validated the core bet: the interactive sandbox became the default way engineers evaluated "is GrabMaps good enough for my use case?" — not the docs, not a sales call. Automatic API key injection cut out a whole class of setup support questions entirely.
On a strategic level, the work created a clear story and a ladder of access — from visual creators to vibecoders to full-code developers — all grounded in the same underlying APIs and data. Before, the answer to "how do I use GrabMaps?" was "contact sales." Now it's "try the Playground."
What I'd tell myself at the start.
Developers hate unnecessary complexity — they're just better at spotting it
Every iteration around routing defaults, results layout, and information overload was a reminder that developer-centred design is still human-centred design. "They're technical, they'll figure it out" is not a design principle.
Time to Hello World is a design problem
The sandbox, login modal, automatic key injection, and doc structure were all design levers to shorten that path — not nice-to-haves. Every minute we shaved off the first working request is a developer who stayed.
Sitting between strategy and execution is where the work actually happens
Saying no to the consumer Playground fantasy, or deferring richer templates and support flows, wasn't fun — but it kept the experience coherent and shippable. Design's job was to clarify what we're building and who it's really for, not just to make it look good.
"You could have been anywhere on the internet. Thanks for reading."
↑ BACK TO TOP