Web platform development
A web platform is the app your customers sign in to every day, and the part that breaks first is rarely the interface. It is who can see what. Permissions start as an admin flag, grow into a role column, and end up as checks scattered through the codebase. Then the first large customer asks for teams, custom roles and an audit log, and nobody can say for certain what a given user can reach. We build that model properly, early, in Next.js and TypeScript.
Four ways this arrives.
We replace the role column with a permission model that can express teams, access to individual resources and roles the customer defines, add SAML or OIDC sign-in, and write the audit log their security questionnaire will ask about.
Or very nearly did. We find every query that can cross a tenant boundary, enforce the tenant in one layer rather than in every handler, and add tests that try to read across that boundary on purpose.
We build the admin side properly: search across organisations, an audited view-as-user mode, and screens for access and usage. Support stops asking an engineer to run a query against production every time a customer says something looks wrong.
An early Next.js app with auth stitched into middleware, a custom server, and a release process that lives in someone's head. We move it forward in small steps, with preview environments and a pipeline anyone on the team can ship from.
A Next.js platform scoped per organisation, where an administrator can view the app as any other user and each Tableau report opens only for people granted it.
Read the write-up →Asked on nearly every call.
What is wrong with a role column?+
Nothing, until you have more than one kind of customer. A role says who a user is; most real questions are about what they can do to one specific thing, inside one specific organisation. Encoded as role checks, every new requirement becomes a code change in many places. We model permissions as data, check them in one place, and test them like any other logic.
Should we use an auth provider or build our own?+
Use a provider for identity: passwords, magic links, SSO and multi-factor. It is a solved problem and getting it wrong is expensive. Authorisation, meaning what a signed-in user may do, is specific to your product and usually belongs in your own code and database. We wire the first to the second and keep the line between them clear.
How do you handle multi-tenancy?+
Usually one database with a tenant ID on every row, enforced in one place: Postgres row-level security, or a data-access layer every query has to pass through, rather than each handler remembering. A separate database per tenant is sometimes right, for one very large customer or strict isolation, and we will say if that applies to you.
Where does it get hosted?+
Wherever suits your team. Vercel is the least effort for Next.js and fine for most platforms. If cost or long-running background work make that awkward, we run it in containers on Railway, AWS or your own Kubernetes. The repository, the cloud accounts and the bill are in your name either way.
What do enterprise customers ask for, and can you build it?+
Single sign-on through SAML or OIDC, audit logs, role management, session controls, encryption and data export. We build each of them into the platform and help you answer the technical questions on a customer's checklist accurately, so the security conversation speeds the deal up instead of stalling it.