How We Work

Short engagements, clear outcomes

Data work goes wrong when scope is vague. Every HPDL engagement starts with a defined outcome, a defined end date, and a defined handover. There are no rolling retainers that continue because nobody agreed what finished looks like.

1. Discovery

We start by reading what exists rather than replacing it. That means profiling tables, tracing how data actually moves, and mapping the undocumented dependencies that make changes risky. You get a written picture of the current state, including the parts that are not in any diagram.

2. Design

Before code, we agree the target: contracts between systems, ownership of each dataset, quality thresholds that matter to the business, and the cutover sequence. Design decisions are recorded so the reasoning survives after the people who made them move on.

3. Build alongside the live system

The new pipeline is built next to the old one, not instead of it. Automated reconciliation compares both outputs daily, so differences surface while there is still time to correct them rather than on the morning of a switch.

4. Cutover

A cutover is a runbook, not a hope. Because the pipeline is idempotent, a failed source on the day can be restarted without duplicates. Reconciliation runs again immediately afterwards and the numbers are confirmed, not assumed.

5. Handover

You receive documentation, the monitoring configuration, and a walkthrough with the people who will own the system. If something is still unclear to your team at handover, the engagement is not finished.

What we need from you

A named technical contact, read access to the platforms involved, and access to the people who understand what the data is supposed to mean. Everything else we can work out. Start with a 30-minute call.

Working alongside your team

We work in your repositories, with your review process, on your platform. Branches are named clearly, commits are small enough to review, and pull requests explain the reasoning rather than only the change. Pairing is encouraged: the fastest way to make a handover succeed is to have your engineers involved while the work is happening, not afterwards.

Progress is visible without asking. Each week has a short written update covering what changed, what was verified, what is outstanding, and anything that needs a decision. If a decision is blocked, that is stated plainly instead of being absorbed silently into the timeline.

What we do not do

We do not take on work we cannot staff with senior people, we do not report progress in percentages that mean nothing, and we do not extend an engagement because the original scope was unclear. If the honest answer is that your existing team can solve the problem with guidance, we will say that rather than sell a project.

We also will not start a migration without a reconciliation method agreed in advance. A cutover without a way to prove the numbers match is not a plan, it is a hope with a calendar entry.