Face verification API
B2B SaaS · developer audience · API + site
summary
- came in
- An API for developers to add face verification to their own apps: a two-part AI back end, liveness detection and face matching, a data model that stores no raw images, and a promotional site that speaks to developers.
- examined
- Which parts of the promise are measurable (latency, liveness, encryption, KVKK/GDPR), the conversion model (free API sign-up, upgrade to a paid tier, sales contact for enterprise), how the competitors (AWS Rekognition, Azure Face, FaceIO) present themselves.
- decisions
- The AI side is two separate parts, as in the brief; match and liveness return as two separate result fields. No images stored, only encrypted vectors. API first, then interface; a code sample on the site's first screen. The site was later reassessed; a new visual language was proposed as a clickable prototype.
- techniques
- Laravel API, face matching and liveness services, encrypted vector storage, webhooks; design system (Inter Tight + IBM Plex Mono, single accent), clickable prototype, a CC BY 4.0 licensed 3D wireframe model.
Where I looked
The job was an API that lets developers add face verification to their own apps, and a site to present it. The problem space was clear: passwords and SMS codes are easy to intercept; face recognition can replace them, but it is not safe as long as a photo or a video can fool it. Off-the-shelf cloud services also often leave developers unsure about data retention and KVKK / GDPR.
So I first looked at which parts of the promise are measurable, how a developer moves from a free sign-up to a paid tier, and how the competitors present themselves.
What I did and delivered
- A two-part AI back end. Two separate parts were written, as in the brief. Face matching extracts a face vector from the image, compares it with the enrolled vector and returns a confidence score. Liveness detection tells whether the image comes from a live person rather than a photo or video held up to the camera.
- API. Enrolment and verification endpoints, authentication, rate limits, webhooks for asynchronous flows and clear error codes. Every endpoint is documented with examples in four languages (cURL, Python, JavaScript, PHP).
- Data model. No raw image is stored; only an encrypted face vector is kept.
- Accounts and tiers. A flow that starts with a free sign-up and moves to a paid tier, plus an enterprise contact path.
- Promotional site. A bilingual site whose copy comes from translation keys.
- Redesign proposal. I later reassessed the site from the outside and proposed a new visual language and page structure; it remained a clickable prototype.
Decisions
- API first, then interface. The product's value is in the endpoints; the site was built to tell what the API says, accurately.
- Privacy by default. Not storing images was not a feature added later but the data model's starting decision.
- Two parts, two results. Match and liveness return in separate fields; developers can assess each on its own.
- Talk to developers like developers. Code samples, endpoints, error codes and rate limits come before marketing lines.
- Simplifying in the proposal. The five animation layers on the opening became one main visual (a 3D wireframe face that follows the cursor); the menu went from six items to four; API detail moved to the documentation; each page kept one primary and one secondary action; with no real customers yet, verifiable content (technical documentation, a demo, a security policy) was proposed instead of a logo wall.
- What an outside look showed. Animations that were fine one by one distracted together; documentation on the promotional page left both audiences half-served; placeholder content is a debt.