Book the follow-up call

For Martin, Jamie and Jan

Yes. We can rebuild it without your data engineers.

Two ways we could start, and the questions we need answered to come back with an indicative yes, a cost and a duration.

Bijan Soltani

Bijan Soltani · Founder & Managing Director, Gemma Analytics

Hi Martin, Jamie and Jan,

Thank you for a genuinely straight conversation on Thursday. You asked whether we could go in, work the engine out without taking your data engineers off their day jobs, and rebuild it. The answer is yes, and we would be glad to.

This is squarely our lane: greenfield data platforms, data engineering, and standing up an entire data function from nothing. Around a hundred projects over seven years. We can be on this in the week of 21 September.

Below are the ways we could start, and the questions we need answered to come back with an indicative yes, a cost and a duration. All of it is open to being reshaped on the follow-up call.

The question you asked twice

Have we done this before?

Straight answer yes. Honest answer: not behind a full seal. We have rebuilt estates whose authors had already left and who left nothing behind but the system itself. Doing it with the incumbent team still in the building and deliberately out of scope is the part that is new.

What we have done. We have walked into estates where one or two people had built the whole thing and were gone: sick, poached, or simply finished with their employer. Nobody left behind knew how it worked. We reconstructed what it did from the system itself, then rebuilt it properly.

What is new here. A sealed lab, with your engineers still in post and deliberately untouched, is not something we have run in exactly that shape. We do not see why it would not work, and we would rather say that plainly now than discover it together in November.

The difference cuts both ways. We would have less engineering knowledge available than we usually do. We would have far more of the business available than we usually do, and that is where the answers about what a number is actually supposed to mean live anyway.

Where we would start. Not with the schema. With two lists: what today's data produces that has to keep working, and what it does not produce that you need next. Everything else follows from those, and getting them right before anyone builds is what decides whether this lands.

How we could start

Two ways in

Same people either way. What differs is how much you want to know before you commit, and who carries which risk. Our day rate is €1,280, and both figures below are built from it. We contract in euros and are happy to quote the sterling equivalent at the rate on the day.

Start now, against a budget you set Our most senior engineer in from the week of 21 September, the team ramping behind them. A budget rather than a fixed outcome: €50,000 as our anchor, slide it anywhere between €30,000 and €80,000.
  • We start in the week of 21 September. No mobilisation phase and no discovery gate. You asked for the quickest route to movement, and this is it.
  • Most senior engineer first. They go in on day one and begin working the estate out from the inside, on the access you give us rather than on anyone’s time.
  • The team ramps behind them. A project lead and one engineer, to two, and to three if the work asks for it. We size to what we find, not to what we guessed in September.
  • A budget, not a fixed outcome. We will not pretend to know the endpoint before we have seen the estate, so we commit to the money instead. €50,000 is our anchor; set it anywhere between €30,000 and €80,000 and we shape the run around it.

Roadmap

  • Week one, access and orientation. The senior engineer reads the system rather than the people: databases, code, orchestration, logs and change history. Out of it come the two lists — what must keep working, and what is missing.
  • Weeks two to four, reconstruct the logic. The project lead joins. We map the flows that actually matter — point of sale into policy administration, the finance feeds, renewals — and write down what each does and what it is meant to mean. Documented as we go, in your repository.
  • From week four, build in the lab. Two engineers, three if the work asks for it. A transformation layer under version control, business definitions, and a semantic layer other people can build on.
  • At the budget line, stop and look. We show what runs, what is documented and what is left. You decide the next tranche against evidence rather than an estimate, in good time for February.

What we would need from you to start

From our standing kick-off checklist, with one change: every line names an owner who is not one of your data engineers.

  • Read access to the platform the estate runs on, and to the reporting database. Admin where you are comfortable, a scoped account where you are not.
  • For each source feeding that database: who the admin is, and a read account.
  • Read access to whatever orchestrates today’s transformations, and to its logs.
  • The change history — repositories, tickets, deployment logs. This is how we reconstruct intent without asking anyone.
  • A repository owned by Uinsure that we can work in, and handles for our engineers.
  • A shared Teams or Slack channel, so none of this runs by email.
  • A way to pass credentials securely: a shared vault, or guest access to whichever tool you use. Never by mail.
  • A mailbox we can send pipeline alerts to.
  • One named person who can unblock access, and a named deputy for when they are out.

Next step. Answer the questions below, tell us the budget you want to set, and we hold the week of 21 September for you.

Strongest when moving now matters more than knowing the endpoint, and you still want a hard ceiling on the first cheque.

