From equipment
to infrastructure.

A product may arrive with impressive capability and still leave the hardest questions unanswered. Is it right for the person and setting? Who assesses and prepares the environment? How is access financed? Who installs, trains and responds when performance changes? Where do incidents, maintenance, return and replacement decisions live?

Those questions are not secondary administration around the technology. Together they form the commercial and operational system that determines whether the asset can become dependable infrastructure.

Care technology has two lives. The first is the visible product: sensing, alerting, supporting, lifting, moving or assisting. The second is the service around it: selection, contracting, installation, monitoring, maintenance, return and replacement. The first creates capability. The second makes it dependable.

The equipment arrives once. The service model has to arrive every day.

This guide is about that second life. It is written for households and care providers that need technology without pretending purchase is the end of the decision, and for manufacturers and partners that need a clearer route into responsible care use.

The hidden work begins with the operating requirement. A machine cannot be selected responsibly from a category label alone. "We need a robot" is not yet a brief. The decision must name the accepted outcome, the task, the site, operating hours, common variation, human roles, data boundaries, support window and consequence of interruption.

Once an asset is selected, the number of interfaces grows. The manufacturer may supply hardware and specialist support. A finance provider may carry part of the capital structure. The customer prepares the site and operating process. Internal technology teams handle access, connectivity and data. Operations decides what happens when the asset is unavailable. Procurement and legal translate expectations into agreements. Insurance and risk teams examine consequences. Somebody must preserve the shared record.

Each party can complete its own task while the deployment still fails between them. A route is available but the access rule is not. A fault is known but nobody owns the customer update. A maintenance window exists but operations cannot release the asset. A software change is installed but acceptance evidence is not refreshed. These are interface failures, not necessarily machine failures.

Questions that begin after the product demonstration

• Which operating condition would make this asset the wrong choice?
• Who owns site preparation, commissioning and acceptance?
• Which costs sit outside the asset or lease price?
• Who responds during the operator's actual working hours?
• What fallback keeps the operation running during downtime?
• Where are incidents, maintenance and material changes recorded?
• Who decides when to upgrade, redeploy, replace or exit?

The purpose of an infrastructure model is to make this work visible, named and repeatable. It does not remove specialist suppliers. It gives their responsibilities one coherent operating frame.

The value is in the continuity between these stages. Asset selection shapes the finance structure. Finance assumptions depend on operating hours, service life and replacement. Deployment establishes the records and responsibilities management will need later. Lifecycle evidence should influence the next asset decision.

Just Hail Mary is building this commercial and service layer around care technology. The aim is one accountable model from first qualification through return or replacement, while preserving the specialist role of manufacturers, assessors, finance providers and support partners.

A useful selection brief describes the outcome before the asset. It identifies what the operation will accept, where the task happens, when it must happen, which variations are ordinary and what consequence follows from delay or interruption.

Care technology assets are not interchangeable. A sensor, bed, hoist or mobile platform can differ in fit, runtime, charging, sensing, maintainability, support coverage, data behaviour, environmental limits and integration boundary. Those differences only become meaningful against a named care need and setting.

A selection brief should name

• Outcome: the completed work the operation can accept and use.
• Task and site: space, surfaces, objects, traffic, people, access and environmental variation.
• Operating window: hours, demand pattern, charging opportunity and support requirement.
• Human roles: preparation, supervision, recovery, maintenance and right to stop.
• Technical dependencies: power, connectivity, integration, data and cybersecurity boundaries.
• Lifecycle: service, spares, changes, upgrades, replacement, return and exit.

Vendor-agnostic does not mean universal compatibility or a promise that a suitable asset exists. It means the operating need remains the authority. The purpose is to compare available asset families and suppliers against the same bounded requirement, record the gaps honestly and reject a deployment where the fit is not credible.

Start with the work the organisation must accept, then choose the machine that can enter that work.

Purchase, lease and managed-service structures distribute capital, technology, support and residual-value risk differently. Ownership can make sense where the asset, utilisation, service life and internal operating capability are well understood. Leasing infrastructure can align cost with a defined term. A managed service can make deployment and lifecycle responsibilities more visible. None is automatically correct.

The finance decision should use the same operating assumptions as the deployment decision. A business case built from theoretical capacity will not survive if the site, support window, supervision burden or downtime pattern produces far fewer accepted outcomes.

