// 01 — web development

Web platforms that survive
their second year.

Most business software does not fail at launch. It fails eighteen months later, when nobody remembers why a decision was made and every change breaks two other things. We build for that second year from the first week.

// what we build

The shapes we
keep shipping.

Different names, same underlying discipline: a clear data model, typed contracts between layers, and a UI that does not lie about what the server actually did.

  1. 01

    Multi-tenant SaaS

    One codebase serving many customers with hard data isolation. We have built this for a diagnostics chain where every table is partitioned by tenant and the tenant id is carried in the auth token, so a query cannot accidentally cross a boundary.

    • Tenant isolation
    • Row-level scoping
    • Per-tenant config
  2. 02

    Internal dashboards & operations tools

    The screens your staff live in eight hours a day. These deserve more care than the marketing site, not less — keyboard flows, bulk actions, sane defaults, and states that survive a flaky connection.

    • Role-based access
    • Bulk actions
    • Audit trails
  3. 03

    Customer portals & booking systems

    Self-service for the things your team currently does over phone and WhatsApp. Availability, scheduling, payments, documents and notifications — with the awkward edge cases handled rather than hidden.

    • Scheduling
    • Payments
    • Notifications
    • PDF generation
  4. 04

    Marketplaces & commerce

    Multi-party flows where money, inventory and trust all move at once. Idempotent payment handling, reconciliation you can audit, and webhooks that do not silently drop.

    • Payment reconciliation
    • Idempotency
    • Webhooks
  5. 05

    Rescuing an existing codebase

    A large share of our work. We start read-only: architecture, dependency and security state, test coverage, and the riskiest areas. You get a written assessment and a prioritised plan before anyone changes a line.

    • Audit first
    • Incremental refactor
    • No big-bang rewrite

// how we build

Decisions written down, not remembered.

We start with the data model, because it is the thing that is expensive to change later. Screens can be redrawn in an afternoon; a schema that encoded the wrong assumption will still be costing you in three years.

Then contracts: typed interfaces between the client and the server, so a rename in the backend becomes a compile error rather than a production incident. Where the stack allows it, the types are generated from a single source rather than maintained twice.

We work in weekly slices on a URL you can open on your phone. You steer while steering is still cheap. There is no six-week silence followed by a reveal — that pattern is how projects end up building the wrong thing very competently.

And we write things down. Short specs with testable acceptance criteria before the work, and decision records explaining why afterwards. It is the difference between a codebase a new developer can join and one that only its author can safely touch.

// straight answers

Questions we get
every week.

How long does a web application take?

A focused internal tool is typically four to eight weeks. A multi-tenant SaaS with billing, roles and reporting is usually three to six months to a real first release. We give you a written scope with a range before you commit, and we would rather narrow the first release than miss the date.

Do you work with our existing team?

Yes. We can embed as a dedicated pod inside your repo and your stand-ups, or own a specific slice such as the API or the reporting layer while your team owns the rest. We are equally happy being handed the whole thing.

What stack do you use, and can we choose it?

Our default is Next.js, React and TypeScript on the front end, with NestJS or Laravel and PostgreSQL behind it. If you already run something else and it is sane, we will work in your stack rather than force a migration you did not ask for.

Who owns the code?

You do, in full, including the repository history and deployment configuration. We hand over documentation written for a developer who has never met us.

Can you take over a project another agency started?

Yes, and it is common. The first step is always a read-only audit so you get an honest picture of what you actually own before deciding how much of it to keep.

// next step

Tell us what is actually broken.

A short message is enough to start. The first scoping call is free, and you will be talking to the person who would write the code.