What we solve

Most problems in a data platform are laid down before the build begins

They arise when decisions are made on a current state that is only partly known. Below are the four situations we meet most often. If you recognise any of them, we know what it looks like from the inside.

01 · The reports

Two reports answer the same question differently

The business asks how many customers you had in March and gets two answers. Both look plausible, and the question of which one holds is left hanging.

It usually comes down to

  • The same metric is defined in several places, by different people, at different times.
  • The definitions have drifted apart on their own, step by step.
  • One report reads from a layer that has stopped updating.

How we find out

AI reads every model, script and report. Exhaustively, not by sampling, and therefore in days. Our developers then trace the metric back to the source and determine which definition you should keep.

02 · Production

Nobody knows for certain what is actually running

You are about to migrate or change something. The question of what is in production, what is dead and what depends on what gets different answers depending on who you ask.

It usually comes down to

  • The platform has grown over many years, through several teams and several sets of priorities.
  • The documentation describes the plan, while the code describes reality.
  • Dependencies only reveal themselves when something breaks.

How we find out

AI reads code, configuration, schemas and run logs, exhaustively. That is the part that otherwise takes months. Our developers then separate what has been built from what is in production, and set an order based on dependencies and risk.

03 · The decision material

Decisions rest on figures nobody will stand behind

The data exists. Everyone double-checks it anyway, so decisions still land on gut feel, only slower.

It usually shows up like this

  • The business builds its own side calculations alongside the reports.
  • Meetings go into comparing numbers rather than making decisions.
  • The pace of decision-making is the same as before the platform.

How we find out

You point out a piece of decision material that has to be trustworthy. AI reads every model and report feeding it, and our developers assess whether the data carries the decision. The answer is one you can put in front of a board.

04 · The source data

You are about to build and do not know whether the data holds

The decision to build has been made. The question is whether the source contains what you are counting on.

It usually comes down to

  • The source was built to drive a process, and is now being used for analysis.
  • Fields assumed to be populated are empty in half the material.
  • The history starts later than the trend you want to be able to follow.

How we find out

We profile the source with AI against an information need you identify, and measure what determines whether you can build what you intended. Otherwise the most expensive discovery in a data project arrives late.

Why it goes fast

We call the way we work RAID

We use AI for more than writing code: it runs through the whole of the work, from planning, requirements and architecture to testing, documentation and deployment. The human owns the decisions at every step.

That is why an assessment of the current state takes days rather than months.

How we work →
11 of 12
steps in the development process where AI is used, each time with review
One fifth
of the calendar time, and roughly one eighth of the hours, compared with the same work done manually
The first step

A bounded first step

Whichever situation you recognise, we start the same way: we find out how things actually look, before anyone decides what to build. Which of the two it becomes depends on where you stand.

If you are building something new

Source data profiling

  • One source system, one database or one data mart
  • Up to 25 objects
  • A written data report plus an hour-long walkthrough
  • Leads on to the source connected, at a fixed price
If you are migrating or building further

Assessment of an existing system

  • One repository, one bounded subsystem or one data mart
  • Up to 150 objects
  • A written engagement assessment plus an hour-long walkthrough
  • Leads on to migration in increments, at a fixed price per increment
10
working days
3 to 4
hours of your time
Yours
the report is yours, whether or not anything else follows

A fixed price once the scope is defined. You know what it costs before we start.

We sell units: one source, one system, one subject area. The deliverable defines when something is finished.

Next step

Does any of this sound familiar?

Three ways to take it further.

01

Read a case study

The figures and the mechanism behind them, anonymised.

To case studies →02

Read what we have written

Spec-driven development with AI, described step by step. No form.

To insights →03

Book twenty minutes

A conversation about your situation. We listen more than we present.

Book a meeting →