MedText.
From a reminder to understanding.

1. Reminders already exist. Build beyond the alert.

This focused review uses public product descriptions, not an exhaustive market survey or a hands-on comparison. Feature availability and commercial terms should be rechecked before procurement.

Public sources reviewed 30 September 2026. A feature omitted from this table should not be interpreted as absent from a competitor.

2. A differentiation hypothesis we can test

The potential advantage is the combination of reviewed visual content, accessible messaging, a dependable care workflow and measured benefit. Each component exists elsewhere; the combined experience must earn its place through testing.

Where AI could add value

• Draft onboarding: extract a proposed schedule from prescription text, flag ambiguity and require human verification before activation. Never infer missing dose instructions.
• Grounded explanations: retrieve an approved explanation and source version matched to a confirmed medicine. Use reviewed templates for safety-sensitive replies; decline individualized dosing changes.
• Barrier summaries: summarize a patient’s replies for authorized staff, preserving uncertainty and providing the original messages for checking.
• Communication preferences: test preferred wording and educational timing with consent. Never let an engagement model change a prescribed dose or dosing time.

These are planned features. The current demo uses deterministic replies and no AI model. A general chatbot can explain a drug; our proposed product would add a verified schedule, consent records, delivery handling, care-team responsibilities and an auditable link to reviewed content.

3. Initial prototype and first live MVP

Initial boundaries: adult, stable daily schedules verified by a clinician, pharmacist or patient against an existing prescription. Begin with a small approved medicine set. Defer as-needed reminders, tapering, pediatric regimens, complex cycles and high-risk variable-dose therapy until specific clinical workflows are designed. Do not automatically turn the ibuprofen explainer into a recurring dose reminder.

Delayed delivery, a snooze or an unanswered message must never generate a catch-up or double-dose instruction. Support must tell patients when it is monitored and how to get help outside those hours.

4. A gated, 12-week path

Relative weeks begin after a project owner, budget and clinical partner are confirmed. These are planning estimates; enrollment waits for the relevant gates to pass.

1. Weeks 1–2 · Find the right problem

   Interview approximately 10–15 patients/caregivers and 3–5 pharmacists or clinicians. Observe reminder setup, missed notifications, refill barriers and language needs. Clear the working name.

   Exit gate: choose one audience and a repeated unmet need; secure a willing pilot partner and define who responds to requests.

2. Weeks 3–4 · Test the experience

   Run usability sessions using this prototype. Test enrollment comprehension, discreet wording, STOP, caregiver permissions and whether educational links help. Clinically and linguistically review the proposed content.

   Exit gate: participants can identify that “no reply” is uncertain, snoozing is not dosing advice, and the service is not emergency care.

3. Weeks 5–8 · Build reliable delivery

   Implement the production service, provider registration, consent records and support queues. Test duplicate callbacks, phone reassignment, opt-out races, daylight-saving changes, schedule edits and outages with synthetic records.

   Exit gate: documented clinical/privacy review, provider agreements, operational ownership and all critical delivery/opt-out tests passing.

4. Weeks 9–12 · Run a supervised feasibility pilot

   Propose 20–30 consenting adults for an initial 30-day usability and feasibility pilot, subject to partner and research review. Measure delivery, understanding, opt-outs and staff workload.

   Exit gate: decide whether to refine, stop or design a powered comparison. This small pilot would not establish improved health outcomes.

5. Keep content separate from patient operations

• Database: retain the Supabase/Postgres direction, with a separate patient-data project and least-privilege access. Core records: participants, consent versions, caregiver grants, regimen versions, scheduled occurrences, delivery attempts, replies and support tickets.
• Scheduler: run server-side, independently of the website being open. Save IANA time zones and occurrence timestamps; define daylight-saving and travel behavior explicitly. Deduplicate each regimen version and occurrence, and recheck consent immediately before sending.
• Messaging: evaluate Twilio first through a replaceable transport adapter. Validate webhook signatures, process retries idempotently and distinguish queued, sent, delivered and failed. A delivery receipt cannot prove ingestion.
• State changes: STOP suppresses sends and caregiver follow-ups; schedule edits invalidate old jobs. Use bounded retries, dead-letter queues, monitoring and a rollback procedure. Prevent a stale job from reviving an old prescription.
• Storage: keep educational media in object storage/CDN and only content references in patient records. Keep identifiable health data out of public static files, analytics URLs, application logs and consumer Google Drive workflows.

Before real enrollment

Review the business model with qualified privacy and clinical advisers to determine applicable HIPAA, California privacy, messaging and other obligations. The prototype does not establish compliance. Supabase requires a signed BAA and its HIPAA add-on for PHI use; a normal project alone does not satisfy that requirement. Twilio supports eligible healthcare workflows under the appropriate agreement and configuration. Consent, sender registration, opt-out handling and incident response are launch work, not a checkbox added afterward.

Supabase HIPAA requirements · Twilio healthcare services · Twilio messaging consent policy · FTC health-app breach guidance

6. Measure the benefit before scaling

Commercial starting point: one Bay Area independent pharmacy or primary-care practice serving patients who prefer texts. Test a partner-funded service priced per active participant, with messaging limits and a clearly staffed support tier. Pricing and willingness to pay are hypotheses; no fee is committed here.

A feasibility pilot estimates usability and workload. A subsequent controlled study needs a prespecified primary endpoint, appropriate sample size, missing-data plan and review of research requirements. Do not call message replies “adherence improvement” or infer fewer hospitalizations from engagement.

Investment sequence: validate the unmet need, establish content quality, prove reliable delivery, then evaluate understanding and sustainable economics. The defensible asset would be the reviewed content and demonstrated workflow benefit—not the ability to send a text.