Services

Six disciplines. One team that stays.

Most projects don't fail on the code. They fail in the gaps — between the designer and the developer, between the developer and whoever was supposed to test it, between launch and the first month of it being live. We took those gaps out by not having them.

01 · Web development

Interfaces that stay fast on the phone your customer actually owns

Product dashboards, back-offices and marketing sites, built in React and TypeScript against a Node and Postgres backend. We budget for the mid-range Android on a two-bar connection, because that is the device that decides whether your product feels good or not.

ReactTypeScriptNodePostgres ViteREST & OpenAPI
What you get
  • The repository, in your organisation, from the first commit
  • A running preview per branch, so review isn't a screenshot
  • Component library and design tokens, documented
  • Lighthouse budget agreed up front and enforced in CI
  • Handover doc: how to run it, deploy it and debug it
02 · Mobile apps

One codebase, two stores, and everything the stores actually demand

React Native for iOS and Android. The build is the easy half — the half that sinks schedules is signing, provisioning, review notes, privacy labels, push certificates and staged rollout. We have shipped our own app through all of it, so none of it is a surprise on your project.

React NativeiOSAndroidFCM push CrashlyticsOffline sync
What you get
  • Signed builds and the keystores, held in your accounts
  • Store listings written, screenshotted and submitted
  • Crash reporting and release health from day one
  • Offline behaviour designed, not discovered in the field
  • A staged rollout plan with a rollback you have rehearsed
03 · Quality assurance

So that shipping stops being a decision made on nerve

Automated suites that run on every push and block the merge when they fail, plus a manual pass on the things automation genuinely cannot see. The measure of this working is not a coverage number — it is that nobody is anxious on a Friday.

JestDetoxSupertestCI gates Load testing
What you get
  • Unit and integration suites wired into your pipeline
  • A test plan that names what is covered and what isn't
  • Regression pack for the flows that must never break
  • Load results against a target you agreed, not a vanity one
  • A red build blocks the merge — not a habit, a rule
04 · Security testing

A report your customer's security reviewer will accept

Threat modelling, authenticated and unauthenticated penetration testing, dependency and secret auditing, and transport hardening. Findings come ranked by what an attacker would actually do first, with a fix for each — not a scanner dump with two hundred informational rows.

OWASP ASVSTLS pinningSecret rotation Dependency auditRetest
What you get
  • Written report with severity, reproduction and remediation
  • Executive summary a non-engineer can act on
  • A free retest of every finding once you've fixed it
  • Rotation runbook for keys, tokens and certificates
  • Attestation letter you can send to a customer
05 · Product & design

Deciding what not to build is most of the job

We start from the record your business has to keep and the decisions it has to support, then design the smallest thing that keeps it. Expect us to argue a feature out of scope before we argue one in — that is where the money is saved.

Design systemsPrototypesFigma MotionAccessibility
What you get
  • A clickable prototype before a line of production code
  • Design tokens that the build actually consumes
  • A written scope naming what is explicitly out
  • Contrast and target sizes checked, not assumed
  • Source files, in your workspace
06 · Run & support

The boring parts of staying live, done by the people who built it

Deployment, monitoring, alerting, dependency upgrades and the occasional 2am question. We publish a support window we can genuinely hold — weekdays with a 24-hour reply — rather than implying a desk that does not exist. An agreed on-call window is available where the system warrants one.

DockerCI/CDObservability AlertingBackups
What you get
  • Dashboards and alerts pointed at your inbox, not only ours
  • A runbook for the five failures most likely to happen
  • Backup and restore tested, with the restore timed
  • Monthly dependency and security patch pass
  • Weekdays, 24h reply, written into the agreement
Engagement

Three ways to work with us. All of them priced before we start.

You will know the number and the date before any work happens. Changes are re-quoted rather than absorbed quietly and billed later as an overrun.

◧

Fixed-scope project

A written scope, a fixed price and a delivery date, split into phases you can stop after. Most new builds and rebuilds start here.

Quoted per phase
Typically 4–12 weeks per phase
◎

Monthly retainer

An agreed number of days a month for ongoing build, maintenance and support. Right when the product is live and the work is continuous rather than a project.

Agreed days per month
Rolling, one month's notice
⛨

Audit or review

A security review before a customer audit, a second opinion on a quote you have been given, or an assessment of a codebase you inherited. Fixed fee, written findings.

Fixed fee
Usually 1–2 weeks, retest included
How we work

Three phases, and you can stop after any of them.

Discuss & scope

A call, then a written scope with a fixed price and a date. If we think the idea is wrong, or cheaper to solve another way, you hear it here rather than after invoicing.

Build in the open

Two-week cycles against a running build you can open yourself. Tests and CI from the first commit, not bolted on at the end when they cost five times as much.

Ship & keep it up

Store submissions, deployment, monitoring and handover documentation. The code, the infrastructure and the accounts are yours from day one.

Questions

The ones worth asking before you sign anything.

How much does a project cost?

It depends on scope, and anyone who quotes before hearing the scope is guessing. What we will commit to is that you get a fixed number and a fixed date in writing before work starts, phase by phase — so the risk of being wrong sits with us, not with you.

Who owns the code and the accounts?

You do, from day one. Repositories, cloud accounts, app-store listings and domains are created in your name, not ours. Leaving is a transfer of access, not a negotiation.

Is testing an optional line item?

No. A build that isn't tested isn't finished, so we don't quote it as though it were a choice. The same goes for a basic security pass on anything handling money or personal data.

Can you take over something half-built?

Often, yes — it is one of the more common things we're asked for. We start with a fixed-fee assessment of what is there, what is salvageable and what isn't, and you get that in writing before deciding whether to continue.

What happens after launch?

Whatever you want to happen. A retainer if you want us running it, a clean handover with documentation if you don't, or nothing at all — the accounts are already yours, so walking away costs you nothing.

How big is the team, honestly?

Small. That is why you talk to the people writing the code instead of an account manager, and it is also why we take a limited number of projects at a time. If we're full, we'll tell you that rather than stretch and miss your date.

Let's talk

Tell us what has to exist by when.

Twenty minutes on the phone is usually enough for both of us to know whether this is worth doing. If it isn't, we'll say so and you'll have lost twenty minutes.