Foursquare 3 min readTurning Foursquare's location technology into a self-serve platform
Foursquare had 150,000+ developers using its API, but the SDK was still locked behind sales. The developer experience was fragmented across disconnected tools, docs, account surfaces, and brand systems.
I led the design of a unified, self-serve developer platform — shaping strategy, research, console UX, site architecture, and brand while directing two product designers and one brand designer, and partnering closely with product and engineering.
We shipped a rebuilt developer site, unified console, new brand system, and SDK demo app. For the first time, developers could access, configure, and understand the Foursquare SDK without going through sales.
The Foursquare SDK (called Pilgrim) could detect when a user entered a specific venue using GPS, Wi-Fi, Bluetooth, and Foursquare's place database — but access was gated through sales.
The rest of the developer experience was fragmented too. App creation lived inside the consumer product. Credentials were hard to manage. Usage was invisible. Documentation was disconnected from implementation. The console structure had also reached its limits and could not support new features on the roadmap without re-architecture.
The platform needed to serve three groups at once: independent developers experimenting with Foursquare tools, enterprise partners managing production apps, and internal teams supporting customer configurations.
Different users, same underlying problem: no clear path from discovery to working integration.
The original developer experience
App creation, credentials, and SDK access were fragmented across disconnected surfaces with no clear path for developers.
Before redesigning the console, we needed to understand where developers were getting stuck. We mapped the existing developer journey, audited the current console, reviewed comparable developer platforms, and spoke with independent developers, product, engineering, developer relations, and enterprise teams.
The work quickly made one thing clear: this was not a visual refresh. The console needed a new information architecture that could support developers from first API key to production usage.
"I don't even know where to start."
Developers knew what they wanted to build. The friction was understanding what Foursquare made available, what required approval, and how apps, credentials, and billing fit together before they could start.
Independent developer"There's no path from API to SDK."
After creating an app and getting a Foursquare API key, developers interested in the SDK had no clear next step. It lived behind a sales motion, which made the platform feel fragmented instead of connected.
Independent developer"I only find out when something breaks."
Usage was not visible until developers approached a billing threshold. There was no response-code breakdown, timeline view, or clear signal for when an app was misconfigured or growing unexpectedly.
Independent developerWe used the developer conversations to map what different audiences were thinking, feeling, and trying to accomplish: independent builders, enterprise evaluators, internal support teams, and developer relations.
This helped the team move away from isolated feature requests and toward a shared view of the core problem: developers needed clearer product guidance, more visible app state, and a console structure that could grow with Foursquare's platform.
Empathy mapping
Mapping what each audience type was thinking, feeling, and trying to accomplish.
User journey mapping
Identifying friction across the developer journey, from discovery to app creation, configuration, usage, and support.
Crazy 8s sketching
Rapidly exploring interface directions with product, engineering, and developer relations to align on possible paths forward.
The early wireframes explored how the console should be organized around the developer's app instead of around Foursquare's internal product lines. We tested ways to make app creation, credentials, usage, and SDK configuration feel like one connected workflow.
The goal was to answer a few structural questions before moving into visual design: Where should a developer land after sign-up? How should multiple apps be managed? Where do credentials, usage, and configuration belong? And how could the SDK become accessible without breaking the enterprise sales model?
Wireframes
Exploring app hierarchy, credentials, usage visibility, and SDK configuration.
The research kept surfacing the same three blockers. Each became a design directive.
Developers should be able to sign up, create an app, get credentials, configure the SDK, and start building without contacting sales.
Because usage thresholds affected billing, API and SDK usage needed to be visible before developers hit a limit.
The SDK was hard to understand through documentation alone — we needed to show what location-based experiences felt like in practice.
A new developer brand and design system. A rebuilt app management console. A relaunched Foursquare Developers site. And an SDK demo app — the first time any developer could experience what the Foursquare SDK actually did without going through sales.
Foursquare's consumer brand was not the right foundation for a developer product. We created a developer-specific visual system that felt connected to Foursquare but more technical, precise, and systems-oriented.
The system included new iconography, interface patterns, and design foundations for configuration, credentials, usage tracking, documentation, and app management.
It helped developers understand that Foursquare's location technology was a set of tools they could combine, configure, and scale.
The design system underpinned the entire platform — the console, the rebuilt Foursquare Developers site, and the SDK demo app. Components were built to be used out of the box where possible, and extended where the product needed a more specific approach. It was what made a five-month timeline viable.
Foursquare Developer design system
Color palette, icon library, component specs, and spacing — built to let engineering move fast without sacrificing consistency.
We shipped a unified developer console that brought app management, credentials, usage, and SDK configuration into one place for the first time. Developers could create apps, generate keys, configure SDK settings, and track API usage and billing thresholds without contacting anyone.
App overview
A single view for app status, credentials, usage, and SDK configuration — everything a developer needs without leaving the console.
The hardest design problem was app hierarchy. An app had to connect APIs, SDKs, credentials, configuration, usage, and billing in a way that worked for a solo developer on day one and an enterprise team in production. We tested multiple structures before landing on a model that scaled across both.
API usage
Developers could track call volume, error rates, and monthly quota usage in real time — broken down by API type and time range so issues were visible before they became billing surprises.
App configuration
Each app had a unified configuration surface for web addresses, credentials, notification settings, and Foursquare SDK setup — replacing a fragmented set of disconnected forms.
Before this project, the Foursquare SDK was a product developers had to take on faith. Access required a sales conversation, and the only way to understand what it did was to read about it.
We shipped a demo app for iOS and Android that sent real location-based pings — geofences, venue check-ins, visit timelines — so developers could see exactly what the SDK made possible before writing a single line of code. The Foursquare SDK became self-serve and tangible at the same time.
Foursquare SDK demo app
Login, live map, visit timeline, and check-in — real location triggers, no code required.
Four things shipped in five months — brand, console, site, and SDK demo app — with a cross-functional team of 17 across design, product, and engineering.
The Foursquare SDK moved from a sales-led product to self-serve, giving Foursquare's registered developer community a way to explore its most powerful location-awareness technology.
Developers could build, test, and launch with the SDK before entering a paid relationship, turning access into a scalable developer growth channel.
We shipped the developer site, app console, brand system, and SDK demo app as one connected experience — creating the foundation for future API, SDK, documentation, marketing, and enterprise support.