The trade: we learn the estate while building on it, so the first few weeks will reshape the plan.

A short discovery, then a real offer A couple of days with Jamie and Jan, €10,000 indicatively, ending in a plan, a roadmap and an offer built on what is actually there.
  • A couple of days of discovery. We walk the existing setup with Jamie and Jan, pull the requirements out in detail, and establish what is really in there rather than what the documentation claims.
  • Indicatively €10,000. Small enough to sign off without a business case, and the number firms up the moment the questions below are answered.
  • What you get out of it. A plan, a roadmap and a real offer, all built on the actual estate. Yours to keep and act on with or without us.

Roadmap

  • Beforehand, the access list. We send what we need to be able to see. You tell us what is easy, what is slow, and what is genuinely out of reach — that answer alone changes the plan.
  • Day one, the estate. With Jan: databases, flows, orchestration, what breaks and how often. With Jamie: what the business consumes, and what it must never lose.
  • Day two, the target and the gap. Where Uinsure 2.0 is heading, what has to be true by February, and what is honestly missing today — dictionary, business definitions, semantic layer, change governance.
  • Within a week, the deliverable. A written plan, a roadmap to the February date, and an offer against it. Yours whether or not you carry on with us.

What we would need from you for the two days

Deliberately light. The point of this option is to spend your people’s time once, not repeatedly.

  • Jamie and Jan for the two days, or the parts of them that matter. Not full days, but reachable.
  • Read access to the reporting database and to whatever orchestrates it, arranged before we arrive.
  • Whatever documentation exists, however partial or out of date.
  • Half an hour each with two or three people outside the data team who consume the numbers and would notice if they were wrong.

Next step. Give us two dates and we will send the access list the same day. The plan and the offer follow within a week of the second day.

Strongest when you want to know what you are buying before committing the budget, and when €10,000 is an easier signature than €50,000.

The trade: a couple of days before anyone builds anything.

What we need from you

The questions you asked us to send

These are the questions that let us price it, and they apply whichever option you pick. The shorter lists inside each option above are a different thing: what we would need to start, once you have chosen. Answer what is quick here; where an answer needs digging, say so and we will work around it rather than wait. Nobody should be spending hours and hours on this.

What has to keep working The single biggest driver of cost and risk. We can rebuild anything; we need to know what must not break while we do.
  • Which reports, extracts and scheduled processes must keep running from day one, and who consumes each of them?
  • Which of those are business-critical rather than reporting: the point-of-sale to policy-administration flow, the finance feeds, the renewals run?
  • When one of them is late or wrong today, what happens, and to whom?
  • Are any of them tied to a regulatory deadline or a partner commitment?
The estate as it stands Enough shape to size the work. Rough answers are fine; we would rather have an estimate today than a precise figure in October.
  • Which databases, servers and integration platforms are in scope, and roughly how large are they?
  • What orchestrates the transformations today, and how much of it sits in version control?
  • Is there any documentation, lineage or data dictionary at all, however partial or out of date?
  • How many distinct source systems feed the reporting database?
  • How large is the Power BI estate, and who owns the reports inside it?
Access, without touching your engineers The premise of the whole engagement. If these answers are thin, that changes the plan rather than the price.
  • What read access can you give us to the databases, the code, the orchestration and the logs, and how quickly can it be arranged?
  • Can we have the change history too: repositories, tickets, deployment logs? Reconstructing intent from those is how we avoid asking anyone.
  • Can we work on a copy in an environment of our own, or would we be reading in place?
  • Who answers business-definition questions, and how much of their time can we have? Hours across a week, not days.
  • Is there anyone outside the data team who has previously documented or challenged these numbers?
Where this is going Uinsure 2.0 and this work have to end up in the same place. Cheaper to agree that now than to reconcile it later.
  • How does Uinsure 2.0 relate to this: is the new design the target we build onto, a parallel track, or something you also want a second opinion on?
  • Is the target platform open, or effectively already decided?
  • Is Lightdash a decision or still a candidate?
  • Where does the boundary sit: do we stop at a clean, documented semantic layer, or do we also rebuild the business-critical jobs behind it?
  • How does the in-house policy-administration migration sequence against this work?
Clock, constraints and commercials February is the fixed point. The rest we can design around once we know it.
  • What specifically has to be true about data engineering by the time the advisory process starts?
  • Which security, data-protection or contractual rules apply to a third party holding a copy of your data?
  • Which entity in the group would contract with us, and who signs?
  • Is there a budget envelope we should be designing against?
  • What may the existing team be told about this work, and when?

Tell us which shape fits, and we will put numbers on it.

Book the follow-up call