VissionLink Lab
VissionLink Lab is the research and development programme run jointly by Kreativloops and BMR. It builds the AI we use in-house before we sell it, designs and prints the hardware we put our name on, and maintains the one flow we use to take an idea all the way to a deployed product.
The Lab exists because neither side could do this alone. One builds the systems, the other runs a business that has to live with them.
Brings the software and AI practice: models, agents, retrieval over company data, the platforms they run on, and the evaluation work that decides whether something is fit to ship. Kreativloops builds and operates every system VissionLink puts in front of a customer.
Brings the operating floor: a live rental business with real fleet, real customers and real deadlines. Every prototype the Lab builds gets tested against a working day here first, which is the difference between a demo and something a company can run on.
VissionLink Lab is a joint research programme of two independent companies. It is a way of working together, not a separate legal entity, and we would rather say that plainly than let a name imply otherwise.
Three tracks, chosen because each one removes a dependency we would otherwise be renting from someone else.
01
Assistants, agents and automation built in-house, run on our own operations first, then offered to clients once they have survived contact with a real business.
02
Proprietary products designed, printed and assembled by us, so a change takes an afternoon instead of a supplier quotation and a six week wait.
03
The method itself is a deliverable. One flow covers software and hardware, so a team does not have to invent a way of working every time the work changes shape.
Most teams have a process for code and no process for anything physical, so hardware work turns into guesswork. These five stages run the same either way, with a different artefact at each gate.
Frame the problem and the constraint that actually binds it, then agree the smallest thing worth testing. Nothing gets designed until we can say what it would take for this to be a bad idea.
The job the user is hiring the system for, and the data it would need to do it.
Where the unit lives, what it must survive, and what it costs to make one.
Decide it before building it. The expensive mistakes are structural, and structure is cheap to change while it is still a drawing.
Data model, interfaces between systems, and the screens the work actually happens on.
CAD, tolerances, print orientation and a bill of materials that can be sourced twice.
The cheapest honest version, in someone's hands, fast. A prototype that flatters the idea has failed at its only job.
A working slice running on real data, not a clickable picture of one.
A printed part on the bench in the same week, revised as many times as it takes.
Turn the thing that worked once into a thing that works every time. This is where the tests, the tolerances and the boring rigour go in.
Hardened, instrumented, access controlled, and covered by tests that would catch a regression.
Repeatable print and assembly steps, firmware, and a check that says a unit passed.
Shipping is the start of the obligation, not the end of it. We stay on the system after it goes live, which is also how the next round of the Lab gets its evidence.
Live, monitored, and maintained by the people who built it.
Units in the field reporting to the same platform, updatable without a site visit.
The stages are fixed. The depth is not. A two week internal tool and a device that has to run unattended for a year get the same order of operations and very different amounts of stage four.
An R&D page is the easiest place on a website to overclaim. Here is the honest state of each track, using the same three labels we use internally.
Answering enquiries on a live platform, against a real catalog and real pricing.
In productionQuotation, contract and invoice steps that used to be manual, running on live orders.
In productionEnclosures, mounts and jigs designed and printed in-house to support our own builds.
In developmentService and assistant units: expressive interface, on-device behaviour, updatable brain.
In developmentControllers and sensors reporting into the platform an operation already runs on.
In developmentModels running on the unit itself, so it keeps working when the connection does not.
ResearchIn production means it is running for real users today. In development means it is being built and is not a product yet. Research means we are still finding out whether it should be. If hardware is part of what you need, talk to us early and we will tell you plainly where we are.
The Lab takes on work that does not have an off-the-shelf answer. If a product already exists for what you need, we will tell you to buy it.
An assistant, agent or automation designed around your data and your rules, with the evaluation written first so you can see what it does before it faces a customer.
From sketch to a printed, wired, working unit you can hold, then the path to making the same one repeatedly.
We run your team through the same five stages on one of your own projects, and leave the method behind in writing.
A short, scoped answer to whether something is worth building at all, ending in a recommendation you can act on either way.
Longer engagements where the Lab and your engineers build together, with ownership of the output agreed in writing at the start.
A review of a system or a device someone else built, focused on what will break and what it will cost to keep.
Tell us what you are trying to make. We will tell you what stage it is really at and what the next one costs.
Talk to the Lab