Medtech hardware and software case studies

Case narrative

PrairiePatch Health began as a simple idea: help home care nurses track wound healing between visits. The first prototype used a disposable colour calibration sticker, a phone camera workflow, and a clinician dashboard. In the pilot, nurses took standardized wound photos, the app prompted for measurements and patient-reported symptoms, and the dashboard helped a wound-care specialist review changes remotely.

The initial Alberta pilot involved 80 patients across two care teams. It worked well enough to attract interest from additional primary care networks and a rural health innovation program. Maya's team now has a letter of intent for a 1,200-patient expansion. The opportunity is real, but the technical model is fragile. Photos are large, uploads fail in weak connectivity zones, the disposable sticker supply chain is manual, and the dashboard slows down when specialists review many cases at once.

The hardware element also creates scaling pressure. The stickers are inexpensive in small batches, but quality varies between suppliers. A batch with slightly different colour response could affect measurement consistency. The software team wants to automate image quality checks, but the regulatory advisor warns that the more the system influences clinical interpretation, the more disciplined the evidence and change-control story must become.

Dilemma

Maya must decide whether to accept the 1,200-patient expansion immediately or pause to rebuild the hardware supply process, image pipeline, cloud storage model, and support workflow. If she slows down, she risks losing momentum. If she scales too quickly, she may create clinical, privacy, operating cost, and reliability problems that damage trust.

Options

• Accept the expansion now: add cloud capacity, hire temporary support, and manage hardware manually while learning from higher volume.
• Run a constrained scale pilot: expand to 300 patients first, with explicit uptime, upload success, sticker quality, support, and clinical review metrics.
• Rebuild before scaling: qualify suppliers, redesign image compression and offline upload, add monitoring, and document verification before new sites launch.
• Split product claims: keep the near-term product positioned as workflow and documentation support while deferring stronger measurement claims.

Discussion

• What technical metrics should Maya require before moving from 80 to 1,200 patients?
• Where does hardware quality become a software, clinical, or regulatory issue?
• How should the team model image storage, bandwidth, review workload, support tickets, and sticker replacement cost?
• What Alberta privacy and operational assumptions need to be documented before the larger pilot?
• Which claims can PrairiePatch make safely now, and which should wait for stronger evidence?

Case narrative

NorthBridge Neuro built a wearable sleeve that measures upper-limb movement during home rehabilitation exercises. The first version used off-the-shelf inertial sensors, a tablet app, and a clinician portal. Physiotherapists liked the visibility between appointments, and patients liked seeing progress. The company now has a working prototype, a small grant history, and early support from rehabilitation researchers.

A venture fund has offered a seed term sheet. The fund wants NorthBridge to accelerate commercial development, hire a larger engineering team, and pursue U.S. market entry quickly. The investor believes the company should move toward a scalable platform for multiple rehabilitation pathways rather than stay focused on stroke. Jonas is excited, but the plan would force the team to make claims and architecture choices faster than their current evidence supports.

An alternative path is available. NorthBridge could bootstrap longer using paid pilots, non-dilutive funding, research partnerships, and a narrower product. That path would reduce pressure, but it may slow hiring and delay the hardware redesign needed for manufacturability, reliability, and field support. The co-founders disagree. One argues that medtech hardware is too capital-intensive to bootstrap. Another argues that VC growth expectations could push them into premature scale before they understand clinical workflow and reimbursement.

Dilemma

Jonas must decide whether to take venture funding and build aggressively, or keep the company narrower and slower while using Canadian and Alberta ecosystem funding to reduce technical and evidence risk.

Options

• Accept the VC term sheet: hire quickly, professionalize hardware and software, and expand toward broader rehab markets.
• Negotiate milestone-based financing: take less capital now and tie future investment to manufacturability, pilot outcomes, and regulatory strategy.
• Bootstrap with paid pilots: focus on stroke rehabilitation, keep burn low, and use customer learning to define the product before scaling.
• Hybrid funding plan: combine a smaller angel round with Alberta Innovates-style support, Mitacs or university collaborations, and targeted customer revenue.

Discussion

