One platform for every horse

The problem

A warning that says only "risk detected" gets dismissed. For a health alert to change what someone does that week, it has to explain what triggered it, how sure it is, and what to do instead.

What we did

We built a rule engine of 19 named rules across five categories: fatigue, overtraining, injury risk, health decline, and schedule compliance. It scans every morning and produces a risk score, a confidence level, and a specific recommendation with alternative actions. A public logic page documents every rule and its trigger condition.

The outcome

Alerts read as advice rather than noise, and an owner can check the reasoning behind any flag without asking support.

The problem

The analytics view, the horse-to-horse comparison, and the downloadable PDF all report on the same money and the same training volume, drawn from health logs, training logs, and expenses. If they are built separately, they drift, and the first mismatch costs the product its credibility.

What we did

We put every metric in one analytics service and made the comparison view and the PDF generator two renderers over the same calculations, including the logic that picks a leader per metric across an arbitrary set of horses.

The outcome

The dashboard, the comparison table, and the exported report always agree, and a new metric ships to all three at once.

The problem

Every owner's records are private, and the platform reads from Postgres through more than one path. Checking permissions only in the API layer would leave that guarantee resting on a single tier.

What we did

We enabled row level security across ten tables and wrote ownership-scoped policies on each, including a subquery policy for health logs that resolves ownership through the horse rather than a direct foreign key.

The outcome

Isolation holds at the database itself, so the API layer and the data layer both have to agree before a row is returned.

The problem

Every prospective user already had a system: a spreadsheet with years of expenses in it. Asking them to retype it is where adoption dies, and refusing to give it back is why people distrust a new tool.

What we did

We built CSV import for bulk expense history and CSV export for everything the platform holds, with the same category structure on both sides, so the accountant's workflow survives the move.

The outcome

New users can start from their existing records on day one, and nobody has to feel locked in to keep using the product.