How we counted 20,900 tests

The home page says the systems our founding team built and runs carry more than 20,900 automated tests, 16,800 CI runs and 11,000 commits. Numbers like that are easy to inflate and hard to check from the outside, so this note shows exactly how they were produced, what they include, and what they do not prove.

What was counted

Three codebases: a production telehealth platform, a clinical-evaluation product, and the AI engineering system we use to build software. Each figure comes from the repository or its CI history, counted on 22 September 2026, and each is rounded down before it appears on the site.

How

Commits, CI runs and merged pull requests come straight from git and the GitHub API. For the telehealth platform alone:

$ git -C platform rev-list --all --count
9873
$ gh api repos/…/platform/actions/runs --jq .total_count
16723
$ gh api 'search/issues?q=repo:…/platform+is:pr+is:merged' --jq .total_count
879
$ git -C platform ls-files | grep -E 'migrations/.*\.sql$' | wc -l
2587

Tests are counted as individual test cases, not files. A small script walks every tracked test file (*.test.*, *.spec.*, test_*.py) and counts each it(…), test(…) and def test_… it finds. For the platform that is 18,878 cases in 1,619 files; across all three codebases, 20,948, published as 20,900+.

Where the count is imperfect

• Parameterised tests are not counted. The pattern looks for a test name straight after it( or test(, so a test.each([…])(…) table is missed entirely. Any such tables make the real number higher than the one we publish.
• Skipped tests still count. A test.skip is a case in the file even when it doesn't run.
• It is a static count. It says how many test cases exist in the code, not how many passed on a given day. That is what the 16,700+ CI runs are for.

Missed parameterised tables make the count too low; skipped tests make it slightly too high. Rounding down leans the published figure further toward understatement.

What the numbers do not prove

A large test count is not the same as good tests. Tests can assert the wrong thing, or the right thing about code nobody uses. What the numbers do show is a habit: in the codebase behind a production healthcare platform, changes arrive with tests, the suite runs in CI thousands of times, and the database changes through thousands of tracked migrations rather than by hand.

That habit is the thing we bring to your system. The engineering team page shows the same kind of evidence for this website: its source, its test output and its CI, live.