Your own AI enabled data stack, built in weeks. Owned by you.

Human engineers collaborating with AI build your modern data solutions together, side by side, from end to end. Not a black box service full of features you do not need: ordinary code, in your cloud, that any engineer can review and maintain. The data and AI transformation project that can take a year, without the year.

Start a project →See what we build
architecture · illustrativeowned by you
  1. PR AI drafts the orders integration, engineer pushes a fix
  2. PR model customer_ltv, tests and docs generated
  3. PR run order a, b, c with a freshness gate
  4. PR report definitions synced from the models

01 The calendar

How a project runs →

Same destination.
Different calendar.

Most of a long engagement is weighted towards coordination over execution: discovery workshops, handoffs, status decks. Light on the real deliverables, heavy on the fluff. We start engineering the foundations from day one, so the feedback loops are fast and the iteration is rapid while discovery and refinement happen alongside.

THE TYPICAL PITCH 6 to 12 months

DiscoveryDesignBuildHandover

DYAD DATA weeks

ScopeBuildYours

Illustrative. Real timelines depend on scope; we fix it in writing before we start.

02 The whole loop

How the pair works →

An engineer and an AI build it together, start to finish.

From the first profiling of your data and architecture to a pipeline running in production, serving reporting, dashboards, AI agents and the critical systems and processes that run your business. The AI brings speed. The engineer brings the real-world expertise to make the calls, and signs off on the solution. That engineer can be ours, your in-house team, or both, with a human in the loop at every decision that matters. You decide with them at the points that count: the plan, the review and the ship.

---

  1. 01

    Intake and profile

    Point us at your existing data and tools. Read-only, safe by construction. The AI profiles structure, types, volume and velocity, and surfaces the critical components and gaps. The engineer talks to your people and judges what matters. No values kept.

    AI + engineer

  2. 02

    Plan

    A brief and a plan: what is new, what you already have, the open questions, and any extra instructions or context.

    ✋ you approve

  3. 03

    Build

    Data ingestion, integrations, data models, reporting, tests and documentation, written on one branch by the AI and the engineer, running locally first and kept in sync.

    AI + engineer

  4. 04

    Check and review

    Automated gates and independent reviewers, each covering only their own area. The reviewers and the engineer read every line, and the engineer decides.

    ✋ you decide

  5. 05

    Ship

    Merged to your codebase under your rules and applied to your cloud only when approved, after passing through a separate end-to-end QA environment you own.

    ✋ you approve

  6. 06

    Run

    Scheduling, monitoring and alerting, with run order and freshness gates built in.

    AI + alerts

Two parties, working as peers.

Neither is a tool for the other. Each does the part the other cannot do alone.

Engineer

Judgement, context and the final call

  • Gathers requirements and plans. Analyses the current state, talks to your people, and plans the future one.
  • Owns the architecture and every trade-off that comes with it.
  • Reads the code that ships, and is accountable for it.
  • Decides what is good enough, and what is not.
  • Signs off every merge.

AI pair

Speed, breadth and stamina

  • Profiles your whole estate. Structure, types, volume and velocity across every source, with gaps and critical components flagged.
  • Drafts the build at machine speed: scaffolding, models, tests and migrations.
  • Documents as it goes. Docs, lineage and decision records written with the code, never after.
  • Keeps watch. Run order, freshness gates and alerts, plus independent reviewers that each check one area.
  • Never merges its own work.

Together One branch, one codebase, one standard. We work code first, with industry-standard tooling that needs no special licence, specialised platform or other vendor, so any engineer and any AI can pick it up and carry on: ours, your in-house team, or a contractor you bring in later.

03 Two authors

What gets built →Every capability →What it works with →

Written by both. Signed off by a human.

Every change lands as a pull request in your code repository, whether it is a pipeline, a report, a small app, or your own internal AI-agent-powered tool. The AI drafts at speed. An engineer has all the oversight: they pull the same branch, add, remove or change code in their own editor alongside the AI, catch what it got wrong and decide what merges. You can see who did what, line by line.

No black boxes. Every line of code, every report and every endpoint is visible. Not as a special feature, but as a standard design principle.

  1. Details →
  2. Details →
  3. Details →
  4. Details →
  5. Details →
  6. Details →
  7. Details →
  8. Details →
AI pairdrafts fast
Engineercodes beside it, signs off
  1. 1AI drafts on a branch
  2. 2Engineer pulls it and codes alongside
  3. 3Both build on it, engineer merges
A conceptual example of the design. Sample code and data, not a client's work.

+ Around the code

Everything around the code is visible.

The code, the access, the pipelines, the lineage and the documentation are visible and built in from day one. Around them sits the tooling that keeps your platform documented, explainable, reviewed and safe to change, and it travels with the repo.

04.1

Local development, built in

