Product

Development

Work with a defined end and a deliverable. A pipeline that has to exist, a report that has to be right, an extract that has to reconcile. Fixed scope, agreed in writing before anything starts.

What we take on

Four kinds of build

Scope is agreed before work begins, and we would rather decline a piece of work than deliver it below standard.

Data pipelines and integration

Ingestion, transformation and orchestration between systems, with dependency handling, restartability and alerting that reaches a person.

BI and reporting

Dashboards and semantic models built to refresh reliably at scale, with the data model underneath designed first rather than worked around.

ERP development

Extracts, interfaces and custom reports, built by people who know these systems from the extraction side where the documentation runs out.

Custom development

Stored procedures, data-processing services, internal tools and web front ends - built when an off-the-shelf answer genuinely does not exist.

Migration and cutover

Moving from one platform to another with parallel running and row-by-row comparison before anything is switched off.

Automation of the dull parts

The recurring manual steps between systems: reconciliations, reformatting, chasing exports. Often the highest return on the list.

How it ships

Every piece of work, the same way

These are not optional extras that get cut when a deadline moves. They are the reason the thing still works after we leave.

  • Tests written alongside the code, not after it
  • Source-to-target reconciliation counts on every load
  • Documentation written for whoever inherits it
  • Version control and reviewable change history
  • Delivered in increments you can see running
  • A runbook covering routine operation and recovery

Fit

When this is right, and when it is not

A good fit when

  • You know what needs building and want it done properly
  • An existing pipeline or report needs extending rather than replacing
  • You need extraction expertise your team does not have in-house
  • A migration needs someone who has done cutovers before

Probably not when

  • You need bodies on a long-term staffing basis - that is not what we do
  • The requirement is ongoing operation rather than a build - see Support
  • The requirement is not yet defined - start with an assessment

Tools

SQLPL/SQLPythonHTMLCSSJavaScriptPower BISAP BusinessObjectsSemantic modellingOrchestrationChange data captureGitREST APIs

Platforms we work on: ERP, warehouse and lakehouse platforms across the major vendors.

Have something that needs building?

Describe the scope. We will come back with an approach, an estimate and the risks we can see.

Start a conversation