Platform and workflow discovery for medical technology.
In two to four weeks, we define priorities, architecture and a costed implementation roadmap.
Anyone can build the screens. The work that decides whether a platform survives is agreeing what is true — once, in writing, before the build.
Early clarity creates lasting value
We clarify ownership, data flows and priorities before they become code. That gives the business, design and engineering one dependable basis for decisions.
The same clarity makes automation and AI useful: approved information, explicit rules and human checkpoints turn technology into a reliable part of daily work.
Four phases, clearly connected.
Each phase ends with a clear decision and a tangible result — from the system map to working software and handover.
We map what you already run, honestly.
Interviews with the people who actually maintain things — not only the project sponsor. Product management, sales, IT, the editor who knows why that one field is filled in by hand every Thursday.
“Which system owns which field today, and where do people work around it?”
A system map and a written list of the manual steps holding it together
We settle the data contract before the design.
One definition per field: where it lives, where it flows, how often, and what happens on conflict. Signed off by IT and by the business, because those two rarely have the same answer at the start.
“When two systems disagree, which one wins — and who decided that?”
A data contract, a content model, and an integration architecture
We build in the open, in thin slices.
One narrow path end to end first — a single product, from the source system all the way to a page a customer can see. It surfaces the integration problems while they are still cheap, and it gives everyone something real to argue about.
“Can a real record travel the whole path, today, without anyone helping it?”
Working software from the first weeks, and a release you can test against
We build it so you can run it without us.
Documentation written for the person who inherits this in two years, not for the person who built it. A content model your editors can explain to a new colleague. No cleverness that only its author can maintain.
“If we disappeared tomorrow, could your team ship the next change?”
Documentation, a trained team, and a codebase without private jokes
Point at any field. Who owns it?
This is a normal product page. Each field is filled from somewhere. Pick a system to see what it is responsible for — then look at what two systems both claim.
Two fields here have two owners. Nobody decided which one wins. That is what a launch delay looks like six months early.
Six questions. How many can you answer today?
None of them are technical. All of them change the estimate. Answer honestly — the result is the same advice we would give you on a call.
- 01
Who is allowed to say no?
A project with four stakeholders and no decider does not stall on engineering. It stalls on a question nobody is empowered to close.
- 02
What happens today when a product is renamed?
The answer is usually a list of six places and one person who remembers all of them. That list is your integration scope.
- 03
Which of your systems is allowed to be wrong?
Somewhere in every stack there is a source everyone quietly distrusts. Naming it early is cheaper than discovering it in acceptance testing.
- 04
What did the last agency get wrong?
Not to score points. The failure mode is usually structural and still present — and if we do not name it, we will walk straight into it.
- 05
Who edits this on a Tuesday afternoon?
Systems are designed for launch day and lived in for years. The daily editor’s workflow tells you more about the right content model than any requirement document.
- 06
What are you planning that you haven’t told us about?
The second market, the acquisition, the product line in development. These decide the architecture far more than anything in the current brief.
The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency.Bill Gates
From uncertainty to a solution your team can run.
Most manufacturer engagements start with Discovery, because it resolves the scope before technology and budget are committed.
MedTech Platform & Workflow Discovery
- System and information map, including manual handoffs
- Prioritized use cases, dependencies and delivery risks
- Architecture direction, integrations and approval points
- Implementation milestones and a costed roadmap
Platform build
- A senior team, not a team led by one senior
- Working software from the first weeks
- Integration work treated as the main event, not a phase at the end
- Documentation and handover built in, not bolted on
Ongoing partnership
- The same people who built it
- Next markets, next product lines, next integrations
- Architecture review before each significant addition
- Your team increasingly doing it without us
Things we won’t do, and why.
Being clear about this early saves everyone a procurement cycle. None of it is principle for its own sake — each one is a failure we have watched happen.
Fixed price on an undefined scope
It looks like you transferring risk to us. It is actually both of us agreeing to argue about change requests for a year. Discovery first, then a price that means something.
Building on a content model we think is wrong
We will say so once, clearly, with what we would do instead. If you still want it, that is a legitimate decision — but we would rather lose the work than build the rebuild.
A design phase that finishes before the data is understood
Screens designed against imagined data get redrawn against real data. It is the most common and most expensive sequencing mistake in this kind of project.
Being the only ones who understand it
Lock-in is good business and bad engineering. If your team cannot maintain what we built, we have sold you a liability with a nice interface.
How this works in practice.
Do we have to start with discovery?
No, but we will ask the discovery questions either way. If you already have a system map and an agreed content model, we will read them and start building. If the answers are “it depends who you ask”, discovery is the cheaper path — it usually pays for itself in scope that never gets built.
How do you work with our internal IT?
As colleagues who will be here after us. They hold the ERP knowledge and the security requirements, and they inherit the integrations. We would rather spend an extra week getting their sign-off on the data contract than discover their constraints during go-live.
Can you work alongside our existing agency?
Often, yes — we do it regularly. The usual split is that they keep brand, strategy and the client relationship, and we take the platform and integration work. It works when the boundary is written down early.
What does the first two weeks actually look like?
Interviews with six to ten people across the business, a read of whatever documentation exists, access to the systems in read-only where possible, and a first draft of the system map by the end of week two — deliberately early, so people can tell us where it is wrong.
Start with the landscape, not a solution pitch.
In a focused first conversation, we identify the product-information or workflow problem worth mapping first.
Find the right AI starting point.
Align the business case, governance and first implementation—without starting a large programme.