• How does funding strategy change the architecture, hiring plan, evidence plan, and claim boundary?
• What costs are unique to connected hardware compared with software-only startups?
• Which milestones should Jonas prove before broadening beyond stroke rehabilitation?
• What would a fundable but responsible 18-month roadmap look like?
• How should NorthBridge avoid building for investor excitement instead of clinical adoption?

Case narrative

CareLink Triage helps clinics collect structured intake information, route referrals, and surface missing information before a specialist review. Aisha's first product was a standalone web app. It was easy to demo: patients completed intake forms, clinic staff reviewed completeness, and specialists saw a clean summary. The product reduced phone tag in two friendly clinics.

When Aisha began selling to larger organizations, the conversation changed. Prospective buyers liked the workflow but did not want another portal. They asked how CareLink would integrate with existing EMRs, how referrals would move through current queues, who would own interface maintenance, and whether the system could support audit logs, privacy review, role-based access, and data retention requirements. One health-system advisor said bluntly: "The workflow is interesting, but integration is the product."

The engineering team can build API endpoints, but each customer seems to need a different integration path. Some clinics want CSV import and export. Others ask about FHIR resources, HL7 v2 messages, or interface engines. Aisha worries that every sale will become a custom services project. Her sales lead argues that ecosystem integration is the price of admission. Her CTO warns that promising broad EMR integration too early could consume the roadmap and create support obligations the company cannot meet.

Dilemma

Aisha must decide whether to keep selling the standalone workflow, invest heavily in integration capability, or narrow the market to customers whose technical environment the company can support repeatably.

Options

• Stay standalone longer: sell to smaller clinics that can tolerate a separate workflow while the company proves value.
• Build an integration layer: define API contracts, data mapping, error handling, audit logging, and a repeatable implementation playbook.
• Partner with an integration vendor: use interface-engine expertise while CareLink focuses on triage workflow and customer success.
• Narrow the buyer segment: target one ecosystem or clinic profile where integration patterns are similar enough to scale.

Discussion

• When does integration become core product strategy instead of implementation detail?
• What should be included in an integration brief before CareLink signs a customer?
• How should Aisha price implementation, maintenance, and interface monitoring?
• Which data governance, privacy, and custodian questions matter in Alberta deployments?
• How can the company avoid becoming a custom consulting firm while still selling to health ecosystems?

Case narrative

Foothills Motion Labs created a kit for remote mobility assessment. Patients attach two small motion sensors, complete a guided movement protocol in an app, and clinicians receive a report comparing range of motion, balance, and adherence over time. Leah understands clinical workflow and customer pain deeply, but she is not a software or hardware engineer.

The prototype was built by a talented contractor who handled firmware, the mobile app, and a simple backend. It impressed early customers, but the contractor now has limited availability. The codebase has weak documentation, firmware updates are manual, and the app depends on several undocumented assumptions about sensor pairing. Leah has funding for two hires but is unsure what roles matter most.

Advisors give conflicting advice. One says to hire a senior full-stack developer and keep hardware outsourced. Another says the company needs an embedded systems lead because sensor reliability is the product. A third says Leah should hire a technical product manager first to translate clinical needs into requirements, manage contractors, and prevent rework. Meanwhile, a large occupational health customer wants custom reporting within eight weeks.

Dilemma

Leah must decide how to build a technical organization without over-hiring, losing contractor knowledge, or letting one customer's custom request distort the product.

Options

• Hire a senior full-stack lead: stabilize the app, backend, deployment, and data model while continuing to contract firmware work.
• Hire an embedded systems lead: focus on sensor reliability, firmware updates, connectivity, and hardware test discipline.
• Hire a technical product manager: create requirements, manage contractors, own documentation, and force tradeoff decisions.
• Form a fractional technical bench: combine a part-time CTO, firmware contractor, QA advisor, and software contractor while deferring full-time hiring.

Discussion

• Which technical risks are most existential: app stability, firmware reliability, data quality, or customer-specific reporting?
• What knowledge transfer should Leah require from the original contractor before more features are built?
• How should technical leadership differ at prototype, pilot, and production stages?
• What role should clinical domain expertise play in product management and acceptance criteria?
• How can Foothills decide whether the occupational health request is strategic product learning or distracting custom work?

Case narrative

