August 20, 2026 · 15 min read

Sahha Demo App: How to Run a Real Evaluation With Your Own Team

See real Sahha output from your own team's phones, with no developer needed to start. How to get access, what to expect week by week, how to brief your testers, and how to finish the evaluation with a working pipeline.

What this is

The Sahha Demo App lets your team see real Sahha output from their own phones and wearables, with no SDK, no mobile build, and no app store submission. Install it, carry your phone normally, and scores, biomarkers and archetypes start appearing, drawn from the phone and from any wearable already connected to Apple Health or Health Connect.

It runs on your own Sahha account, so everything your testers generate is your data, in your dashboard. That means the evaluation runs at two depths, and the first one starts today.

Start with the output. No developer needed and nothing to configure. Install the app, add a few colleagues, and watch real profiles fill up in the Sahha dashboard. Most teams have their answer inside the first week, because this settles the question that decides everything after it: is the data good enough, and is there enough of it?

Then prove the pipeline. One endpoint is enough. Point a webhook at it and your developers can query the API while the testers are still walking around, so you finish the evaluation having run Sahha against your own stack rather than having watched a demo. Most teams do this in week two, once the data has earned it.

Judge the app on the data, not the design. It is a plain testing tool, not a product we sell or a template we ship. Your product already has its own look. Sahha sits underneath it, so what you ship looks like you rather than like this.

Getting access

Access is not self-serve. To get your team onto the demo app:

  1. Book a call with the Sahha team. We walk you through what the app does, what to look for, and how it maps to what you are trying to build.
  2. Send us the email addresses of everyone on your team who will be testing.
  3. Tell us which device each person is on (iOS or Android), so we can add them to the right distribution list.
  4. Accept the invite and install. iOS testers receive a TestFlight invitation. Android testers are added to Google Play internal testing.
  5. Grant health permissions on first launch. On iOS this is Apple Health. On Android this is Health Connect.

We usually have your build ready within two business days of receiving your tester list. Getting it onto phones after that depends on Apple TestFlight and Google Play review, which normally clears quickly but is not on our clock.


What you can do with it

See the data flow end to end. Phone and wearable data goes in, standardised Sahha output comes out. You can watch the same data appear in the app, in your Sahha dashboard, and on your own webhook endpoint.

See Sahha’s products rendered for an end user. The app surfaces the core Sahha outputs in a user-facing way:

  • Scores (0 to 1): Activity, Sleep, Readiness, Wellbeing, Mental Wellbeing, each with the contributing factors behind it
  • Biomarkers: 100+ standardised signals across activity, sleep, vitals, body, nutrition, and engagement
  • Archetypes: human-readable behavioural labels such as Night Owl, Short Sleeper, Highly Active
  • Tags: time-bound labels for events and states, captured by the SDK or pushed in from your own backend
  • Insights: trends and comparisons against the user’s own baseline and against the wider population

See concepts that can be built on top of Sahha data. The app includes sketches of things our customers commonly build. Today that means challenges, personalised product recommendations, and bookings, each driven by the user’s actual Sahha data. These are illustrative, and the set changes as we iterate. They exist to show the data is rich enough to drive real product logic, not to be shipped as-is.

See wearable data flowing without connecting anything. If a tester’s Garmin, Oura, WHOOP, Fitbit or Apple Watch already writes to Apple Health or Health Connect, the SDK is reading it today and scoring it alongside phone signal. That is how Sahha reaches 800+ devices across 165 integrations, and it is why the app has no connect buttons: you are seeing what Sahha returns for your whole user base, not just the part of it that owns a wearable. Direct provider-cloud connections are coming, and they add a second route to the same scores rather than unlocking anything missing today.

Watch it arrive in your own dashboard. Because the app is tied to your account, anyone on your team can log in and see test profiles populate, browse scores and biomarkers per person, and confirm data is landing. This needs no developer and no setup.

Then move it into your own systems. Configure webhooks and start pushing data to your warehouse, CRM, or app backend. Nothing blocks on this, so it can wait until the data has convinced you, but the teams that finish an evaluation with a working pipeline are the ones that go live fastest.


