Skip to content

Language

TypeScript Development

We write TypeScript across the stack so the shape of a record is checked at the boundary and a rename cannot quietly break a screen three modules away.

Laptop on a software development workspace

Usage

What we build with TypeScript

  1. Application backends and API layers
  2. React and Next.js front ends
  3. Shared validation schemas used by client and server
  4. Integration adapters and workers
  5. Content collections that fail the build when an entry is malformed
  6. Command line tooling and build scripts

Rationale

Why we choose it

  • Refactoring becomes safe

    Renaming a field or changing a shape surfaces every affected call site at compile time. Without that, a rename in a large codebase is an act of faith.

  • Types document the contract

    A typed function signature is documentation that cannot go out of date, which matters most at handover.

  • One language across the boundary

    The same types describe the API response and the component that renders it, so a mismatch is a compile error rather than a runtime surprise.

Practice

Architecture patterns we use

  • Parse at the boundary

    External input is validated with a schema that produces a typed value. Inside the boundary the type is trusted because it was checked, not because it was declared.

  • Discriminated unions for state

    Loading, success and error are modelled as one union rather than three loose booleans, which makes impossible states unrepresentable.

  • Strict mode always

    Strict null checks on from the first commit. Adding them later to a large codebase is a project in itself.

  • Typed content collections

    Content entries are typed, so a missing field or a link to a slug that does not exist fails the build rather than producing a broken page.

Build with our TypeScript engineers

Tell us what you are building and what it has to connect to. We will come back with an approach, a scope and what it would take.

  • A mutual NDA is signed before project details are shared.
  • Scope is fixed in writing before any build starts.
  • You own the source code, the IP and the documentation at delivery.
  • Support plans are available and tailored on a discovery or technical call.