Aurora Imaging AI built a model that helps prioritize imaging studies for review and drafts structured findings for radiologist confirmation. The pilot product impressed clinicians because it reduced repetitive review steps and made urgent cases easier to spot. The company priced the pilot as a monthly site license based on the number of radiologists, assuming cloud costs would be manageable.

Three months into the pilot, Samira's finance lead discovered a problem. The model uses more compute than expected. Some studies require multiple processing passes, large images increase storage and transfer costs, and the team keeps more intermediate data for auditability and performance review than originally planned. The gross margin looks fine for low-volume clinics but weak for high-volume sites. The most attractive customers are the ones who generate the highest processing costs.

The team faces a second complication. To satisfy clinical and quality expectations, Aurora cannot simply cut processing steps. The model monitoring plan depends on storing inputs, outputs, confidence metrics, overrides, and subgroup performance indicators. The regulatory advisor says that if the system influences triage or reporting workflows, the team must treat monitoring, validation, and change control as core operating costs, not optional overhead.

Dilemma

Samira must rethink pricing without undermining customer trust. The current site license is easy to sell but may fail economically. Usage-based pricing matches cost better but buyers may resist unpredictable bills. Reducing model complexity could improve margins but might reduce product value.

Options

• Keep the site license: accept lower margins while optimizing infrastructure and negotiating higher renewal prices later.
• Add volume tiers: price by study volume bands, with overage thresholds and transparent assumptions.
• Use hybrid pricing: charge a base platform fee plus per-study or per-processing-unit fees for heavy usage.
• Redesign the AI pipeline: reduce processing passes, use cheaper inference paths where safe, and reserve advanced processing for selected cases.
• Narrow the product: focus on a workflow where clinical value per processed study justifies the cost.

Discussion

• Which cost drivers should Aurora model before signing the next customer?
• How should pricing account for compute, storage, monitoring, validation, support, and quality-system overhead?
• What usage limits or service assumptions should be visible in the contract?
• How can the company avoid hiding AI cost inside a simple license that later becomes unprofitable?
• What would a responsible Alberta pilot dashboard show about clinical value, model performance, and operating cost?

Case narrative

Kananaskis Remote Care built a kit for rural and remote monitoring after discharge. The kit includes a cellular hub, a pulse oximeter, a blood pressure cuff, a patient app, and a clinician dashboard that flags deteriorating patients for follow-up. The first prototype was built with seed money, founder salary deferral, and help from two graduate students. A small trial with one Alberta clinic showed promising workflow fit, but the launch version needs better device provisioning, cybersecurity review, EMR export, bilingual patient instructions, quality-system documentation, and a stronger evidence plan.

Nadia has three possible launch markets. The first is Alberta primary care, where the product could reduce avoidable visits for chronic disease patients. The second is Indigenous and northern community care, where the system would need deeper community partnership and culturally safe implementation research. The third is emergency and defence-adjacent remote care, where the same rugged kit could support field triage, disaster response, or austere operations if the company can prove reliability and a real dual-use need.

The team has six months of runway. A venture investor is interested but wants a broader AI platform story. Nadia would rather use non-dilutive funding to reach a launch-ready product, then raise on better terms. Her CFO warns that grants do not all solve the same problem: some fund research through academics, some fund company R&D, some are tax incentives after spending occurs, some require matching cash, and some are poor fits unless the market direction changes.

Funding menu on the table

The team maps each program to a launch milestone instead of treating funding as a generic cash source. Program rules, deadlines, stacking limits, and intake status must be checked before applying.

Dilemma

Nadia must choose a funding direction before her team writes applications, hires staff, or promises customers a launch date. The wrong stack could waste months, misrepresent the company, or fund research that does not reduce launch risk. The right stack could bridge the company from prototype to launch without giving away too much equity too early.

Options

