Technology & expertise

A narrow stack, and the practices around it

This page lists what the team genuinely works with. An honest, shorter list is more persuasive to a technical buyer than an exhaustive one — and it is the list we can be questioned on.

Talk to our engineers View our products

Stack

What we build on

Each group states why it is on the list. Technology chosen per project against performance and maintenance requirements, not house preference.

01

Languages & runtimes

A deliberately narrow set. Depth in a few runtimes produces more maintainable systems than shallow coverage of many.

  • TypeScript
  • JavaScript
  • Python
  • C#
  • PHP
  • SQL
  • Node.js
  • .NET
02

Web & application

Chosen per project against performance and maintenance requirements, not house preference.

  • Astro
  • React
  • Next.js
  • ASP.NET
  • Laravel
  • REST & JSON APIs
  • Progressive web apps
03

Cloud & infrastructure

Microsoft-centred, because that is where our certifications and the majority of our client estates sit.

  • Microsoft Azure
  • Microsoft 365
  • Entra ID
  • Docker
  • Linux server administration
  • Windows Server
  • CI/CD pipelines
04

Data

Relational first. We introduce specialised stores only where the access pattern genuinely requires one.

  • PostgreSQL
  • Microsoft SQL Server
  • MySQL
  • Redis
  • Vector search
  • ETL & migration tooling
  • Reporting & dashboards
05

AI & automation

Applied to bounded tasks with measurable outcomes, always behind a human approval step where output carries risk.

  • Document extraction & classification
  • Retrieval-augmented generation
  • Workflow automation
  • Evaluation harnesses
  • SATVIK AI (in-house)
06

Security & operations

Operational practice rather than a product list. These are the controls we apply to what we run.

  • Identity & access management
  • Endpoint protection
  • Backup & recovery testing
  • Monitoring & alerting
  • Patch management
  • Audit logging

Engineering practice

How we work on code

These are the standards applied to everything we build, including our own products. They are also the standards this website was built to.

01

Specification before implementation

Every build starts from a written specification covering scope, data model, interfaces and acceptance criteria. It is the document a disagreement gets resolved against, which is precisely why it exists.

02

Version control and reviewed changes

All work is in version control, and changes reach production through review. There is no direct editing of a live system as a normal working practice.

03

Automated testing where it earns its cost

Tests cover business logic, integration boundaries and anything that has broken once. We do not chase a coverage percentage for its own sake.

04

Tested recovery, not just backup

A backup that has never been restored is an assumption. Recovery procedures are exercised, and the result is documented.

05

Documentation as a deliverable

Administrator and technical documentation ships with the system. The measure is whether your team can operate it without calling us.

06

Performance and accessibility budgets

Front-end work is held to explicit budgets for payload, Core Web Vitals and WCAG-conscious contrast and keyboard support. A build that misses the budget is not finished.

Delivery

From discovery to handover

Six phases, each producing an artefact you can inspect. Nothing proceeds to the next phase on a verbal agreement.

  1. 01

    Discovery

    We establish the actual requirement, the systems already in place, and the constraints that are not negotiable. Fixed scope and fixed cost.

    Output

    Written requirement and constraint summary

  2. 02

    Specification

    Scope, architecture, data model, interfaces and acceptance criteria are documented and agreed before any build commitment is made.

    Output

    Technical specification and cost basis

  3. 03

    Build

    Delivered in reviewable increments against the specification, with a demonstrable state at the end of each one.

    Output

    Working increments in a staging environment

  4. 04

    Validation

    Testing against the acceptance criteria, including performance, access control and recovery. Findings are logged and resolved before release.

    Output

    Test results and resolved defect log

  5. 05

    Release & handover

    Deployment to production with documentation, administrator training and credentials transferred into your ownership.

    Output

    Live system, documentation and access in your name

  6. 06

    Support

    An optional service agreement with defined response targets, or a clean exit if you would rather run it yourselves.

    Output

    Service schedule, or a documented handover

Front-end budgets

We hold our own work to a number

Front-end work is delivered against explicit budgets rather than a subjective sense of "fast enough". A build that misses the budget is not finished.

Largest Contentful Paint
< 2.5s
Interaction to Next Paint
< 200ms
Cumulative Layout Shift
< 0.1
  • Static generation or server rendering by default; client-side JavaScript added only where it earns its cost.
  • Responsive AVIF/WebP imagery, lazy loading below the fold, and reserved dimensions so late media cannot shift layout.
  • WCAG-conscious contrast, full keyboard operation, visible focus states and reduced-motion support as acceptance criteria.
  • Tested on entry-level Android hardware, not only on a development machine.

Next step

Bring us an architecture question

If you are choosing between approaches, migrating a workload, or trying to work out whether a build is worth doing at all, a discovery conversation is the cheapest way to find out.

Talk to our engineers See all services