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.
Four shapes an engagement takes. Each is scoped and priced before it starts, and each ends in something written that you keep.
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. Staged for this page, not a record of an engagement.
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.
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 exactly that: an address for service. Nobody receives visitors there, and post is forwarded on rather than opened where it lands. For anything time sensitive, email is the faster route.
Everything starts as an email. What is useful to put in it is set out below.
Useful things to include: the question you want answered, what happens if the answer is no, and roughly when you need to know. No specification is needed at this stage. A paragraph is enough for us to judge whether we are the right people.
Where this is not work for us, the reply will tell you so, rather than a call being booked to tell you later.