• Clinical evidence stack: pursue CIHR-aligned research with a university clinical team, pair it with Mitacs Accelerate interns for implementation and data work, and use Alberta Innovates when a relevant digital health intake opens.
• Engineering commercialization stack: use IRAP for company-led technical hardening, Mitacs Accelerate or NSERC partnership work for deeper engineering uncertainty, and SR&ED to recover eligible experimental development costs after spending.
• Adoption and business model stack: use Mitacs BSI for pricing, procurement, and market segmentation; pair with SSHRC partnered research on workflow, trust, and implementation barriers in rural and community care.
• Dual-use launch stack: explore RDII only if the team can document real emergency, defence, or austere-care demand; combine with IRAP or NSERC-style engineering validation for ruggedization and reliability.
• Investor-led stack: raise venture capital now, then use non-dilutive programs selectively for specific milestones without letting grant availability drive product direction.

Discussion

• Which launch path is most credible: Alberta primary care, Indigenous and northern community care, employer health, emergency response, or defence-adjacent remote care?
• Which uncertainty is most important before launch: technical reliability, clinical evidence, adoption behaviour, pricing, manufacturing, cybersecurity, or market access?
• Which programs fund company work directly, and which require a post-secondary researcher or intern to lead the funded activity?
• How should Nadia handle matching cash, reimbursement timing, tax credits, stacking limits, and grant reporting when calculating runway?
• Where could combining programs create a coherent roadmap, and where would it create administrative load without launch value?
• What evidence would make RDII a legitimate direction rather than opportunistic funding chasing?

Case narrative

ClearPath Diagnostics began as a university research project that combined a low-cost assay cartridge, a small optical reader, and software that interprets the result for use in community clinics. The early prototype was promising: it could shorten a diagnostic workflow that normally required samples to be shipped to a central lab, and rural clinicians saw potential value if the device could be made reliable, affordable, and easy to support.

The invention was not created in a clean startup environment. The assay chemistry came from a faculty lab, the reader enclosure was refined by an engineering capstone team, the first interpretation algorithm was written by a graduate student, and some validation data came from a hospital-affiliated pilot with strict data-use terms. Priya and two co-founders built a better software workflow after hours, but the core patentable method appears to sit partly inside university-owned IP. The university technology transfer office has asked the team to complete invention disclosures and is offering help with patent counsel, prior-art review, a provisional patent strategy, investor introductions, and a path toward a startup license. Priya knows the company will still need its own legal advice, but the office can help her understand what must be documented before the company presents the opportunity to investors or pilot partners.

Priya wants to move quickly. A regional clinic network is willing to run a paid pilot if ClearPath can deliver ten devices within nine months. A venture investor says the company needs exclusive rights to the core IP before financing. An incubator advisor says the university can be an important ecosystem partner, especially for patents, grant applications, clinical validation, and credibility with health-system buyers. A co-founder argues that the license terms may be too expensive for an early company: university equity, royalties, patent-cost reimbursement, milestone obligations, publication rights, diligence requirements, and restrictions on sublicensing could all affect the cap table and future partnerships.

The team has a second path. They could bootstrap around the university IP by narrowing the product into a workflow and quality-control tool that uses commercially available readers and public methods. That would avoid a complex license, but it may also weaken the company's defensibility, reduce investor interest, limit access to the original research team, and make the clinical story less compelling. Priya must decide whether to build the company as a university spinout, negotiate a staged license, or launch a narrower independent product first.

Dilemma

Priya must decide how much IP control the company needs before launch, whether sharing economics and governance with the university is worth the patent and ecosystem support, and whether bootstrapping a narrower product would preserve speed at the expense of defensibility. The wrong choice could either slow the company inside licensing negotiations or leave it without the rights investors, clinical partners, and future acquirers expect.

Options

• Accept the standard university license: secure exclusive startup rights, patent support, and institutional credibility, while accepting equity, royalty, diligence, reporting, and patent-cost obligations.
• Negotiate a staged option-to-license: pay for a limited option period, define field-of-use rights, clarify who pays patent costs, preserve investor flexibility, and convert to a full license after technical and market milestones.
• Build an ecosystem commercialization plan: combine the university, technology transfer office, incubator, clinical investigators, non-dilutive funding, contract manufacturers, and clinic pilot partners into a launch roadmap with explicit governance.
• Bootstrap a narrower product: avoid disputed university claims by building a workflow, training, analytics, or quality-control product around public methods and commercially available hardware.
• Pause for IP and data cleanup: document contributors, invention ownership, open-source dependencies, data-use permissions, patentability, freedom-to-operate concerns, publication plans, and future improvement rights before signing customers.

