Shipped by changing less

Medeq is a South African software business serving the medical equipment servicing market. Their customers are hospitals, clinics, and service providers whose technicians log every device they service: ticketing, job cards, checklists, parts, customer sign-off, against an off-the-shelf service management system called iTOP that holds the customer, device, and asset data.

Kevin Joubert, Medeq’s managing director, had been trying to bring this product to market for a long time. Two development partners had taken on the build before us, and neither had delivered a functional platform. Each engagement had been a fixed-price contract; each had ended with money spent and nothing shippable to show for it. A third attempt on the same commercial basis would have meant gambling more cash on the same pattern.

There was a second problem underneath the first, and it is the one that matters. Both attempts had worked by modifying iTOP itself, pushing the new behaviour into the system that was only ever supposed to do the ordinary job. By the time the money ran out, Medeq was pinned to an old version of a product it did not control, and had paid for that twice over: once to build the changes, and again in every upgrade it could no longer take. None of it had reached a customer.

So Medeq took a different route. Instead of a third fixed-price build, the engineering was paid out of the result. The share is 25%, and it is scoped: it applies to field service agent subscriptions, which is the thing the software does, and to nothing else Medeq sells. Medeq’s iTOP training and setup income is Medeq’s. Equity was part of this one as well, which is unusual and not the shape most of these take.

What ReadyRun carries in return is the build, the improvements that keep following it, and the infrastructure underneath, so Kevin has no technical function to run and no second supplier to manage. The structure meant the next attempt did not deplete the cash Medeq needed for everything else, and it meant a shallow read of the problem was not affordable on either side. How that kind of arrangement is scoped is on the pricing page.

The thing that separates this attempt from the two before it is not a method. It is which software got changed.

Every bought part stayed as it comes. Most are open source, hosted on Medeq’s own infrastructure as a GoFast service rather than rented per seat. Two are paid subscriptions, because getting mail into an inbox and knowing how a product is actually used are specialist jobs with no in-house version worth having.

That is the whole rule: open source where it makes sense, a subscription where one is genuinely better, and something built only for the part that is Medeq’s own.

All of it talks through published APIs, so any single part can be upgraded on its own. If one of those APIs moves, some integration work follows. That is an ordinary maintenance job, and the distance between it and a rebuild is the whole of the difference between this attempt and the last two.

The problem space had already defeated two teams, so the first job was to understand why. Sitting with the technician’s day, the iTOP integration surface, the signing scenario and the calibration rules turned up more interlocking requirements than a scope document could carry. The full workflow was mapped out step by step, as diagrams, and worked through edge case by edge case.

Two things came out of that which were not in the brief. The first was signing. A customer signature as proof of delivery is easy to meet on the surface, but if a Medeq customer ever disputed a signed job, what was there would not have held. The requirement was the discovery; meeting it was then a matter of putting Documenso behind it rather than writing a signing engine.

The second was where the work actually happens. Mobile readiness was not in the requirements, and a technician’s day is moving between sites, working on hospital floors and in patient rooms. A desktop-first app would have fought its user every hour of every day.

Both came from the same thing, and it is the part that is genuinely hard: reading the problem deeply enough that the platform fits the reality rather than the brief.

Seven capabilities, each closing a specific gap in how the business runs.

The second thing that got built sits between the software running on a client’s infrastructure and the question of who is allowed to use it. When somebody signs in to a Medeq Field Service app, they are checked twice: against that client’s own iTOP instance, and against the Hub as a user Medeq has actually provisioned.

Medeq’s clients add and remove their own people. The Hub works out the pro-rata and the cancellation periods that follow, and then does something unusual with the result: it raises the invoice from ReadyRun to Medeq, and the invoices from Medeq to its clients, inside Medeq’s own accounting system. It is wired into two companies’ books at the same time.

It also serves Medeq’s new public site, with Twenty behind it catching enquiries. That site is live at medeq.readyrun.tech and moves to the main domain when it suits Medeq, not when it suits us. Nothing about this has been a switchover; the pieces move into place one at a time, disturbing as little of the working business as possible.

The Hub is where a detail worth naming lives. ReadyRun does not charge Medeq per user. Medeq does charge its own clients per user, because that is how its market works, and the software supports that without a fight. Not charging per person is a position ReadyRun holds about its own pricing, not a rule imposed on the businesses it builds for.

The Hub was designed and built by Daniel Pieterse, end to end.

Software teams normally split a build down the middle: one developer works the screens, another works the rules and the data, and every feature crosses that seam twice. This build did not run that way. With AI in the toolkit at every layer, each engineer carried their piece end to end, from the screen a technician touches down to the rules and the integration underneath it.

The reason that belongs in Medeq’s study is what it meant for the engagement: fewer people on the build, no feature waiting for the other half of itself, and one person answerable for the whole of a thing rather than half of it. Medeq is where the old split got retired, and everything since has been built this way.