What it cannot do

  • It is not brandable or configurable. You cannot change the look, the copy, the screens, or which metrics are shown.
  • It is not a sandbox for your own logic. The challenges, recommendations, and bookings are fixed examples. They are not editable and not connected to any real inventory, catalogue, or booking system.
  • It is not production software. It is not intended for real users, and it should not be given to anyone outside your evaluation team.
  • It does not cover every Sahha capability. Sahha exposes considerably more through the API than the demo app chooses to display. If something you care about is missing from the app, ask us. It very likely exists in the data.
  • It has no direct wearable connect buttons yet. Testers connect wearables to Apple Health or Health Connect as they normally would, and Sahha reads them from there. Direct provider-cloud authorisation is coming to the app.

What to expect once you install

The evaluation is a sequence, and knowing which part you are in stops people judging it too early.

WhenWhat appearsWhat to watch for
Day oneRoughly 14 days of retroactive scores and archetypes, drawn from health data already on the tester’s phoneNobody hits an empty screen. There is something to look at from the first launch
Within minutesFresh biomarkers and score updates, typically under a minute after the phone syncsConfirms the pipeline is live rather than batched overnight
First weekDaily scores and biomarkersThe main thing to watch. Push testers to wear their device to bed, since sleep drives several scores
Weeks two to fourWeekly and monthly archetypes, and longer-range insightsWhere it gets genuinely interesting. These need history, so this is the part an early cancellation costs you

A realistic tester profile matters. A phone that sits on a desk all day will produce a thin picture. The demo is most convincing when testers carry their phone normally and, ideally, wear a watch or ring.

If data looks missing, late, or wrong, check the End User FAQ before raising it. It covers the common cases directly: blank screens and no scores yet, last night’s sleep not showing, step or calorie counts that don’t match Apple Health or the wearable’s own app, a connected watch not being reflected, sync that worked yesterday and stopped today, background sync fixes, and a fast checklist for missing data. Most of what testers report turns out to be one of these.


How it connects to your Sahha account

WhereWhat your team can do
Sahha DashboardSee test profiles appear, browse scores, biomarkers, and archetypes per profile, and confirm data is arriving
WebhooksPoint an HTTPS endpoint at Sahha and receive events as they happen: scores, biomarkers, archetypes, tags, and raw data logs. Score and biomarker delivery can be batched on an interval from 1 to 720 minutes, or left real-time. Tags and data logs are always delivered immediately
APIQuery the same data directly for anything your developers want to prototype

The dashboard row needs nothing from anyone. The two below it are there the moment a developer wants them, which is what makes this an evaluation of the platform rather than a look at an app.

To build against it, your developers start at the Quickstart. The Developer FAQ is the one to keep open alongside it, because it answers the questions that come up first in an evaluation: how often Sahha uploads and delivers data, how long scores and biomarkers take to update after new data arrives, what to check when scores or biomarkers aren’t showing, and why data can appear in the dashboard but not yet in the API or webhooks.


Briefing your testers

Your testers are not evaluating Sahha. They are generating data. The most common way a demo goes wrong is a tester who thinks they are reviewing an app, judges it on how it looks, and leaves it closed on their home screen for two weeks.

Make sure everyone you invite knows four things:

  1. This is a data test, not a product review. The app is deliberately plain. Nobody needs to give feedback on the design.
  2. Their job is to carry their phone normally. No special behaviour, no step targets, no pretending. The point is to see what real data looks like.
  3. Wear your device to bed if you have one. Sleep drives several of the scores, and a missing night leaves visible gaps.
  4. Keep it installed for the full period. The interesting patterns need history. Uninstalling after three days wastes the exercise.

Copy and paste this to your testers

Hi, we’re looking at whether we can use a health data platform called Sahha for what we’re building, and I need a few people generating real data so we can see what it actually looks like. Taking part is completely optional and it is genuinely fine to say no, so just let me know either way, and if you’re in, whether you’re on iPhone or Android.

You’ll get a link to install a demo app on your phone (TestFlight for iPhone, Google Play for Android). It reads health data your phone already collects, plus your watch or ring if you have one, and shows you what it makes of it.

What it involves:

  • Where the data goes. Into our own company Sahha account, not to a third party. You can revoke the app’s health permissions any time, or tell me to remove your profile.
  • Just carry on as normal. No changed routines and no chasing step counts, since unrealistic data tells us nothing.
  • Wear your watch or ring to bed if you have one. Sleep is a big part of what we are assessing.
  • Stay installed for [X weeks]. This is the part that matters most, because the patterns we care about take a couple of weeks to build up.
  • Ignore how it looks. It is a plain internal testing tool, not a product and not what we would build, so no design feedback needed.

