MindStride did not have a product team. It had two founders with a direction, an external delivery partner, and me.
I joined in April 2023 as the first employee, after the earliest product concepts had already been drawn by hand — before the company was formally incorporated. My title is UX/UI Designer. What the company needed was someone who could turn a founder's sentence into something a team could build, test, and release without breaking the four other systems it touched.
Three years later that work spans eleven delivery projects: a patient mobile app and web portal, a provider EMR, an in-house conferencing system, assessment and intervention tools, a content engine, payments, AI services, and external integrations.
Founder-led priorities arrived as outcomes, not specifications. The team changed twice, the business expanded from mental health into primary care, and every new workflow touched several systems at once.
Everything between an approved direction and released software: workflow definition, requirement clarification, ticket creation and routing, cross-functional coordination, hands-on QA, and release-readiness verification.
A live care platform serving both employer clients and individual subscribers across four Canadian regions — delivered through two engineering-team transitions and a business-model expansion, without interruption to service.
What MindStride had to become
MindStride sells health coverage to Canadian employers and directly to individuals. Employer-sponsored programs are the larger share of the business, but the platform serves both. The category it competes in has a well-documented problem: fewer than 5% of employees covered by a traditional EAP ever use it, because access means calling a 1-800 number and waiting. MindStride's answer is continuous care — rapid triage, a mobile app people actually open, assessments and interventions assigned by a provider, and monitoring between visits. Delivering that means the software cannot be one product.
of employees covered by a traditional EAP ever use it. Access starts with a phone call and a wait — which is the behaviour the platform was built to replace.
A patient books through the mobile app or the web portal. A clinician works in the provider EMR. A session runs in an in-house conferencing system. An assessment is authored in one place, assigned in another, completed in a third, and scored into a fourth. Employer accounts sync from HRIS; individual subscribers pay through Stripe.
Three things changed while this was being built. Development moved from an external delivery partner to an internal engineering team around the first launch in 2024. The business expanded from mental health into primary care, so the clinic and the software had to evolve together. And the engineering team grew to about ten people spread across those eleven projects.
In a startup this size, requirements do not arrive as specifications. A request explains the outcome someone wants and leaves the states, permissions, data dependencies, and failure conditions unanswered. Someone has to find those gaps before they reach engineering, and keep design, development, and testing aligned while the answers change.
Where my ownership begins
My title is UX/UI Designer. My scope is product delivery, technical project management, product operations, UX, and QA. I report to the CTO and work daily with the engineering team; during the external-vendor phase I was also the bridge between the founders, the vendor's designers, and its developers.
I do not own every product decision. I own the system that makes approved decisions executable and verifiable.
Eleven delivery projects
The two sections that follow are two of those eleven projects. I chose them because they show different kinds of delivery problem: one is a configuration system that removed a recurring engineering dependency, the other is a single user journey that had to behave correctly across five systems at once.
Turning clinical rules into a configurable system
Assessment is the first step in MindStride's AIM model — Assessment, Intervention, Monitoring — and the first structured connection between the platform and a patient's needs. The original onboarding assessment was hard-coded, which meant that changing a single question required an engineering ticket.
Today the system runs 14 active assessments, and 13 of them were created by clinical staff through the Builder without any engineering work. That is what the feature was for: it turned a recurring development dependency into a clinical operations capability.
The clinical inputs were fixed. Standard instruments such as PHQ-9 and GAD-7, along with internally authored questions, came from the CMO and the clinical team, who also set the scores and severity thresholds. The patient-facing requirement was one question at a time.
I turned those inputs into a configuration model. An authorized user creates an assessment in the EMR Builder, organizes questions into groups, assigns a score to each option, defines score ranges and colours, and adds conditional branching where the clinical logic requires it. A provider assigns it from AIM Manager. The patient completes it in the mobile app through single-choice questions with minimal interaction. The system scores the result and classifies it as critical, moderate, or minor; the EMR Summary shows a red, yellow, or green card so a provider can see which results need attention first.
Conditional branching was the hardest part. When the CTO identified the need for it, we worked through the solution together and I designed how an assessment creator would configure each branch — which answer leads where, and what happens to the score when a path is skipped.
After release, the clinical team asked for one more capability: reassigning an assessment to the same patient over time, so change could be tracked. I worked with engineering to extend AIM Manager so a provider could create a new assignment from an existing assessment, then validated the updated workflow across the Builder, the mobile app, and the EMR.
No scoring or workflow issues have been reported since release.
One user journey that had to work across five systems
Before online booking, every appointment required a phone call to the clinic. Replacing that was not a matter of picking a doctor and a time. The flow had to serve registered and unregistered users, distinguish B2B members from B2C customers, activate accounts where necessary, collect payment where required, and create the correct record in the correct provider's EMR schedule.
The entry path for the largest user group
B2B members are the largest audience, but they do not all start from the same state. An activated member opens the app, chooses a provider and an available time, and confirms. An eligible employee whose account has not been activated has to get into the product first. I redesigned that embedded activation journey from 14 steps to 3, with the home screen immediately after, so the member could continue straight into booking. The CTO approved the simplified flow. This was the clearest product decision I led in the initiative: remove avoidable setup work before asking someone to complete the task they actually came for.
steps in the embedded B2B activation journey, with the home screen immediately after — so a member continues straight into booking.
B2C added a payment dependency
An unsubscribed user needs the service explained, payment collected through Stripe, and only then a completed booking. Data showed users leaving at the payment page, and the sequence was changed so that payment came later in the journey. I owned how that approved sequence actually behaved — service-price disclosure, payment states, the Stripe handoff, and booking confirmation — across every entry state a user could arrive in.
The provider side
Appointments is a separate provider-facing feature that exists only in the EMR, and I led its feature-level workflow. A completed booking creates an appointment record automatically, and access follows the clinical relationship: each provider sees only their own schedule and patients. The record also connects the visit type to the next action — an online appointment opens MindStride's conferencing system directly from the EMR; an in-person appointment supports the clinic visit and lets the provider check the patient in from the Appointments page.
Booking moved from a phone-only dependency to a connected self-service journey: activation or registration, provider and time selection, payment where applicable, appointment creation, provider scheduling, and entry into virtual or in-person care.
Keeping delivery intact through two team transitions
The operating model changed twice while the product was being built, and both times the delivery system had to hold.
During the external-partner phase I converted founder discussions into a Figma wireframe foundation for the original EMR and mobile app, explained the intended functionality to the partner's UI designers, and stayed involved with their developers through implementation. I reviewed each build, captured screenshots, and marked up what was wrong, where it occurred, and how the behaviour differed from what was specified. There was no ticket system at that point, so those decks were the system — annotated screens filed by date, one deck per review pass. Founder approval was the formal design gate; implementation quality was mine.
When the external engagement ended in August 2024, the internal engineering team took over. Collaboration became more direct, but the need for shared visibility went up, because the work now spanned about ten engineers and many connected systems.
I maintain the operational source of truth
A single source of truth was the first thing I built once the internal team took over, because the PowerPoint decks had never been consolidated. Before Jira it was a shared tracker recording the ticket title, the detailed issue, the owner, and the status — 249 completed records across the EMR, the mobile app, and web, with no overlap into Jira. The counts on this page start there; the vendor-era review work is not included in them. That tracker carried the work for about a year. When the team adopted Jira in August 2025 I moved the same discipline into an explicit lifecycle.
The two states that matter most are the ones teams usually skip. Back to Development is where work goes when it fails testing, so a fix that did not actually work cannot be quietly closed. Test Passed is the only route to production.
As of mid-2026 that adds up to over 600 documented tickets across 11 delivery projects — EMR, mobile app, web, the Martha AI assistant, User Portal, the micro content engine, conferencing, payments, nurture and integration work. I create roughly 95% of them and I manage, test, and verify all of them.
Release readiness as evidence, not opinion
In healthcare software a feature is not complete because its main screen looks correct. A workflow can fail on state, data, timing, permissions, or an interaction with another platform — and the failure lands on a patient trying to get care. I treat QA as a continuous product activity rather than a final visual review.
If the defect is still there, the ticket goes back to development instead of being closed for the sake of progress.
A privacy defect in the conferencing system
One example came from the in-house conferencing system, which carries online appointments for both mental and physical healthcare. I found a high-severity defect that could have exposed user information. In a healthcare product that is not a bug, it is a privacy incident waiting to happen. I documented it, worked with engineering to isolate and correct it, and then verified the fix repeatedly — across multiple rounds, on different devices, with colleagues testing alongside me — before it was allowed anywhere near production.
The most valuable tester is not checking whether a requirement exists. They are asking how the system could fail during someone's real task.
The details are confidential, but the lesson generalizes. Release readiness follows the same principle: before a release decision the CTO asks me to confirm that the relevant tickets are complete and that reported defects have passed testing. Leadership issues the release instruction; my job is to make that decision evidence-based rather than optimistic.
What three years produced
MindStride went from pre-incorporation sketches and zero users to a live care platform serving both employer clients and individual subscribers across four Canadian regions. Patients reach care through the mobile app or the User Portal; providers work in the EMR and the in-house conferencing system; thousands of users have activated accounts and used the service.
Three kinds of evidence describe my contribution.
- Booking: phone-only → connected self-service across patient and provider systems.
- Assessment authoring: engineering ticket → a task a clinician performs without code changes.
- B2B activation: 14 steps → 3, with booking available immediately after.
Over 600 documented tickets across 11 delivery projects, roughly 95% created by me and 100% managed, tested, and verified — alongside the original Figma foundation for the EMR and mobile app.
The platform kept operating through two engineering-team transitions and an expansion from mental health into primary care. No scoring or workflow issues have been reported on the assessment system since release.
Clarity is its own kind of leverage
MindStride changed how I understand product leadership. Roadmap authority is one form of ownership. It is not the only one, and in a founder-led startup it is not the one that determines whether anything ships.
What I learned to do instead was create leverage through clarity: surface the decisions nobody had made yet, make workflows understandable to people who would never see the whole system, keep dependencies visible, document evidence, and refuse to call something done before it was.
Three things I would introduce earlier
- Consistent acceptance criteria and a formal release checklist from the first development cycle, rather than after the second team transition.
- A lightweight decision log, so that changing requirements kept their rationale attached.
- A systematic user-feedback and product-analytics loop. We had useful input from internal providers, but limited direct patient feedback made it harder to say whether a released workflow changed behaviour, not just whether it worked.
The project clarified where I add the most value: translating intent into flows, making cross-functional work visible, finding the risk before the release, and carrying a feature through to the point where someone can actually use it.
This case study focuses on my process, scope, and contribution. Specific user counts, internal ticket detail, and some technical specifics are generalized to respect company confidentiality.
