Preventa
CTO and co-founder since 2019
A preventive-health platform with AI retinal image analysis, engineered to the highest standards. Eric has been Preventa's CTO since 2019 and has a financial interest in the company beyond the engagement fee — disclosed here because it is not an arm's-length client relationship.
Visit preventawellness.comAt a glance
- Our role
- CTO and principal engineer since 2019
- Engagement history
- Continuous since 2019. Eric was principal investigator on NSF SBIR Phase I #1941226 (the award was made to Preventa Medical Corporation) and has been CTO of the company since, through its commercial platform at preventawellness.com.
- Disclosure
- Paid fractional CTO engagement. Eric is also a co-founder and has a financial interest in Preventa beyond the engagement fee. Not an arm's-length client engagement.
- Product owner
- Preventa (the client owns the product and the IP)
- Data sensitivity
- Sensitive health data — engineered to the highest standards, not the minimum the product is held to
- Platform
- Flutter, cross-platform, on HIPAA-eligible cloud services
- AI component
- Retinal image analysis for preventive health insights
The challenge
What made this hard
Preventa needed to put AI-assisted retinal image analysis in front of real patients. That combination — medical imagery, machine learning, and consumer-grade UX — puts sensitive health data into every layer of the system at once. Health data is the one domain where "mostly secure" is not a defensible position: the architecture has to satisfy regulators, hospital security teams, and patients simultaneously, and the decisions that determine whether it does are made in the first weeks of the build, not retrofitted before an audit.
The approach
Treating health data as an architectural constraint, not a checklist
Most teams discover their health-data obligations late, then try to bolt controls onto a system that was designed without them. That is where the expensive rewrites come from. We inverted the order: the boundary around sensitive health data was drawn before the first feature was built, and every subsequent decision — where images live, which services can read them, what gets logged, what crosses a network hop — was evaluated against that boundary.
Practically, that meant identifying exactly which data elements were sensitive, keeping them inside a narrow set of services, and making sure every vendor that could touch those services was covered by a Business Associate Agreement. As a wellness product the platform is not required to meet the full HIPAA rule — the standard is voluntary, and that is the point. Any component that could not be BAA-covered was designed out of the sensitive-data path rather than granted an exception.
Encryption, access control, and audit logs that are actually queryable
Health data is encrypted at rest and in transit. That part is table stakes, and every vendor claims it. The part that distinguishes an audit-defensible system is access control and logging: who touched which record, when, and through what path — and whether you can answer that question quickly when someone asks.
Audit logs are only useful if they can be searched under pressure. We built logging as structured, queryable records tied to identity and resource, rather than as an append-only stream nobody can interrogate. Role-based access controls sit in front of health-data reads so that permission is granted per-role and per-resource instead of being implied by a successful login.
Running AI inference without widening data scope
Retinal images are sensitive health data. Any AI pipeline that processes them inherits the full sensitivity of that data, which rules out the casual approach of shipping images to whichever inference API is most convenient. The pipeline had to stay inside infrastructure the client controls and a BAA covers.
I designed the image-handling path so that the analysis runs against controlled storage with explicit, logged access, and so that the surrounding analytics and product telemetry operate on de-identified data. Product questions get answered without every dashboard becoming a sensitive-data system.
One Flutter codebase, without the cross-platform tax
Preventa is a Flutter application, which let a single codebase serve multiple platforms — the right economics for a company that needs to reach patients broadly without funding three parallel native teams.
Cross-platform only works when it is architected deliberately: a real state management layer, declarative navigation, and a design system shared across surfaces. Done that way, the codebase stays one product rather than three diverging ones that happen to share a language.
Outcome
What shipped
- A health platform running in production at the highest standard, owned outright by the client
- Health data encrypted at rest and in transit, with BAA coverage across the vendor stack
- Structured, queryable audit logging and role-based access controls over health data
- AI retinal image analysis running inside controlled, BAA-covered infrastructure
- A single Flutter codebase serving multiple platforms
- Architecture documented so the client is never locked in — they own the code, the cloud accounts, and the IP outright
Stack
More work
PriceHarvest
A Flutter web app that tracks prices across retailers and tells shoppers the moment to buy — co-developed by IN2Labs.
GhostX
A suite of free browser tools whose privacy guarantee is structural rather than promised: the single-file tools have no upload endpoint at all, and the sharing flows are end-to-end encrypted with a key the server never receives.
Building something like this?
A 30-minute technical triage. Tell me where you're stuck — I'll tell you what it takes. I confirm every request within 24 hours.
Request a technical triage