Frame it, de-risk it,
then build it.
Programmes rarely fail because a team could not build the thing. They fail because the wrong thing was specified, an assumption in the middle of the architecture was never tested, or the evidence strategy arrived too late to influence anything.
On this page
The process
Five stages, and
a decision at each one.
Every stage ends with something you can act on and a genuine option to stop. A process that only ever recommends continuing is a sales funnel, not a method.
Frame
We establish what problem is actually being solved, for whom, and what would have to be true for it to be worth solving. Most of this stage is spent removing ambiguity from the brief, including the parts everyone assumed were already agreed.
- Framed problem statement
- Stakeholder and user map
- Assumption and risk register
- Go / no-go recommendation
Explore
Field research and technical feasibility run in parallel, deliberately. The research tells us what the product has to do; the feasibility work tells us which parts of that are hard. Both are needed before anyone can commit to an architecture honestly.
- Research findings and use environment
- Feasibility results on the risky subsystems
- Concept directions
- Regulatory pathway options
Define
The point where the programme becomes real: system architecture, interface definitions, requirements written so they can be verified, and a risk file that reflects the design rather than describing a generic device.
- System architecture and interfaces
- Verifiable requirements set
- Risk management file (ISO 14971)
- Costed development plan
Design & build
Hardware and software advance together in short cycles, with real users seen throughout rather than at the end. Design controls run continuously, so the design history file is a by-product of working rather than a project of its own.
- Working prototypes at each cycle
- Formative usability studies
- Design history file, maintained live
- Design freeze with rationale
Validate & transfer
Verification and validation against the requirements written in stage three, summative human factors, and transfer to whoever will manufacture and run it. We stay through the first builds, because that is when the interesting failures appear.
- V&V protocols and reports
- Summative usability validation
- Manufacturing transfer package
- Post-market surveillance plan
The durations above are typical rather than sequential. On most programmes stage two on one subsystem runs alongside stage four on another. What does not change is the rule that nothing enters build before its riskiest assumption has been tested.
Engagement models
Five ways to
work with us.
Most relationships start small. A first engagement is usually a few weeks and exists to tell you something you did not already know, sometimes including that you do not need us.
Discovery sprint
A focused look at a problem you have not been able to settle internally. Ends with a framed problem, an assumption register and a recommendation you can take to a board.
Best when the brief is still moving.
Feasibility study
One hard technical question, answered properly. Can the model hit that accuracy on your data? Will that mechanism hit cycle time? Does that endpoint survive validation? Written up either way.
Best before committing a development budget.
Full programme
End-to-end delivery from framing through transfer to manufacturing, with a multidisciplinary team and milestone-based commercial terms tied to real decision points.
Best when you need a product, not a phase.
Embedded team
A Sirotics squad working inside your organisation, on your tooling and your backlog, alongside your engineers. Designed so capability transfers to your team rather than pooling in ours.
Best when you are scaling a team you already have.
Advisory & fractional leadership
Senior technical and regulatory judgement on call (architecture reviews, pathway decisions, vendor selection, due diligence) without adding a permanent executive hire.
Best when the decisions are big and infrequent.
Technical due diligence
An independent read on someone else's technology for investors and acquirers: what is real, what is scaffolding, what the remaining engineering and regulatory work actually costs.
Best ahead of a funding or acquisition decision.
Principles
How we
actually behave.
These are the commitments that tend to matter once a programme is underway and the initial enthusiasm has worn off.
Test the thing most likely to kill it, first
Programmes accumulate risk in the order work is convenient, not in the order risk matters. We deliberately invert that, even when it makes early progress look slower.
Say the uncomfortable thing early
If the pathway is wrong, the timeline is not real, or the feature everyone loves is the one that will fail validation, you will hear it from us while it is still cheap to act on.
Build so you can take it over
Documented, conventional, and using tools your team can hire for. We would rather lose the maintenance revenue than leave you dependent on us for something you should own.
Evidence is a design input
Claims, endpoints and the studies that support them shape the architecture. Left until the end, they usually require the architecture to change.
Senior people do the work
The people in your kickoff are the people on your programme. We would rather decline work than staff it with a team we assembled to fill a gap.
One team, one backlog
Your engineers and ours work in the same repositories, the same standups and the same tracker. Parallel vendor teams produce integration problems disguised as schedule problems.
Questions
Things people ask
before signing anything.
You do. All foreground IP created on your programme (designs, source, documentation, test data) is assigned to you. We retain only our pre-existing background tooling and internal libraries, and we will list those up front so there are no surprises at the end.
Yes, and it is usually the better option. We work inside your QMS where you have one, and under our own ISO 13485-aligned procedures where you do not, with the output structured so it can be brought into your system later without being rewritten.
Short engagements (discovery sprints, feasibility studies, due diligence) are fixed price. Longer programmes are milestone-based, with each milestone tied to a decision point rather than a calendar date. Embedded teams and advisory work are monthly.
We do not bill for the scoping conversation, and we will tell you when a smaller engagement would answer your question.
You get a written explanation of why, what was ruled out, and what would have to change for it to become viable. A study that says no is doing its job: it has just saved you a development budget. We have no incentive structure that rewards us for finding otherwise.
Occasionally, as a partial arrangement, and only where we would have taken the work on normal terms anyway. We will not do it as a way of making an unaffordable programme look affordable. That arrangement tends to end badly for both sides.
We run distributed by design, with on-site presence where the work genuinely requires it: field research, human factors sessions, lab and manufacturing integration, and hardware bring-up. Everything else runs remotely with a fixed weekly rhythm you can plan around.
A discovery sprint can usually begin within two to four weeks of an initial call. Larger programmes depend on which practices they need. We will tell you our real availability rather than agreeing to a date and staffing it later.
Next step
Start with the
riskiest question.
Bring us the part of your roadmap you are least confident about. A first call is 30 minutes and costs nothing.