We make sure the software we build solves the right problem.
Inlab builds AI products and business systems, our own and other people’s.
We’d rather show you than tell you. A look at how we build our own tools, and the client work we can talk about publicly so far.
A 25-year-old system, rebuilt for Onecom.
We came up with the printed catalogue, in the browser, linked both ways to InDesign.
Live, and used by Pepkor, Furnmart and Homecorp. →
201 franchises and 876 suppliers on the system.
A promotions and inventory system for Mica’s head office, suppliers and franchises. Rebuilt because the old one wasn’t serving them. →
We don’t treat the brief as the answer. Business, product, systems and engineering perspectives stay involved as the software takes shape.
Building teaches you things. A prototype exposes a bad assumption. A technical constraint changes the product. Something that looked essential at the start turns out not to matter at all.
The build gets better because the thinking doesn’t stop when the building starts.
How we work →More routes investigated.
More assumptions tested.
More prototypes built.
More iterations possible.
We use AI throughout the work, from research and reasoning to design, code and testing. Not because using AI is the point. Because it lets a small, experienced team go further within the same practical constraints.
Most software goes wrong in the gap between the people who understand the business and the people who build it. We close that gap by keeping both in the same few heads: senior experience across business, product, systems, engineering, retail, marketing, brand and M&A, concentrated into a handful of people rather than spread across a large team. The people who understand your problem are in the room when it’s built.
Bring us a specification, a problem or an opportunity. We’ll work out what it needs and take it through to working technology.
If you know exactly what needs building, we’ll build it. If you don’t, we’ll work out what should be built with you.
Where are you starting from?
Defined
“We know what it needs to do. We need it built properly.”
What we do
We read the specification closely and build it. If something in it will cause trouble later, a wrong assumption or a dependency nobody mentioned, we say so while it’s still cheap to fix. We don’t build a bad specification just because it was written down.
What you end up with
Working software, delivered quickly, with fewer mistakes in it. The thinking happens quietly, in service of clean execution.
“The systems we run the business on are held together by workarounds. We know they need replacing. We don’t know what they should become.”
What we do
We work out what the new system needs to be by looking at how your business, your customers and your data actually fit together. We prototype as we go, so you’re reacting to something working instead of a document.
What you end up with
A clear picture of what’s worth building, and a start on building it, in the same piece of work.
“Something isn’t working and nobody agrees why. Customers drop out. Information arrives late or wrong.”
What we do
We start from the symptom and work backwards, across business, customer, systems and engineering, until we know what the real problem is. Sometimes it isn’t the one you came in with.
What you end up with
A diagnosis you can act on, and a solution built to fit it.
“We think there may be a better way to do this, or a different business in it. We haven’t proved it.”
What we do
We test the idea early with real prototypes, so you find out whether it holds before you commit to a full build.
What you end up with
A decision made on evidence. Sometimes that decision is to build. Sometimes it’s to stop, and it’s worth knowing early.
Undefined
The capability is the same at every point on the line. What changes is how much of it your problem needs.
A finished brief, a half-formed problem, or a hunch you haven’t tested yet. Start wherever you actually are.