RegisteredEngland and Wales, company number 17061582
Incorporated1 March 2026
StatusActive. Building. Not yet trading publicly.
VIVAN LABS LTD builds and repairs the plumbing underneath analytics: ingestion, storage and modelling, data contracts and tests, orchestration, access control and platform cost. The point of the work is not another dashboard. It is that when somebody disputes a figure, you can walk them back through the transformation, the test that guarded it and the source extract that produced it, without guessing.
VIVAN LABS LTD was incorporated on 1 March 2026. It has no filed accounts yet, no published client list, no case studies and no awards, because a company of this age cannot honestly have any of those. Nothing on this website is a claim about work already delivered. What follows describes the discipline we practise, the way we would run a first engagement and the commitments we are willing to put in writing before any money changes hands.
If you are assessing us as a supplier and you need evidence we do not yet have, say so in your first email and we will tell you plainly whether we can produce it. We would rather lose a procurement round than pass a due diligence question we cannot answer.
Most teams do not have a data problem. They have one of these six problems, and it is showing up as a data problem three layers further up. The work is identifying which layer is actually broken before rebuilding anything.
L1
Getting data out of operational systems without hurting them and without silently losing rows. Change data capture where the source supports it, batch extraction where it does not, idempotent loads so a rerun does not double count, and a landing zone that keeps the raw payload exactly as it arrived.
The single most common defect we expect to find here is an extract that quietly truncates when the source changes a column type, and a pipeline that reports success anyway.
L2
Deciding what the warehouse or lakehouse is actually shaped like. Raw, staging and serving separation, partitioning and clustering that match how the tables are read rather than how they are written, surrogate keys, slowly changing dimensions where history genuinely matters, and a naming convention a new analyst can predict.
Modelling is where cost is decided. A badly partitioned fact table is a recurring monthly invoice, not a one off mistake.
L3
A data contract is a written, enforced agreement about the schema, the semantics, the freshness and the nullability of a dataset, owned by the team that produces it. Without one, every downstream break is discovered by whoever is unlucky enough to open the dashboard on a Monday.
We build the tests that enforce the contract: uniqueness and referential checks, accepted value sets, row count and distribution shifts, freshness thresholds, and a failure that blocks the release rather than posting a warning nobody reads.
L4
Scheduling is the easy half. The hard half is dependency ordering, backfills that do not stampede the warehouse, retries with sensible backoff, alerting that distinguishes a transient network failure from a genuine data defect, and column level lineage so an impact assessment takes minutes instead of a week.
We treat a pipeline that cannot be safely rerun from any point in its history as unfinished work.
L5
Role based access at the table, column and row level, so that the finance team and the support team see different things from the same model. Classification of personal and special category data at the point it enters the platform, not retrospectively. Masking and pseudonymisation policies expressed in code rather than in a spreadsheet of promises.
This layer is where UK GDPR obligations become real engineering: retention that actually deletes, deletion that actually propagates, and an audit trail that survives an ICO question.
L6
Warehouse spend attributed to the team, model and query that caused it. Slow query identification, materialisation decisions made on measured cost rather than habit, and warehouse or cluster sizing that reflects the actual concurrency profile.
Platform metrics treated the same way as application metrics: freshness, job duration, failure rate and cost per model, all on a dashboard the platform owner sees before the finance director does.
If a dataset has no owner, no schema contract and no freshness threshold, it is not a data product. It is a file that happens to update.
Almost every failure we expect to be called in for traces back to that sentence. Somebody built a table, somebody else started depending on it, and nobody ever wrote down what it promised. Our first job on any platform is usually to find those tables and make the promise explicit.
We do not sell an open ended retainer to a client who has never worked with us. A first engagement is a fixed scope, fixed fee assessment with a written deliverable at the end, priced before it starts. If the assessment says your platform is fine, that is a legitimate outcome and you owe us nothing further.
01 / Inventory
Sources and their extraction method, the models between them, and who or what reads the output. Most organisations discover during this step that two teams maintain the same metric with different definitions, and that at least one scheduled job has been failing quietly for months.
02 / Contract audit
For each dataset that matters: is there an owner, a documented schema, a freshness expectation and a test that fails loudly when the expectation is broken? We produce a list, not a score. A list can be worked through.
03 / Failure modes
We trace what happens when a source system changes a column, when a load runs twice, when a backfill overlaps a scheduled run, and when a job fails at three in the morning. The output is the list of failures that are currently silent, ranked by what they would cost you.
04 / Privacy and access
Classification of personal and special category data across the platform, the access paths to it, and the gap between your published retention policy and what the tables actually still contain. This is written to be usable in a record of processing activities under Article 30 of the UK GDPR.
05 / Cost
Spend attributed to models, jobs and query patterns rather than to one undifferentiated monthly invoice, with the specific changes that would reduce it and an honest estimate of the engineering effort each one takes.
06 / Written plan
Ordered by risk and dependency, with effort estimates and the reasoning behind the order. You own it. If you want your own team to carry it out, or a different supplier, the document is written so they can.
Five rules we hold to. They are constraints on us, not requirements on you, and they are the reason our scoping conversations tend to be longer than average.
Rule 01
We take a read only credential first and keep it for as long as possible. A supplier who asks for write access to a production warehouse in week one has told you something about how they work. Elevated access is requested per task, with a stated reason and a stated expiry.
Rule 02
Models, tests, orchestration definitions, infrastructure code and documentation are committed to a repository you control, under a licence that leaves you free of us. There is no hosted VIVAN LABS component sitting in the middle of your platform that you would have to unpick later.
Rule 03
Development and testing use synthetic fixtures or a masked sample. We take a copy of real personal data only where the task genuinely cannot be done otherwise, under a written processing instruction, and we delete it on completion rather than at some unspecified later date.
Rule 04
Schema changes go out with a migration and a documented rollback. Destructive operations against production data require an explicit written approval from you, recorded against the ticket, and are never bundled inside a larger change.
Rule 05
If an estimate is wrong, if a chosen approach turns out not to work, or if we find something in your platform that is worse than either of us expected, you hear it in the next written update rather than at the end. Silence in a delivery relationship is almost always a supplier managing its own discomfort.
These are default choices, not commitments and not partnerships. If your organisation has already standardised on something different, the honest answer is usually to work inside your existing choice rather than to bill you for a migration you did not ask for.
| Layer | Where we start | Reason for the default |
|---|---|---|
| Warehouse and lakehouse | Whatever your cloud already bills you for, before considering anything new | A second warehouse doubles the governance surface and halves the chance that either one is properly maintained. |
| Transformation | SQL first, version controlled, with tests defined alongside the model | SQL is the one language every analyst, engineer and auditor on the project can read without a translator. |
| Ingestion | Managed connectors for commodity sources, written code only where the source is unusual | Bespoke connectors for standard systems are maintenance debt that outlives the engagement that created them. |
| Orchestration | Declarative dependency graphs, retries and backfills as first class operations | Cron plus hope fails silently. A dependency graph fails loudly and in the right order. |
| Quality | Tests that block a release, not warnings routed to a channel | A quality signal that cannot stop a bad deployment is documentation, not a control. |
| Infrastructure | Declared as code in your repository, with state stored in your cloud account | Click configured infrastructure cannot be reviewed, reverted or handed over. |
| Secrets and credentials | Your secret manager, scoped service accounts, no shared logins | Credentials that cannot be attributed to one identity cannot be revoked with confidence. |
On vendors and certifications. VIVAN LABS LTD holds no vendor partnership, reseller agreement, implementation badge or product certification with any data platform vendor, and we do not resell licences or take referral commission. We hold no ISO 27001 certification, no SOC 2 report and no Cyber Essentials certification. If any of those are a hard procurement requirement for you, we do not currently meet it, and we would rather tell you now than at the end of a questionnaire.
The most useful first email describes the thing that is currently annoying you: a number two teams disagree on, a job that keeps failing, a warehouse bill that has doubled, a subject access request you are not confident you could answer. We reply to every genuine enquiry, normally within two working days.