Services
Data warehouse modernization, delivered as a fixed scope.
The rebuild that stays on the roadmap because it is expensive and never urgent. We take it as a fixed scope — one named domain, one migration, one set of definitions — and hand back models your team owns.
Two operators who have run data platforms at scale, delivering with the software described on this site. The tool performs the reading and the generation; we scope the work, review its output, and remain until your reviewer accepts it. Everything we produce is yours to keep.
Both frames are the tool reading our own reference warehouse, not a customer’s, and the figures visible in them are its scoring of that fixture. They are here to show the shape of the work, not to stand as a result. We have not published a measured outcome yet, and we would rather leave that space empty than fill it with a number we have not earned.
How an engagement runs
Five stages, and you can stop after any of them.
Every engagement below runs this shape. The first two stages change nothing in your warehouse, and nothing after them proceeds without your explicit approval of the plan.
Scope
Thirty minutes on your warehouse, your engines and what is forcing the issue. We write the scope and its exclusions down before anyone signs anything.
Your sideOne call. If we are not the right fit we say so here.
Read
The tool reads every table it can reach — lineage to the column, where a metric is defined more than once, what each model costs to run. Read-only credentials, no changes.
Your sideRead-only credentials, and someone who can answer questions about intent.
Agree
We walk the findings with you in a working session, not a PDF. You see the proposed layers against what is deployed today, and the business logic we intend to keep and to drop.
Your sideA working session, and decisions on anything contested.
Build
The models are generated and run against your warehouse in a staging schema, with the checks described below. Nothing is deployed into production.
Your sideA staging schema we can build into.
Hand over
You take the models, the tests and the documentation. We stay until your named reviewer accepts the work, and then we leave.
Your sideOne reviewer with a mandate to accept it.
The one condition we do not flex on
Every engagement needs one named person with the authority to accept the work. It is the entry condition, not a formality: the way these projects fail is not bad models, it is good models that are delivered and never adopted, and the only reliable guard against that is somebody on your side whose job it is to say yes. If nobody has that mandate, we would rather wait until someone does.
The engagements
Six engagements. Each one names what it will not do.
Scope that expands after signature is the common failure in this category, and you have probably bought consulting before and watched it happen. Every engagement below states its deliverable, what we require from you, how long it runs, and what is explicitly excluded — on this page, before any call.
Everything begins with a read
We do not quote a rebuild for a warehouse we have not read. An estimate made without one would be wrong.
Read-only · fixed and short
Warehouse Audit
In scope: A full read of every table, a prioritised fix map, and a working session to walk it.
Out of scope: Any change to your warehouse. This one is read-only by design.
Four ways the work goes on
All four are the same delivery underneath. They are named separately because they answer different reasons for starting.
One domain · scope-priced
Medallion Rebuild
In scope: One named domain redesigned into clean layers, run against your warehouse before handover, with the tests we ran handed over alongside the models.
Out of scope: Orchestration changes, BI rework, and deploying anything into production.
Legacy in, Snowflake out
Migrate Clean
In scope: Your warehouse re-architected on the way over, delivered on Snowflake.
Out of scope: The infrastructure cutover, dual-running, and re-pointing your BI tools.
Definitions · scope-priced
Context Layer
In scope: One agreed definition per metric, written back as models you own, so a plain-English question has one answer.
Out of scope: Ruling on which definition wins. We surface every conflict with its lineage; your owners decide.
Two warehouses · scope-priced
Two Warehouses, One Definition
In scope: Both warehouses read, every conflicting definition surfaced with its lineage, one reconciled set.
Out of scope: Ruling on which definition wins. We recommend; you decide.
One engagement instead of three procurements
Delivered in stages with an acceptance point at each one, so you are not committing to all of it on day one.
Our primary engagement
Full AI Data Transformation
In scope: The audit, the rebuild and the context layer run end to end by us, delivered in stages with an acceptance point at each one. An agent pointed at an undefined warehouse still returns a confident answer; this is about it also being the correct one.
Out of scope: Choosing or standing up your agent platform. We make the warehouse fit to be queried; we do not build the agent.
Plain language
What we mean when we say tested.
We generate the models, run them against your Snowflake or Athena connection, and check that each
one returns rows, that its primary key is unique, that no column comes back completely empty, and
that the types are what we said they’d be. On top of that we run dbt’s own generic
tests — not-null, unique, accepted values, and foreign keys against their parent — and
hand you the schema.yml for them, so the tests we ran are tests you keep.
Where a test can’t be evaluated soundly it comes back marked skipped, never passed. We
don’t run a full dbt build, and we don’t compare your old numbers against
the new ones row by row. If a figure has to reconcile exactly, that’s a conversation for the
call.
We write this out because “tested” is the word most likely to mean something different to you than it does to us, and finding that out in month three is how these projects go wrong.
Engines and fit
Two engines today, and four reasons we would turn you down.
We would rather you found this out here than six weeks into an engagement. Where a connector is still being written, it says so.
- Snowflake Read, generate and test. The default engine, and the one every engagement below assumes unless we say otherwise. ✓ Available
- Athena + Glue The Glue catalog read directly, queried through Athena. On this engine the deliverable is plain SQL rather than dbt-shaped models. ✓ Available
- Redshift Today we read a Redshift warehouse and deliver it re-architected and tested on Snowflake. A direct connector is scoped but not built, so intake is your code rather than a live connection. Source only
- Databricks Connector in development. Not available today, and we will not scope an engagement against it until it is. In development
Other engines
Regulated data
One-person warehouses
No named reviewer
Who does the work
Two people, and you will have met both of them.
There is no bench
Both founders take the scoping calls and both do the delivery. There is no offshore team and nobody you have not spoken to. That is a real constraint on how much we take on at once, and it is the reason we scope tightly rather than a slogan about attention to detail.
Where we are, stated plainly
In beta with our first design partners. No customer has yet run our generated SQL in production — establishing that is what this phase is for, and we would rather say it here than have you discover it on the call.
Questions
The things we get asked on every call.
Do we have to do the audit first?
For anything that rebuilds, yes. The audit is what makes a rebuild possible to scope, and we do not quote one for a warehouse we have not read — a number produced without it would be a guess dressed up as an estimate.
It is also the cheapest way to find out we are wrong. If the findings say a rebuild is not warranted, we will tell you that, and the fix map is yours regardless.
Will teams really run AI-generated SQL in production?
That is the single thing this phase of the company exists to find out, and the honest answer today is that no partner has done it yet. We would rather write that down than have you ask it on a call and watch us hedge.
What we can say is what happens before handover: the models run against your warehouse, they pass the checks described above, and the tests come with them. What you do with them after that is your decision, made with your reviewer, on your timetable.
What stops the scope growing once we have signed?
The exclusions are written down before signature, on this website, where you can read them without a call. Every engagement page carries a “not in scope” block, and it is always rendered — there is no version of these pages where it is quietly dropped because the list was short that week.
Work outside the named scope is a new engagement with its own scope, not a change order against this one.
What happens after you leave? Are we dependent on you?
Everything we produce is yours to keep and runs without us: the SQL models, the macros, the
sources file, the schema.yml of tests, and the documentation. Nothing calls back to
us and nothing expires.
We are also not going to pretend a rebuild is permanent. Warehouses re-tangle — the question is whether you find out in three years or next quarter. We are still working out whether an ongoing arrangement is worth paying for, which is why there is no subscription on this page for you to be talked into.
Why not do this ourselves with an AI coding assistant?
You could, and some teams should. The people who tell us this usually have not, and the reason is rarely capability — it is that the rebuild loses to whatever is on fire this quarter, every quarter.
The part that is genuinely harder to assemble yourself is the loop: generating the models, executing them against your live engine, reading what failed, and repairing until they pass. That is what the tool does, and it is why an engagement is measured in the reading rather than in months of someone’s time.
Who sees our data?
The question we get asked first, and it deserves a fuller answer than a paragraph here, because the accurate one has detail in it. We confirm the executed agreements and the terms we operate under in writing, with the full sub-processor list, as part of your security review — before an engagement starts, not after.
We would rather you did not take that on our word on a marketing page. Ask for it on the call and we will put it in front of you.
What does it cost?
We do not publish prices, and we are not going to invent a range to fill this space. The audit is fixed and short; everything downstream is scope-priced from what the audit finds, which is the only basis that produces a number worth honouring.
You will get that number on the call, against a written scope with its exclusions attached.
Begin with the audit.
Read-only, fixed in scope, and concluding in a working session. If the findings indicate that a rebuild is not warranted, we will say so.