Requirements to Start Development
What we need from Hilo to begin building. Organised by severity (blocker / high / medium) and by owner. The Blocker items prevent any meaningful progress.
The single most valuable ask. If we can get an Entra ID account with Contributor role on the relevant Azure subscription, we can self-provision every other piece of infrastructure (VM, Postgres, networking, secrets, monitoring) without further back-and-forth. That one access decision unlocks ~70% of the infra requirements list below.
1. Blockers · cannot start without these
Provision an Entra ID account for the developer on the Hilo tenant. Add to the relevant Azure subscription with Contributor role on the resource group that will hold the B2B dashboard infrastructure (or a new RG dedicated to it).
This single permission unlocks self-provisioning of: VM, Postgres, networking, Key Vault, Application Insights, App Service, Storage. Without it, every infra piece needs a separate request to the Hilo tech team.
To design the patient data model and the mirroring path, we need to see the B2C schema. Acceptable forms (in order of preference):
- Read-only Postgres user on a dev/staging copy of B2C (best — also lets us test queries)
- Schema dump (
pg_dump --schema-only) plus a sample data export - Documentation of relevant tables: patients, devices, BP readings, sleep, steps, sync events
Without this, the data model on the B2B side is guessing.
Pick one (covered in Architecture · §4):
- Direct read-only DB connection from B2B service (fastest, OK for pilot)
- Read replica of B2C Postgres (recommended for pilot)
- Internal API exposed by B2C team (long-term target)
The choice determines whether the B2C team needs to ship something before B2B can integrate.
2. High priority · needed in week 1
Topics: B2C data model walkthrough, sync mechanism, dev/staging environment availability, data residency, retention policies, anomalies in current data we should know about.
Even draft language is enough to start designing against. Final approval can come later. We need legal to opine on:
- Whether email-link consent is sufficient under GDPR Art. 9
- Required identity verification before consent grants
- Consent revocation cascade (what happens to historical data)
- HIPAA applicability (US customers? EU only?)
- Data Processing Agreement template between Hilo and B2B partners
Recommendation: Azure AD B2C (already in Azure ecosystem; Entra ID provisioning). Alternative: Auth0. Either is fine. Building auth in-house is not.
Default: West Europe or North Europe for GDPR-defensible residency of EU patient data. If Hilo has US customers, multi-region considerations apply.
Single async channel for unblocking infra and data questions. Keeps decisions out of email.
3. Medium priority · needed in week 1–2
For reference on existing patterns (auth, logging, data access). Confirmed access already exists per the kickoff meeting.
Suggested: partners.hilo.com or dashboard.hilo.com. Need DNS team to
create CNAME / A record once Azure App Service is provisioned. TLS via Azure-managed cert.
For consent emails (Phase 2) and partner invitation / password reset emails. Provider TBD (SendGrid, Postmark, Azure Communication Services). Need DNS records to authenticate the sending domain.
Already received as zip files in .context/attachments/. Editor access optional (good
for visual iteration with the PM). Treat as visual reference only; build the production
codebase fresh.
For UX flows that didn't make it into the Lovable prototype. PM committed to share post-meeting.
PM committed to deliver by "tomorrow evening" (per the kickoff). Final MVP funnel + breakdown of which steps are clear vs which need definition.
4. Information requests · ongoing
| What | From whom | Why we need it |
|---|---|---|
| How does HCP-managed band sync work today? | Matti / app team | To model time-of-measurement vs time-of-sync correctly |
| BP categorization thresholds Hilo uses | Hilo product | Avoid hardcoding wrong cutoffs in schema |
| HubSpot account model for partners (record types, fields) | Konstantin | Future integration; not a blocker |
| Shopify decision (account creation in Shopify or HubSpot) | PM (after Shopify meeting) | Determines long-term integration design |
| App team roadmap / capacity for patient consent endpoint | App team lead | Determines whether patient-managed flow is achievable in Phase 2 |
| Existing audit logging or compliance infra | Hilo tech / security | Avoid duplicate work |
| Existing Hilo monitoring / observability stack | Hilo tech | So B2B dashboard plugs into the same place |
5. Suggested message to send in the team chat
A copy-paste-able version for the team Slack / Teams channel once it's set up.
Hi all — getting set up for the B2B dashboard build. Top priorities to unblock me:
1. Entra ID account on the Hilo tenant + Contributor role on the Azure subscription
(or RG) where the B2B dashboard will live. With this I can self-provision the
VM, Postgres, networking, Key Vault, monitoring without further back-and-forth.
2. Read access to the B2C database — ideally a read-only Postgres user on a
dev/staging copy. If that's not available, a schema dump + sample data is fine.
3. A 30-min call with Matti to walk through the B2C data architecture and decide
whether B2B reads via direct DB connection, read replica, or an API.
4. Hilo tech leadership decision: Azure AD B2C or Auth0 as the identity provider
for B2B dashboard logins. Either is fine; not building auth in-house.
5. Azure region for the resources (recommendation: West or North Europe for
GDPR-defensible residency of EU patient data).
Lower priority but useful in week 1: subdomain decision, email sending domain
with SPF/DKIM, the final MVP funnel from PM.
Posting full requirements + architecture + scope analysis in a docs portal —
will share the link separately.