About
Twenty years before the first line of Gecko
Gecko was not written by people learning what a warehouse is. It comes out of more than twenty years of building, repairing and running data platforms for companies whose operations depend on them — the kind of work where the estate already exists, somebody else designed it, and it has to keep producing numbers while you fix it.
That is a particular education. You do not get to choose the stack, the history or the deadline. You inherit a warehouse with eleven years of decisions in it, a transformation layer that half documents itself, and a reporting layer that several people depend on without knowing why. Then you make it correct, and you make it cheaper, and you leave it in a state the team can run without you.
Gecko is that job, written down and made to run continuously instead of in engagements.
Where the experience comes from
The industries
Different businesses, the same estate problems underneath. What changes is which of them is expensive.
Banking and financial services
Regulated reporting that has to reconcile to the cent, on an estate assembled over decades. The hard part is rarely the model — it is proving the number is the same number it was yesterday, and being able to show why when it is not.
Insurance and mortgage
Long-lived policies and loans mean history matters more than throughput: a table that was correct when it was written has to stay correct through a dozen schema changes and three source systems.
Retail and consumer goods
Daily decisions on data that arrives late, incomplete and from more places every quarter. Freshness and spend pull in opposite directions, and the warehouse bill is usually the first thing anybody notices.
Manufacturing and distribution
Operational data that was never designed to be analysed — ERP tables, plant systems, spreadsheets that became systems of record. Most of the work is lineage: knowing what feeds what before changing anything.
Real estate and construction
Portfolios that grow by acquisition, so the estate grows by acquisition too. Three ways of naming the same property, and a reporting layer that has to pretend there is one.
What it taught
Four things that held everywhere
These are the reasons the product is shaped the way it is, rather than a list of beliefs arrived at afterwards.
The failures repeat
Across every industry above, the same handful of problems: a model nobody reads that still runs nightly, a test that was loosened to make a release, a column that changed shape upstream, a warehouse spending money on a dashboard three people opened last year. The names change and the shape does not.
The backlog is not the hard part
Every team knows roughly what is wrong with their estate. What they do not have is the week it takes to prove it, fix it and be confident the fix did not break the thing downstream. The work is not identifying it — it is finishing it.
Trust is the scarce resource
A finding that turns out to be wrong costs more confidence than ten correct ones earn. That is the single belief this product is designed around: it would rather say it cannot tell than guess, and it proves a change before proposing it.
Small teams get the same problems as large ones
An estate of four thousand objects run by two people has the same failure modes as one of four hundred thousand run by forty. What it does not have is anybody whose job is to go looking.
The team
Architects and engineers, not a research group
The people building Gecko are data architects, engineers and analysts who have spent their careers inside other organisations’ estates — designing warehouses, migrating them, instrumenting them and being on the phone when a figure looked wrong on a Monday morning. Several hold current certifications on the platforms the product connects to, which matters less than the fact that they have had to make those platforms behave under a deadline.
It is a small team on purpose. Whoever builds something owns what it does in production and talks to the people using it, so a finding that is wrong is somebody’s problem by name rather than a ticket in a queue.
There is also an AI practice behind it. That is the newer half of the experience and it is the half we are most careful about: a model is useful here precisely to the extent that its output can be proved, which is why nothing Gecko proposes arrives without the evidence it was derived from.
Why a product
Consulting does not reach the teams that need this most
The teams with the worst version of these problems are the ones that cannot buy a quarter of somebody’s time to fix them. Two or three people running an estate built for a company twice their size, with no slack to go looking for a dead table or a query that costs four hundred dollars a month to answer nobody’s question.
What those teams needed was not advice. It was the repeatable part of the work, running on its own, handing back something a person can read in five minutes and approve or reject. That is the whole product: it learns the estate, finds what is broken, wasteful or dead, writes the change, proves it, and waits for a human to merge it. It never merges anything itself.
See it against your own estate
Connect a warehouse and a repository and Gecko will tell you what it found. It reads metadata and query history — never the rows in your tables.
Get started