Discussion

• What must ClearPath own, license, or control before raising investment or signing a clinical pilot?
• Which licensing terms matter most beyond the headline equity or royalty: exclusivity, field of use, sublicensing, patent prosecution, improvement rights, diligence milestones, reversion, and publication rights?
• How should Priya separate university-owned IP, founder-owned know-how, clinical data rights, open-source software, and future product improvements?
• When does the technology transfer office accelerate patents and launch readiness, and when might it slow operational decisions?
• What would a venture investor, health-system buyer, or strategic partner ask during diligence?
• How can an ecosystem approach reduce technical, clinical, funding, and commercialization risk without creating too many decision-makers?
• If the team bootstraps first, what product boundary avoids university IP while still solving a meaningful customer problem?

Case narrative

Riverbend Recovery helps patients complete rehabilitation exercises after knee and hip surgery. The product includes daily exercise plans, pain and function check-ins, short videos, reminders, and a clinician dashboard that flags patients who appear to be falling behind. The prototype is a responsive web app that patients open from a text-message link. It is easy to update, cheap to maintain, and worked well in a 40-patient discovery pilot.

The next pilot will involve 600 patients across several clinics. Omar's team wants to add Bluetooth range-of-motion sensors, push notifications, offline exercise access, camera-assisted form checks, and more polished onboarding. The lead engineer recommends native iOS and Android apps because device permissions, notifications, background behaviour, Bluetooth, and app-store trust are stronger. She argues that if the phone becomes part of a regulated care workflow, the team needs predictable device integration and stronger release discipline.

The product manager disagrees. A progressive web app would let patients start from a link without app-store friction, support clinics with mixed devices, ship updates quickly, and avoid maintaining two native codebases. She notes that many patients are older, some use shared family devices, and some clinic staff do not want to become app-install support. The PWA can still support responsive design, authentication, basic offline caching, and home-screen installation, but it may be weaker for Bluetooth, reliable notifications, deep device features, and store-based discoverability.

The budget forces the decision. Riverbend has enough runway to build either a robust PWA and clinician dashboard or two native patient apps with fewer dashboard improvements. The clinics want a smooth launch, the advisors want an evidence-ready product, and Omar wants to avoid a technical choice that either blocks the sensor roadmap or creates unnecessary development and QA cost.

Dilemma

Omar must decide whether the patient experience should be delivered as separate native iOS and Android apps or as a progressive web app. Native apps may support the product's device-heavy roadmap better, but they increase build, testing, release, and support burden. A PWA may launch faster and reduce friction, but it may not support the future clinical workflow reliably enough.

Options

• Build native iOS and Android apps now: invest in stronger device access, push notifications, Bluetooth sensor support, offline behaviour, app-store presence, and platform-specific accessibility polish.
• Stay with a PWA for launch: prioritize low-friction onboarding, fast iteration, easier clinic rollout, shared code, lower maintenance cost, and web-based deployment while delaying advanced sensor features.
• Use a staged approach: launch the next pilot as a PWA, collect adoption and workflow evidence, and build native apps only if Bluetooth sensors, notifications, or offline use prove central to outcomes.
• Split by user and workflow: keep the clinician dashboard and lightweight patient check-ins on the web, then build a native companion app only for patients using sensors or high-touch recovery pathways.
• Use a cross-platform mobile framework: build one shared mobile codebase for iOS and Android while accepting framework-specific risks, plugin dependencies, and the need for native expertise when device features break.

Discussion

• Which product requirements truly need native capabilities: Bluetooth, background activity, notifications, camera features, offline access, biometric login, or app-store distribution?
• How should Riverbend compare total cost of ownership across native apps and a PWA, including QA, release management, support, analytics, accessibility, and security updates?
• What patient onboarding barriers matter most in Alberta clinic deployments: app installation, password setup, device compatibility, connectivity, language, accessibility, or caregiver support?
• How would each approach affect regulated change control, validation evidence, incident response, and post-launch monitoring?
• What evidence should Omar gather in the 600-patient pilot before committing to a permanent platform strategy?
• Could the company define a minimum viable app platform now, while keeping the architecture flexible enough to add native sensor workflows later?