Building an Enterprise API Platform for Technical and Non-Technical Users
How I transformed FullContact's fragmented developer experience into a unified identity resolution ecosystem—pairing a modernized API platform with a dual-surface dashboard built for both engineers and business stakeholders.
An Identity Platform with an Experience Problem
FullContact operates in identity resolution and data enrichment—domains where privacy is non-negotiable, reliability must be measurable, and APIs are the primary product surface. The technology was strong. The experience around it wasn't.
The developer experience was fragmented: APIs lacked consistent versioning, documentation and testing workflows were disjointed, and the dashboard was built almost entirely for engineers. Business users—product managers, operations teams, finance—had little visibility into usage, billing, or platform health without looping in an engineer.
The product surface didn't match the expectations of enterprise buyers who needed both deep technical control and operational clarity. This wasn't a feature gap. It was a platform design problem.
My Role: Senior Director, Product & Design
I owned product strategy for FullContact's API-first developer platform. I led a strategic pivot from consumer-facing products to enterprise developer APIs, partnered with engineering and executive leadership to align platform architecture with GTM priorities, and ran globally distributed product and design teams across the US, Latvia, and India.
No Consistent API Standards
Endpoints had inconsistent naming conventions, response schemas varied across services, and error handling was unpredictable. Enterprise developers building on the platform had no confidence in what to expect.
Dashboard Built for One Audience
The developer dashboard was designed exclusively for backend engineers. Business users who needed usage visibility, billing insight, or health monitoring had to route requests through engineering—creating friction and slowing decisions.
High Onboarding Friction
Getting from API signup to a successful first call required too many steps across too many disconnected surfaces. Documentation, sandbox environments, and key management were all fragmented experiences.
Trust Was Invisible
For a platform handling sensitive identity data, trust signals were nearly absent. Data handling disclosures were buried, audit trails were limited, and role-based access controls were immature—all barriers to enterprise procurement.
APIs Are the Engine. The Dashboard Is the Cockpit.
We reframed the platform around a clear thesis: FullContact needed to be a unified identity resolution API ecosystem with a dual-surface experience. Deep technical control for engineers, and operational clarity for business stakeholders—both as first-class experiences, not one primary and one afterthought.
Discovery work with existing enterprise customers revealed that the API quality itself wasn't the primary complaint. The friction was everything around it: how you integrated, how you monitored, how you understood your usage, how you governed access. The platform was a black box from the outside.
Working sessions with both technical and non-technical users mapped exactly where each persona got stuck, what they needed to feel confident, and what would make the platform feel intentional rather than stitched together.
Multi-Persona Research
Separate discovery sessions with backend engineers, product managers, and operations teams to map distinct needs.
Onboarding Journey Audit
Mapped every step from signup to first successful API call to identify friction points and drop-off moments.
Enterprise Trust Requirements
Reviewed procurement blockers with enterprise sales to understand what trust and governance signals were required.
API Standards Benchmarking
Reviewed developer experience benchmarks from leading API-first companies to set design standards.
"Enterprise developers care deeply about predictability. The goal wasn't a more powerful API—it was a more trustworthy one."
Platform Reconstruction, Not Iteration
This wasn't about shipping new API features. It was about rebuilding the platform's foundation—the standards, the structure, the surfaces—so that everything built on top of it could be trusted by both engineers and the organizations they worked within.
API Platform Modernization
We established consistent RESTful design standards across all endpoints: unified naming conventions, standardized response schemas, explicit error handling taxonomy, and clear rate limiting patterns. Structured API versioning reduced breaking changes and formalized deprecation timelines so enterprise customers could plan with confidence.
We also invested in observability—defined SLAs, improved monitoring instrumentation, and created clearer system health transparency. The "black box" perception was one of the biggest trust barriers with enterprise buyers. Making the system legible from the outside was as important as making it reliable on the inside.
Dual-Surface Dashboard
We rebuilt the developer dashboard around three distinct user types and their needs—not a single engineer persona. The result was a platform where both technical and non-technical users had a first-class experience.
Engineers
Business Users
Developer Experience as a Growth Strategy
We treated developer experience not as a UX concern but as a growth lever. Time-to-first-successful-API-call became a core metric. Every friction point between signup and that first successful call was a potential customer lost before they ever evaluated the technology itself.
Documentation, dashboard, and API behavior were aligned into a cohesive journey. We restructured documentation around example-driven learning paths, rebuilt sandbox environments for fast self-serve testing, and ensured inline code examples across the most common languages were always current and accurate.
We also embedded trust into the interface—not just the policy documents. Clear data handling disclosures, audit-friendly logging, role-based access patterns, and explicit governance workflows made trust visible at every step of the platform experience.
The Four Execution Pillars
API Standards & Versioning
Consistent design language across all endpoints with structured versioning and formal deprecation timelines
Dual-Surface Dashboard
Rebuilt from the ground up for both engineers and business stakeholders as first-class users
Onboarding Optimization
Streamlined journey from signup to first successful API call with example-driven documentation
Trust & Privacy Architecture
Audit trails, RBAC, and governance workflows designed into the interface—not bolted on afterward
A Platform That Finally Matched the Technology
The core outcome was alignment: the platform experience finally matched the quality of the underlying technology. Enterprise buyers who previously stalled in procurement gained the trust signals they needed. Developers who previously churned during onboarding found a path to their first successful call faster.
Internal teams—Sales, Marketing, Customer Success—gained a platform they could accurately represent and confidently sell, reducing the gap between what was promised and what was delivered.
Platform Identity Established
The work clarified FullContact's identity as an API-first platform—internally and externally. Engineering, Sales, and Marketing aligned around a consistent narrative. Documentation matched real system behavior. Platform clarity improved both buyer confidence and internal execution speed.
Architecture Aligned with GTM
Technical investments were explicitly tied to enterprise positioning. The platform wasn't just better—it was better in the ways enterprise buyers measured. Reliability was measurable. Privacy was visible. Integration was straightforward. That alignment compounded over time.
Facing a Similar Challenge?
Let's discuss how I can help transform your product strategy and drive measurable business outcomes.
Get in Touch