Umzi Labs is a London software company. We take a product question that nobody has answered yet, put working code against it under real conditions, and hand back the measurement: what held, what broke, and what that means for the build.
Illustrative photograph. It is not our premises and not a record of work delivered.
A team that starts building on an unexamined assumption does not find out it was wrong at the point of writing the code. It finds out months later, in production, with a codebase shaped around the mistake. The expensive part is never the first version. It is the direction the first version locks in.
We spend the first part of an engagement making the question falsifiable, and the second part putting real code in front of it. Sometimes the answer is that the idea does not work in the form proposed. That result is delivered plainly, and it is worth what it costs.
Described as capabilities the company is set up to deliver, not as a portfolio. Nothing below has a client attached to it, because the company has not traded yet.
You have an idea that depends on something being possible: a latency budget, a model that has to be accurate enough, an integration into a system with no usable documentation. We build the smallest thing that would fail if the assumption were false, run it against realistic inputs, and write up what the numbers actually were.
A running prototype that real users can hold, built to answer a specific question about behaviour rather than to look finished. We are explicit about what the prototype is not: it is not hardened, not scaled, and not intended to survive into production without a rewrite of the parts that were faked.
Where a question has already been answered and the decision is to build, we do the build: application development, data model, the deployment path, tests, and the operational instrumentation that tells you whether it is working after we have gone. Delivered as source you own, in your accounts, with a written handover.
An inherited system that nobody currently on the team wrote. We read it, map what it actually does against what it is believed to do, and produce a written assessment: the parts that are sound, the parts that are load bearing and fragile, and an ordered list of what to address first with an honest estimate of effort.
Plate 02 Illustrative photograph. Umzi Labs has no published work to show, so this site shows none.
Four stages. Each one ends in something written that you keep, and each one is a point at which you can stop without owing us the next stage.
A conversation and then a written statement of the question, in a form where a specific result would count as an answer. If we cannot get the question into that shape, we say so and there is no charge.
A fixed price and a fixed calendar window for the investigation, with the deliverable named. You approve it before any work starts. We do not open ended bill research.
Code written against the question, run under conditions close enough to real to be worth trusting. You get access to the repository throughout, not a reveal at the end.
A written document: what was built, what was measured, what the measurement supports and what it does not, and a recommendation. Including, where it applies, a recommendation not to proceed.
Umzi Labs was incorporated on 1 March 2026. A company that new has nothing to point at, and a website is an easy place to imply otherwise. So, plainly:
Everything on this site that is a matter of public record can be checked against the Companies House register. Everything else is a description of how we intend to work.
Exactly as filed. If any of it does not match the register, the register is right and this page is wrong, and we would like to be told.
The registered office is a registered office address. It is not a location that receives visitors, and post sent there is forwarded rather than opened on arrival. For anything time sensitive, email is the faster route.
There is no contact form on this site. A form that posts nowhere is worse than no form, and we would rather you had the address.
Useful things to include: the question you want answered, what happens if the answer is no, and roughly when you need to know. You do not need a specification. A paragraph is enough to tell us whether we are the right people.
If we are not, we will say so in the reply rather than book a call to say so later.