If your data looks missing, late or wrong, Sahha’s End User FAQ covers most of it: https://sahha.ai/faq/end-user/. Blank screens, sleep not showing, step counts that don’t match your watch, background sync. Anything it doesn’t solve, send it to me.

Fill in [X weeks] with your evaluation window. Two to four weeks is the range where weekly and monthly archetypes become meaningful.

Testers are sharing personal health data. Make participation genuinely optional, tell people where the data goes, and give them a straightforward way to opt out or be removed. Whatever your organisation’s normal process is for internal testing that involves personal data, apply it here.

The privacy section of the End User FAQ answers the questions testers actually ask: what is collected, how to revoke access, what happens to data after permissions are removed, and whether anything is shared with third parties. It is worth sending alongside the invite.


FAQ

Why does the app look basic, and will my app look like this? No, and only if you want it to. The demo app is an internal testing tool, not a product we sell or a template we ship. It is one arbitrary way of rendering the data, chosen to be readable rather than beautiful, and most customers build something completely different. Sahha’s product is the data layer: the API, the scores, the biomarkers, the archetypes, and the infrastructure that keeps them accurate across 800+ devices. The interface is entirely yours, and Sahha sits underneath whatever you already planned to build.

Can we customise the demo app for our brand before showing it to stakeholders? No. If you need a branded proof of concept, that is a separate conversation and typically means a light SDK integration into a build of your own. Talk to us about it.

Is my data safe? Where does it go? Data from the demo app flows into your own Sahha account under your organisation. It is your data. For legal, IT or procurement review, the Security & Compliance FAQ covers hosting location, encryption in transit and at rest, de-identification, retention and deletion, sub-processors, penetration testing, and SOC 2, HIPAA and GDPR status. The policies themselves are the Privacy Policy, the End User Privacy Policy, and the Terms of Use.

Do testers need a wearable? No. All five scores compute from phone data alone, though some factors are missing without a wearable, particularly for sleep and readiness. A mixed group of testers with and without one is the best way to see that difference for yourself. Sahha supports 800+ devices across 165 integrations; see the integrations list.

A tester’s data isn’t syncing. Who fixes it? Start with the End User FAQ, which has a troubleshooting checklist and covers the usual causes: permissions granted but not taking effect, background sync disabled, a wearable connected to its own app but not to Apple Health or Health Connect, and sync that stops after working fine. If your developers are chasing a pipeline issue rather than a device one, the Developer FAQ is the right place. Anything still unresolved goes to support@sahha.ai.

How many people should we put on it? Three to five testers is the practical minimum. That is enough to see variety in the data and to give your developers a realistic webhook stream. A mix of iOS and Android, and a mix of people with and without wearables, gives the fullest picture.

Can we evaluate another platform at the same time? Yes, and it is the fairest way to do it. Put the same testers on both, over the same period, and compare what comes back for the same people on the same days. The comparison that decides most of these is not the feature list, it is how many of your users each platform can actually return data for, and how much of that survives a week of ordinary life.

Can we give this to our customers or end users? No. The demo app is for internal evaluation only. It is not built, supported, or licensed for end users.

Something in the app is broken or looks wrong. Email support@sahha.ai. Bugs in the demo app are bugs in the demo app, not in the Sahha platform, but we want to know either way.

We are ready to build. What is next? The SDK integration is the next step: iOS, Android, React Native, Expo, Flutter, or Ionic/Capacitor, depending on your stack. Your developers can work through the Quickstart while the demo app is still on your team’s phones, and reach the team at support@sahha.ai with questions.


Who to send what

Most of an evaluation is forwarding the right thing to the right person.

Send toLink
Your testersEnd User FAQ when data looks missing, late or wrong. It solves most of what they will report
Your engineersQuickstart to build against, with the Developer FAQ open alongside it
The stakeholders you report toA case study showing what someone built on this, the Product FAQ for the questions that follow, and the roadmap when procurement asks what is coming
Legal, IT and procurementThe documents: Privacy Policy, End User Privacy Policy, Terms of Use. The Security & Compliance FAQ covers hosting, encryption, retention, sub-processors and certifications

Anything those do not answer, email support@sahha.ai.


The Sahha Demo App is a testing and demonstration tool provided for evaluation purposes only. It is not a commercial product, does not represent the capabilities or appearance of software built with Sahha, and is not intended for use by end users.

Related