Engineering and AI

Web Application Development

Web apps, platforms and APIs built by engineers who also break them for a living. Authorisation, tenancy and failure paths are designed in before the first screen ships.

The costly problems in a web product are rarely clever. A tenant ID trusted from the request, an admin route that is hidden rather than protected, a background job that runs with more access than the user who queued it. Each is a design decision made early, under deadline, and hard to unpick once customers and data sit on top of it. They are also the kind of finding we write up when we test other teams' applications.

We start with the data model and the permission model, because both are hard to change later. Each feature carries a short threat model beside its acceptance criteria. Work ships in small increments to a staging environment you can click through, and security checks run in the same pipeline as the unit tests. Before launch, the team that runs our penetration tests puts it through a security test pass. You own the code and the infrastructure outright.

Usually, one of these is true

You are building a multi-tenant SaaS product and the next enterprise prospect will ask how one customer's data is kept away from another's.
A prototype has found real users, and the codebase now needs proper authorisation, safe migrations and tests before more features land on top of it.
Your API is about to open to partners or customers, and it needs versioning, scoped keys, rate limits and documentation it does not have yet.
A penetration test came back with authorisation findings that trace to the architecture rather than to one endpoint, and patching them one at a time is not working.

What we build

Product work from the data model up. Each area below is designed, built and tested by the same engineers, and documented for the team that will run it after us.

Architecture and data model. Service boundaries, schema design and migration strategy, with each significant decision written down as an architecture decision record your team can revisit.
Authentication and authorisation. Login, SSO, MFA and session handling, and a permission model enforced on the server for every object and role, not only hidden in the interface.
Multi-tenancy. Tenant isolation enforced at the query or database layer, tenant-aware jobs, caches and exports, and tests that deliberately try to cross the boundary.
API design. REST or GraphQL contracts written before the code, with versioning, pagination, idempotency keys on writes, rate limits, and webhooks that are signed and retried.
Frontend and accessibility. Interfaces built to WCAG 2.2 AA, performance budgets on the pages that matter, and forms that behave sensibly on errors, retries and slow connections.
Integrations and background work. Payments, email, search and third-party APIs behind their own adapters, with queues, retries and dead-letter handling for the work that happens off the request path.

How the build runs

We scope it with you in the chat, then send a written scope with a fixed price and fixed dates before any code is written. After that, working software sits on staging throughout, not only at the end.

Discovery. We walk through users, roles, data and integrations with the people who know them, and turn that into a written scope, a definition of the first release and a list of open questions.
Threat model. We draw the data model, trust boundaries and permission matrix, decide what to build and what to buy, and record each decision so it can be challenged later rather than rediscovered.
Build in increments. Features ship in small slices to staging, each with tests and a code review, and with static analysis and dependency checks in the pipeline before anything merges.
Security test pass. Before launch, the team that runs our penetration tests attacks the application as they would a client's: access control, business logic, injection and the API surface. Findings are fixed and verified before release.
Launch and handover. We deploy into your accounts, walk your engineers through the codebase and runbooks, and hand over admin access, secrets and the release process so nothing depends on us.

What you get

The application and its repositories. Source code with full commit history in repositories your organisation owns, deployed to cloud accounts in your name.
Architecture decision records. A short written record of each significant design choice and the reason for it, for the engineers who inherit the system.
Test suite and pipeline. Unit, integration and access-control tests running in a CI pipeline your team can trigger and change without us.
Security test pass report. Every pre-launch finding with a working reproduction, a CWE mapping and a CVSS v4.0 rating, plus a note of how it was fixed.
Runbooks and API reference. Setup, deployment, rollback, secret rotation and first-response steps for common incidents, plus reference documentation for every public endpoint.

What we need from you

A product owner who can make scope decisions and review each increment on staging.
Time with the people the application is for: operators, support staff or customers who know how the work is really done.
Cloud, domain and third-party accounts created in your organisation's name, with access granted to us for the length of the build.
Existing designs, brand assets, API specifications or legacy code the new system has to work with or replace.
Your security and compliance constraints up front: data residency, retention, audit logging and any customer contract terms that apply.

What we can show you

Built by people who test it. The team that builds your application also runs web application penetration tests, with 70+ CVEs published by our researchers and research acknowledged by Apple, Microsoft, Google OSS VRP, Facebook, Twitter, Adobe, Intel and the U.S. Department of Defense.
A test pass before launch, included. Every build gets a security test pass from our offensive team, and each finding is reproduced, mapped to CWE and rated with CVSS v4.0 before it is fixed.
Yours outright. You own the code, the repositories and the cloud accounts. Nothing depends on a framework or service only we control, and the runbooks are written so another team can take over.
Fixed scope, direct line. A written scope with a fixed price and fixed dates before work starts. You deal with the engineers writing the code, with no account-manager layer and no junior bench.

Standards we work to

The references we build and review against, so an enterprise buyer's security questionnaire or accessibility review can be answered from the work itself.

OWASP ASVS
OWASP API Security Top 10
NIST SP 800-218 (SSDF)
WCAG 2.2 AA
OpenAPI Specification
OAuth 2.0 and OpenID Connect

Common questions

What stack do you build in?

Usually whatever your team already runs and can hire for. We work across common web stacks, for example React, Next.js, Node, Go, Python and PostgreSQL, and we explain the choice in writing before committing to it. With no preference from you, we pick the most conventional option that fits the problem, because the next team has to maintain it.

Who owns the code and the infrastructure?

You do, outright. Repositories, cloud accounts, domains and third-party services are set up in your organisation's name from the start, and our access is removed at handover. There is no proprietary layer that ties the application to us.

How are scope changes handled?

The written scope describes the first release and what sits outside it. When something new comes up, we write down what it changes, including its effect on price and dates, and nothing starts until you agree. Swapping one feature for another of similar size is often the simplest route.

Is the pre-launch security test the same as an independent penetration test?

It is run by the team that does our penetration testing, to the same standard: every finding reproduced, mapped to CWE and rated with CVSS v4.0. Because we also built the application, some auditors and enterprise customers will want a test from a party that did not write the code. If that applies to you, tell us while we scope the work so it can be planned for.

What happens after launch?

Handover is the default end point: your team gets the code, the runbooks and a walkthrough, and can run the system without us. If you want us to stay involved for fixes, reviews or new features, that is scoped separately, for example as a retained block of time through On-Demand Risk Reduction.

Related services

Tell us about the system in the chat or on the contact page. Yaali, our AI agent, answers first and brings in an engineer.