Make the whole numerator visible

• Asset purchase, lease or service charge.
• Integration and site preparation.
• Connectivity, software and data services.
• Support, maintenance and spares.
• Supervision, recovery and operational administration.
• Downtime, contingency and fallback.
• Insurance where applicable.
• Upgrade, replacement, return and exit.

The strongest commercial structure does not hide uncertainty. It names the assumptions with the greatest power to break the case: utilisation, accepted-task rate, support response, service life, residual value, demand stability or dependence on specialist intervention.

Just Hail Mary does not use this framework to promise savings. It uses it to create a more honest comparison between ways of accessing and supporting care technology.

The manufacturer supplies the machine. A finance provider structures access. The customer prepares the site. Internal technology teams manage systems and connectivity. Operations supplies people and fallback. Support handles faults. Each participant can fulfil a narrow obligation while the end-to-end service remains unowned.

Deployment should therefore produce more than an installed asset. It should establish a shared operating boundary with a named outcome, conditions, responsibilities, acceptance method, evidence access and escalation path.

The deployment record should establish

• The accepted outcome and deployment envelope.
• Site, power, connectivity, access and integration dependencies.
• Commissioning tests and operational acceptance.
• Who may start, stop, reset, escalate and approve change.
• Support windows, response paths, spares and fallback.
• Incident, maintenance and performance evidence access.
• Software and hardware change control.
• Upgrade, replacement, redeployment and exit conditions.

Contracts may remain separate. Operational accountability cannot disappear between them.

Go-live is the beginning of the operating record. The organisation now needs to understand where the asset is, which contract and site it belongs to, its service state, maintenance history, incidents, changes, support obligations and replacement path.

Uptime remains important, but it is not the whole lifecycle. A machine may technically run while producing less accepted work, requiring more recovery, depending on unavailable expertise or approaching a support boundary. A contract may continue while the operation, demand or asset fit has changed. Management must connect the physical, commercial and operational record.

Lifecycle decisions need evidence

• Maintain: performance and support remain credible inside the current requirement.
• Change: a site, process, hardware or software change needs new acceptance and ownership.
• Upgrade: a newer component or service can improve the operating case without losing continuity.
• Redeploy: the asset may fit another task or site better than the current one.
• Replace: supportability, performance, economics or risk no longer justify the current asset.
• Exit: the organisation needs a controlled return, data, contractual and operational close.

A mature service does not treat replacement as failure. Replaceability is a feature of infrastructure. The machine should be able to change without losing the customer, contract, deployment, maintenance and evidence history around the service.

Headline capacity can be a poor denominator. Available hours are not the same as productive hours. Productive motion is not the same as completed work. Completed work is not useful if it misses the required quality, timing, safety or evidence threshold.

A stronger comparison uses accepted useful outcomes inside the real operating window. The numerator includes the whole lifecycle described in this guide. The denominator includes the demand and operating conditions the organisation can genuinely support.

A shared finance and operations worksheet

• What does the existing process cost under the same demand, quality and risk assumptions?
• Which outcomes must be completed, and what makes one acceptable?
• How many operating hours are genuinely available after charging, maintenance and site constraints?
• What supervision, recovery and fallback work remains human?
• Which support response is required by the consequence of interruption?
• How do upgrade, replacement and exit affect the term?
• Which single assumption has the greatest power to invalidate the case?

This method does not guarantee a positive case. That is the point. It makes a weak case easier to stop and a strong case easier to explain.

A first asset can survive on expert attention, informal communication and the memory of the people who assembled the service. A multi-site portfolio cannot. Scale requires common records, installation patterns, acceptance, support ownership, maintenance, evidence and replacement decisions across equipment and care settings.

The scaling question is not simply how many units can be financed. It is which decisions, diagnostics and recovery actions still depend on the original sales, engineering or site team. Any dependency that cannot travel with the service will become a constraint as the fleet grows.

The practical next step is a bounded care requirement: define the person, outcome, setting, likely duration, product category, finance question, support need and lifecycle owner. That is enough to begin a serious conversation without pretending the final product is already known.

As evidence grows, public claims can grow with it. Until then, the proof boundary protects operators, partners and the credibility of the category.

Read the canonical Just Hail Mary proof boundary.