What working with a one-person practice actually looks like.
No account manager, no bench, no statement of work that takes three weeks to negotiate. Here's the whole process, the engagement models, how pricing is shaped, what the first month contains — and the things a solo practice is genuinely bad at.
01 The process
Four steps. The first one is free.
-
A 30-minute call
You describe the problem and the constraints — the deadline, the budget, the team, the thing that already failed once. You get a direct opinion on whether it should be built, bought, or left alone, plus the questions worth answering before anyone commits money. No slides, no charge, no follow-up sequence.
-
A scoped proposal
Within a few days: the approach, the deliverables, what's explicitly out of scope, the risks that would change the estimate, and a fixed price or day rate. One page. If a cheaper approach exists that doesn't need me, the proposal says so.
-
Build in the open
Code lands in your repositories from the first week, in your CI, reviewed by your team if you want it reviewed. Every week: working software plus a short written note on what shipped, what changed, and anything that moved the estimate. Problems get raised the week they're found, not at the deadline.
-
Handover, then leave
Infrastructure as code, tests, runbooks for the failure modes that actually occur, and a recorded walkthrough with your team. The goal is a platform you can run without me — a consultant who can't be removed is a liability, not an asset.
02 Engagement models
Three shapes, and how to tell which one you want.
Most engagements start as the first and become the second. The third exists because some platforms need an owner more than they need a project.
Architecture review
A week or two of reading your pipelines, your warehouse spend, your incident history and your roadmap — then a written assessment with a prioritised plan.
| Best when | A big decision is imminent and nobody in the room is neutral. |
|---|---|
| Pricing | Fixed price, agreed before it starts. |
| Output | A document you own and can execute without me. |
Scoped build
A defined thing gets built and handed over: a streaming layer, a migration, a modelling layer, a retrieval pipeline. Milestones, not a blank cheque.
| Best when | The what is clear and the how is the hard part. |
|---|---|
| Pricing | Fixed price per milestone, or a day rate where scope must stay open. |
| Output | Running software, tests, IaC, runbooks, handover. |
Monthly retainer
Reserved capacity each month for ownership, incident support and continued development — for teams that need a senior data engineer but not a full-time one.
| Best when | The platform exists and needs someone accountable for it. |
|---|---|
| Pricing | Monthly, for an agreed number of days. Rolling, cancellable. |
| Output | Continuity, a response time, and a backlog that moves. |
03 Pricing
How the number gets to be a number.
Pricing is quoted per engagement after the call, because a quote before understanding the data is a guess with a decimal point on it. What's fixed is how it's arrived at — and what would change it.
Fixed price where scope can be pinned down; a day rate where it genuinely can't; monthly where the need is ongoing. Estimates come with the assumptions written next to them, and if an assumption turns out to be wrong, you hear about it that week with options — not at the end with an invoice.
- Source data quality — the single most common surprise, in both directions
- How many upstream teams have to agree to a change
- Whether a legacy system has to stay live during the migration
- Compliance requirements that arrive after the design
- Access: how long until credentials and a repository actually exist
These are listed in every proposal, with the effect each would have. Nothing on this list should ever be a surprise in month two.
04 The first month
Week by week, on a typical build.
The shape varies with the work, but the principle doesn't: something real is running before the first invoice, and nothing important waits for a phase gate.
Access & ground truth
Credentials, repositories, and reading what exists. The first deliverable is usually an honest map of the current state — which is frequently the first time anyone has drawn one.
Thinnest working slice
One source, end to end, in the new shape — deployed, tested, observable. Small enough to throw away, real enough to prove the design.
Widen
More sources, more transformations, the failure modes that only appear on real volume. Data quality checks land alongside the pipelines, not after them.
Operability
Alerting, backfills, runbooks, cost review, and a checkpoint: what's left, what changed, and whether the original plan still makes sense.
05 Handover
The point is to become unnecessary.
The classic consulting failure mode is a platform only its author understands. Handover is treated as a deliverable with its own definition of done, not as a farewell email.
If your team can't deploy a change, diagnose a failure and add a new source without me, the engagement isn't finished — regardless of whether the software works.
- Everything in your repositories, nothing on my machine
- Infrastructure as code — the platform is rebuildable from scratch
- Tests and data quality checks that run in your CI
- Runbooks written for the failures that actually happen
- Decision records: what was chosen, what was rejected, and why
- A recorded walkthrough your next hire can watch
- A named person on your side who has deployed a change themselves
06 The trade-off
What a one-person practice is bad at.
The advantages are real: senior attention on every task, no coordination overhead, decisions made in minutes rather than in a steering committee. So are the limits — and you should know them before signing anything, not after.
Capacity is finite
One person can't parallelise a five-workstream programme. If you need four engineers by next month, an agency or a hiring plan is the right answer — and you'll be told that on the call rather than sold a version of it.
Bus factor
Mitigated by working in your repositories, documenting decisions, and treating handover as a deliverable — but it doesn't disappear. If continuity is critical, a retainer with a named backup contact is the honest structure.
Not everything is in scope
Deep specialisms outside data engineering — security auditing, hardware, mobile — are referrals, not stretch assignments. A generalist who claims everything is a generalist who has never been audited.
Availability isn't infinite
Start dates depend on current commitments, and holidays exist. Both get stated plainly during scoping — a start date that quietly slips is worse than one that was honest in the first place.
07 Questions
Before the first call
Bring the messy version of the problem. A vague description of a real issue is more useful than a tidy description of the solution you've already picked.
What happens on the first call?
How quickly can work start?
How is progress reported?
What if the scope turns out to be wrong?
Next step
Start with the free half hour.
Worst case you get a second opinion and spend nothing. Best case you leave with a plan and a straight answer about whether it's worth paying anyone to build it.