Authentication & identity integration

1.4–2.8 weeks typical Fixed quote after scoping

Identity as a project — sign-in providers (Apple, Google, magic link, email), team and tenant models, and hardened sessions for an existing product or an identity-heavy build.

Scope your project →

What we build

Sign-in for a product you already have, or the identity layer of one being built: Sign in with Apple, Google Sign-In, magic links, and email, wired through a managed identity platform across development, staging, and production. It goes well beyond the login screen — every record is scoped to its owner in the data layer, verified identity is injected server-side rather than trusted from the client, and sessions, admin access, and service-to-service calls are hardened by default. Our app builds include basic sign-in already; choose this when identity is the project: adding providers to an existing product, enforcing who-can-see-what across tenants, or locking down a system that grew faster than its access model. This owns the identity provider and server side of sign-in; the in-app sign-in screens are the platform accounts services, and rate limiting, bot protection and secrets are security hardening implementation. On a fresh app or web build, the platform's accounts service already covers sign-in — add this only when identity is a project in itself, and when both are on a plan the provider set is decided here once, with the accounts service mirroring it rather than re-asking the client.

What you get

  • Sign in with Apple working end to end
  • Google Sign-In working end to end
  • A test proving one user cannot read or write another user's records
  • A documented session policy (expiry, refresh, revocation) implemented and tested
  • A test proving requests without a verified identity are rejected

How the work unfolds

  1. Integrate Sign in with Apple and Google Sign-In
  2. Add email and magic-link authentication
  3. Enforce per-user data ownership in the data layer
  4. Inject verified identity server-side
  5. Harden sessions and tokens
  6. Set up device and app attestation
  7. Model roles, permissions and team membership

What shapes the price

Before you see a number, our scoping conversation asks:

  • Should people be able to sign up with an email address or magic link, as well as Apple and Google? Email and magic-link auth is its own verification plumbing. Decide the provider set here once — when an accounts family service is also on the plan, its provider questions mirror these answers rather than re-asking the client.
  • Is abuse from fake or modified clients a worry — bots, scripted sign-ups, tampered apps? Device/app attestation is real work most products defer until abuse appears.
  • Will accounts belong to teams or companies with roles inside them — or is every account one person? Role and team modelling is a chunk of data-model work individual-account products skip.

How an engagement starts

This work builds on Discovery workshop, so scope, boundaries and constraints are agreed before anything is built.

Teams often combine it with:

Get a priced plan →