The whole platform runs on a laptop. Identity, warehouse, reports, source APIs and the AI provider are emulated with small local servers, so any engineer can clone the repo, run the stack and test it end to end with no accounts and no spend. A local model can stand in for the AI. Infrastructure changes are planned and reviewed by a person before anything touches your cloud.

Details →

$ stack up --local
identity     emulated real signed tokens
warehouse    local database
reports      emulated
AI           scripted or a local model
source API   demo server

$ test --end-to-end
every seam exercised, no accounts, no spend
cloud: planned, reviewed, then applied

04.2

Documentation that writes itself and stays true

Every column carries its description and where it came from. Write it once upstream and it flows downstream, wherever the lineage is exact. A person's wording always beats a machine's, and nothing is overwritten silently. Descriptions sync into your reports as a pull request.

Details →

raw.orders.customer_idsource

Unique identifier of the customer.

↓ inherited
stg_orders.customer_idinherited

Unique identifier of the customer.

↓ refined by a person
mart.customer_idhuman

Unique customer id, shared across all sales channels.

04.3

Full lineage and blast radius

Column-level lineage from source to report, in one graph. Before anything changes you can see exactly what it touches: which models, which reports, which people to warn. Tickets, plans and deployments join the same graph, so the reason for a change is one click from the change.

Details →

ordersrefundsstg_ordersstg_refundscustomer_ltvnet_revenueexec_reportfin_report

change stg_orders → 2 models · 2 reports affected

04.4

A production line for data work

Different work gets different treatment, declared in one reviewed file. A documentation fix needs no model time. A new mart runs assess, plan, implement. An access request goes straight to a person. Routing is deterministic, every change passes the same automated gates, and the line stops for a human where a human belongs.

Details →

Docs fixa person's changegates
New martassessplan✋ approveimplementgates
Access requestescalate✋ a person decides

gates: secrets · conventions · contracts · reconciliation · sensitive data · controls

04.5

Point it at a source. Get the integration.

Point it at an API or at tables already in your warehouse. It probes and profiles the source automatically, read-only, with structure and types sampled and values never kept. It tells you what is new, what you already ingest and what is already modelled. Then the engineer and the AI build the integration together, pipeline, tests, documentation and run order, while you approve the plan and review the result.

Details →

$ probe /v2/orders   read-only
14 fields sampled, types inferred
key candidate: order_id (unique in sample)
no values kept

brief
orders      new
customers   already modelled read by 2 reports
refunds     already a source

plan  approved by engineer
build AI drafts ingest · tests · docs · run order
review pull request waiting for a person

04.6

Bring your own AI

Your provider, your account, your key. Route different jobs to different models, or run a local one. Every request is capped and counted against a budget, usage is logged without ever storing a prompt or a reply, and nothing is tied to a single vendor, so switching is a config change.

Details →

ai
provider   your own account, or a local model
key        a reference, never in code
route      planning   → strong model
           summaries  → small model
budget     capped per request and per run
log        usage counted, prompts never kept

04.7

An independent review agent, with separated concerns

Each pull request is reviewed by narrow reviewers that each own certain files, carry only their own rules, and are told what is out of scope. One checks data models, one checks infrastructure and security, one checks reports. Merging is decided by scanners, code owners and checks, never by a model's comment.

Details →

  • Data model reviewermodels/**tests, docs, naming
  • Security reviewerinfra/**least privilege, no secrets
  • Report reviewerbi/**measures documented, no credentials

merge is decided by scanners · code owners · checks

04.8

Guardrails you control

Who can do what, how much the AI can spend, what can leave the building, and which optional capabilities are on. Roles come from your identity provider, spend has limits and a kill switch, administrative changes are audited, outbound calls are restricted, and the AI works inside a boundary you can see.

Details →

  • Roles from your identity provider
  • Usage limits per person, and a kill switch
  • Administrative changes audited
  • Outbound calls restricted to known hosts
  • AI limited to approved plans and allowed paths

optional capabilities, per deployment

code reviewreport descriptionsdictionary explorerplain-language askvendor AI integrations

04 The walk-away test

What you own →

Cancel us on a Friday. Monday still works.

Friday

You end the contract.

Access closed. Handover delivered.

Monday

Pipelines ran. Dashboards loaded.

Nothing here needs us to keep it running.

We build for maintainability by any engineer: ours, your in-house team, or whoever you hire next.

  • 01

    It runs in your accounts

    Your cloud, your warehouse, your credentials. No dyad data runtime in the middle.

  • 02

    Any engineer can maintain it

    Open tools, readable source, standard conventions. Ours, your in-house team, or the next person you hire can pick it up and carry on.

  • 03

    It explains itself

    Decision records and runbooks ship with the code, so the why survives the hand-over.

  • 04

    Nothing to unplug

    No proprietary platform to leave behind. Staying is a choice, not a dependency.

Tell us what you are stuck with.

A few lines is plenty. You get an honest answer, including "you do not need us".

Start a project →