Custom software

Software shaped around the work.

For individuals and teams whose useful idea does not fit an off-the-shelf tool: a web application, an internal workflow or a clearer way to connect information.

Start with a real task

Bring the current workflow, intended users and one example of a successful outcome. We agree the first useful slice before choosing a stack.

  • Inputs: examples of the work, permitted data, existing systems and the decision owner.
  • Deliverables: an agreed application scope, interfaces, acceptance checks and operating notes.
  • Integration access and third-party licenses are confirmed during scoping.

From a sketch to a handover

Map the workflow, review a small working increment, validate behavior with representative data, then agree deployment and ownership. Your team should understand how to operate and change the result.

Boundaries worth agreeing early

Data migration, legacy-system repair, mobile apps, ongoing support and third-party subscriptions are separate unless included in the quote. A project conversation does not promise an unlimited build.

What useful evidence looks like

A labelled test fixture, a clear acceptance checklist and a demonstration of the agreed task can support handover. This is a delivery approach, not a customer case study.

A useful next step

Scope a software project

A rough outline is enough to start a scope conversation.

Scope a software project ↗

Content revised 2026-09-27.