SwissDnaCode — scope summary

A three-column read-out of everything Workshop 2 settled — what ships in V1, what waits for the Vision phase, and what is explicitly out of scope.

Credit-based usage is dropped — credits are not tangible for end customers and distract from the core value. The platform now presents fixed-price products to clients.

Version 1 ships as a mobile-optimised web app — strictly web — and its UI is styled to look like a native app. A true native app is a follow-up step that only makes sense when the financial case justifies it. The architecture below is set up so the later native build is faster and cheaper.

Architecture choice now, native path later: the frontend technology is picked already in V1 so the future native build can reuse it — the native app then carries only the frontend, with the backend reached through the same API the web app uses.

No URL to type — desktop and mobile: the customer should launch via an icon or button on either device, never by opening a browser and typing an address.

Consent for sharing customer data with the doctor is captured as early as possible, during onboarding. It is a mandatory statement — not an optional question — and the user cannot proceed without it. Because it's mandatory at onboarding, the platform avoids repeated per-upload prompting later in the chat.

Both bots ship in the first release. They share the same underlying data basis but maintain separate chat histories and produce different kinds of answers — medical depth for the doctor, reduced and safe guidance for the customer. The doctor bot is accessible directly from the patient detail page.

Same data basis, two interfaces. The doctor bot is the medically open assistant; the customer bot is the supervised, safer variant — both running on the same uploaded findings. Clean separation between them is mandatory.

Medication recommendations are driven by the customer's DNA. Because Germany, Switzerland, and Austria use different product documents and brand names, the logic runs over active substances (Wirkstoffe) rather than the broader ingredient lists (Inhaltsstoffe) — active substances are unambiguous across borders.

Physical supplements and creams will not be sold directly on the platform — they are too sensitive to bundle with medical guidance. Printed reports are fine. An affiliate link to a supplement shop (commission, possible first-order discount) is acceptable as long as the storefront sits outside the platform itself.

First step on orders: the doctor or admin internally triggers product orders, so SwissDnaCode keeps the overview before the function is exposed to end customers.

Data must stay in Switzerland for every customer — this is the most important USP. The requirement constrains LLM choice: any model that cannot keep data in CH is out. Once that constraint is locked, we then choose the LLM that fits the project best.

Cost vs. quality: cost is still a black box. The approach is to not optimise for cost at the start — pick the model that delivers quality and optimise margin later at scale.

Dr. Farkas does not want to bring the 10 existing clients across. The new bot will intentionally answer differently — more medical and doctor-led than the lifestyle tone of the old one. The chosen path is to inform existing customers and let them prepare with some input of their own, rather than try to migrate transcripts.

How many of the 10 will continue is still open. Treat each as a re-acquisition rather than a guaranteed carry-over.

Each role (Super-Admin, Arzt-Admin, patient) gets its own settings — the current admin view is symbolic and will be split out. The patient detail becomes the working surface for doctors: findings, patient context, and the doctor bot all live in one place, with no switching between views.

Academy / videos: the "Academy" area may be renamed initially since it carries only intro / explainer videos at first — covering DNA sample collection and how the whole system works. Extended learning videos arrive later. Implementation choice: Memberspot.de API integration or a self-coded basic version.

Not in V1: the category tabs (Sleep, Nutrition, Fitness, Supplements). These return in later phases once the V1 surface is stable.

The main complaint about today's ChatGPT bot is that it hallucinates, intermittently stops accessing stored data, and gets erratic under intensive use. The new platform must contain this. Restrictions are partly LLM-dependent — the chosen model self-restricts on medical advice — but the strategy does not rely on base settings alone.

Three roles ship in the MVP: doctor, admin, and client. They are designed so additional roles can be added later without a rewrite — expanding the role model after the fact is costly. The doctor and admin roles are kept as separate concepts from day one, so a doctor can advise without holding admin privileges.

Therapist role — Vision, not MVP: external therapists arrive in a later phase, slotting into the same model without breaking the doctor / admin separation already in place.

"Done" for V1 is defined by four unified criteria. They tie the technical quality of the AI to the business signals that show the platform actually working for customers.

The core motivation is to live healthier and optimise daily life based on DNA. Customers expect everyday answers tied to their genetics, plus the ability to save useful results and come back to them later.

This summary captures every decision and open question from the second workshop. Prototype extension begins on Monday in parallel with the LLM and cloud-cost research.

Open points — still to decide

The next workshop steps into the AI design itself: what the assistant does, what it refuses, how it uses the customer's data, and what guardrails apply — before any technical decisions on model and infrastructure are finalised.

Workshop 3 deliverables