Building AcuFlex with S.A.E. Orthopedics: Lessons for Healthtech Startups

Ankle dorsiflexion (how far the foot can bend toward the shin) is routinely assessed in musculoskeletal care, but in most cases, the evaluation remains largely observational and difficult to quantify. As a result, two clinicians may interpret the same ankle movement differently, assign different exercises, and achieve different outcomes for the same patient. For Dr. J. Michael Davis, an orthopedic surgeon with 30 years of experience, this variability signaled a clear opportunity: standardize the assessment and turn it into measurable, trackable data.

Together with his team at S.A.E. Orthopedics, he designed AcuFlex — a smart slant board system equipped with motion sensors to capture dorsiflexion range and lower-limb alignment under load. The team assembled an early hardware prototype in-house using off-the-shelf components and found a suitable manufacturer for mass production.

What the prototype lacked was a production-ready data processing infrastructure and a connected app with an intuitive clinical interface. ScienceSoft joined the project to deliver a proof of concept and an MVP, addressing the technical, architectural, and strategic challenges that often determine whether such products scale or stall.

The Logic of Measuring Ankle Dorsiflexion

For AcuFlex, S.A.E. Orthopedics built on a familiar clinical maneuver used to assess loaded dorsiflexion and translated it into an instrumented, sensor-based format. Unlike visual checks or single-angle tools, the system captures two compensation indicators in sync: the degree of heel lift and the angle of lower-leg deviation relative to the reference board. By tracking these values in real time, the platform identifies not only the maximum available range but also when exactly compensation begins.

This distinction matters. Measuring the pure range of motion provides only part of the picture. Monitoring compensation patterns helps assess movement quality and tolerance under load. Over time, clinicians can observe whether the patient maintains form at greater angles, whether compensations occur later in the session, and how mobility trends evolve across visits.

Lesson 1: Define a Precise Clinical Use Case Before Expanding Scope

The way a product defines its intended use affects how the system is designed, which features are essential, and how future regulatory documentation will be structured.

In the case of AcuFlex, the team did not set out to build an all-encompassing rehabilitation platform. The focus was deliberately narrowed to one clearly defined use case: structured, clinician-guided dorsiflexion assessment under load, with repeatable measurements and session tracking over time.

This decision influenced everything that followed. A tightly defined intended use reduced ambiguity in feature discussions. It clarified what the system had to measure and what it did not. It also helped frame the product against existing predicate devices for a future 510(k) submission, since demonstrating substantial equivalence is easier when the use case is specific and bounded.

From an innovation standpoint, specialization can offer an advantage. Broad platforms often promise flexibility across multiple conditions and movement types, but that breadth introduces technical complexity and higher evidentiary demands. A focused device can go deeper into one measurement scenario and build reliability and repeatability around it.

This does not mean that narrow positioning is universally superior. Some products require a broader ecosystem to deliver value. However, defining a precise initial use case can reduce early-stage uncertainty and make both technical and regulatory paths more manageable.

Lesson 2: Confirm the Core Flow Early

When a team introduces a new technical approach to a clinical problem, the first step is to confirm that the central mechanism works reliably outside of theory.

In the AcuFlex project, ScienceSoft and S.A.E. Orthopedics agreed on that mechanism early. The system had to capture sensor readings from the board, transmit them securely to a mobile device, and convert them into consistent mobility metrics that clinicians could interpret. Before expanding the feature set, the team concentrated on making this sequence dependable in real-world conditions.

ScienceSoft built a focused proof of concept and deliberately limited its scope. The team began with a single mobile platform to reduce variability and shorten iteration cycles. We concentrated on one question: can the system generate stable, repeatable mobility readings during live sessions?

Testing revealed that it could — but not consistently. The data transmission between the board’s sensors and the mobile app proved unstable due to signal interference from nearby wireless networks and electrical noise within the device’s internal wiring.

Because the problem surfaced early, ScienceSoft was able to address it quickly by modifying the hardware prototype. The team introduced signal filtering components to reduce high-frequency interference and introduced additional decoupling components to separate the sensor communication lines from internal noise. These changes significantly improved signal stability during the next test sessions in both clinical and home environments.

Naturally, fixing a prototype is not enough if the same issue reappears in production. ScienceSoft worked with S.A.E. Orthopedics and their manufacturing partner to ensure that the revised component configuration could be consistently replicated at scale. This step helped translate a technical fix into a production-ready solution.

Lesson 3: Design Architecture Around Real Usage Constraints

Architectural decisions shape how the product behaves in practice and how complex it becomes to maintain.

In the AcuFlex project, the team had to decide where mobility metrics should be calculated. The system derives values like maximum, minimum, and average joint angles directly from real-time sensor readings. These calculations are deterministic and relatively lightweight. They operate only on the current session’s data and do not require large historical datasets or advanced modeling.

Given these characteristics, ScienceSoft chose to run core calculations directly on the mobile device. This reduced latency during sessions and avoided unnecessary back-end complexity. The app can display updated metrics immediately, without waiting for a round-trip to the cloud. At the same time, the server infrastructure handled storage, user management, access control, reporting, and data export.

This distribution reflects how the product is actually used. Sessions are short. Measurements are generated live. Clinicians expect immediate feedback. In that context, pushing all processing to the cloud would have added integration overhead without meaningful benefit.

In another type of product, the decision might be different. If mobility analysis relied on computer vision, longitudinal modeling, or cross-patient analytics at scale, cloud-based processing would likely be more appropriate. The architecture should follow the data profile and usage pattern, not convention.

Before choosing where logic lives, examine what the product computes, how often it computes it, and under what conditions. In AcuFlex, aligning the architecture with real usage constraints reduced system load and kept the solution technically proportional to its clinical purpose.

Lesson 4: Consider the Regulatory Path From the Start

Because AcuFlex was intended for clinical use, S.A.E. Orthopedics planned to pursue FDA 510(k) clearance. That context influenced how the software was structured and documented from the start.

As the architecture took shape, ScienceSoft’s compliance consultant assembled the core software documentation required for submission preparation, including the cybersecurity file and the software risk management plan. These documents evolved together with the system’s functionality, so the described scope consistently matched the implemented one.

As a result, the transition from prototype to submission-ready product stayed clear and consistent, both technically and formally.

From Early Decisions to Product Reality

Building a connected medical product is a series of small, deliberate choices made early enough to prevent larger problems later. In our experience, that discipline often determines whether a clinical idea becomes something practitioners can actually rely on.