Loading…
👥 My clients
Loading…
🥕 Ingredients
Loading…
💪 Exercise library
Loading…
💊 Supplement catalogue
Loading…
💼 Packages
What you sell. Each package carries what the client gets, how long it runs, and the price - so raising an invoice becomes one choice instead of retyping the same terms every month.
Loading…
🎟 Offers
A code that lowers what a client pays you. Give it a limit and an end date, and it stops working on its own - you are not relying on remembering to switch it off.
Loading…
💼 Packages & sales
Every provider's offering and what it actually earned. Sales are counted from issued invoices, so a package with a price and no revenue is a package nobody bought - which is the useful thing to know.
Loading…
🎟 Platform offers
Codes against the platform fee - what a provider owes Bond. These are a separate table from a provider's own codes, so a provider can never mint one against their own subscription.
Loading…
🧱 Components
Every shared piece of UI in Bond, and the ONE function that builds it. Each preview below is rendered by calling the real component, so this page cannot drift from the app. Check here before building anything - if it is on this list, use it; if it is not, add it here when you build it.
Loading…
🎯 Goals
What members say they are here for. Anything a member types instead of picking arrives as a submission; adding it puts it on the global list, which is what the picker offers everyone.
Loading…
🧩 Templates
Loading…
📋 Surveys
Loading…
🍳 Recipe catalogue
Loading…
📈 Progress logs
Loading…
Loading…
Loading…
🎯 Client targets
These are your reference points - Bond never sets them. Each client’s Progress widgets draw their goals and healthy bands from the numbers you enter here, so what a gauge calls “on target” is your professional judgement, not the app’s. Leave a field blank to hide that target. These are your practice-wide defaults; you can override them per client from that client’s Meal plan ▸ 🎯 Daily target, and the client’s own value always wins.
Loading…
🍽 Macro splits
Loading…
🎛 Preferences
These apply to this browser only.
🥗 Dietitians
Bond is a marketplace, not a licensing body. Practitioners declare their type and open immediately - there is no approval step. The safeguard is disclosure: their declared credentials are shown to the client, who must accept - before engaging - that Bond hasn’t verified them (and granting “dietitian” unlocks medical notes, so that acceptance carries real weight). This is the directory of those declarations; open anyone to read what they claimed. Your role here is an identity / abuse watch - a real person, not someone farming records - not credential vetting.
Loading…
📝 Words they had to type
Practitioner vocabulary only - member goals have their own screen under Library ▸ 🎯 Goals.
Every picker ends in “Other”. What people type there lands here. Approve it and it becomes an option for everyone - the lists improve by being used instead of decaying into “AUB”, “A.U.B.” and “American Univ Beirut”.
Loading…
👤 Users & logins
Loading…
🏋️ Coaches
Approved providers who hold the coach qualification. A dual-qualified provider also appears under 🥗 Dietitians. Approvals and the credential queue live on the Dietitians tab, where the verified type is assigned.
Loading…
🧩 Profiles & authority
Each profile is a template of what its users may see and do - a section × function grid. Assigned to accounts by type (Dietitian→Dietitians, etc.); you can reassign per user on the Users tab. Deactivating a profile blocks everyone assigned to it. A profile governs the UI only - data access is always enforced by the server.
Loading…
🔗 Role mapping
For each account type, choose the profile new accounts of that type inherit when they're created. Only profiles of the matching category are offered. This is the one place the profile ↔ type relationship is set - the authority screen stays focused on grants.
Loading…
Loading…
Loading…
Loading…
Loading…
Loading…
Loading…
Loading…
Loading…
Loading…
Loading…
Loading…
🎨 Brand guide
🖼 Design spec
The agreed clickable prototype - the canonical design, every screen numbered (S01–S92), Web and App side by side, with the journey selector. This is the single home for what we agree; reference a screen by its number and we cross-check it here against the developed & live version.
🗄 Data structure & architecture
How Bond stores and protects data - the request path, the store, and the data model (every table, its tenancy scope and scope keys), read live from the registry so it never drifts from what the kernel enforces. For review; nothing here is editable.
🗺 Appflow map
Every screen and the control that reaches it - redrawn from the source on every build.
✅ Requirements Status
Bond mapped to ISO/IEC/IEEE 12207 (software life-cycle), with an honest Done / Partial / Not-started status per item. Updated on every completion.
🗺 Development Plan
Loading…