Goable
A B2B API that turns weather and physical data into a score from 0 to 100: for that activity, in that place, at that time, can you go or not.
Goable takes weather forecasts, ocean and atmospheric data and answers a single question: is it worth going? The result is a score from 0 to 100 with a verdict and a readable explanation, for water, snow, air and land sports. You integrate it through a REST API, the TypeScript and Python SDKs or the OpenAPI spec.
- My role
- Founder and sole developer: product, front end, back end, AI and infrastructure.
- Who it is for
- Booking platforms, schools and outdoor operators who decide every day whether a session goes ahead, and developers who want that decision inside their own software.
The problem
Forecasts give you numbers: wind at 18 knots, a wave of one metre twenty, tide rising. They don't tell you whether you can go. Every sport has different thresholds, which change with the place and the level of the person, and people who work outdoors interpret them by hand every day. There was no service giving that answer to software, for several sports at once and in an explainable way.
How I built it
I designed and wrote Goable on my own, from the scoring engine to the customer console, from the AWS infrastructure to the website with demos that call the real API.
At its core is a scoring engine in TypeScript. The physics is made of pure functions, with no network and no state: wind, waves, tides, snow, lightning, air quality. Every formula comes from the scientific literature and is tested on its own, in milliseconds. On top of the physics sits a probabilistic layer that accounts for forecast uncertainty and blends several data sources.
AI has a precise role. A language model writes the explanation of the score for the person reading it, but it doesn't decide the verdict. Safety rules, such as lightning risk or hazardous air, sit above the engine and apply whatever the score.
The API contract comes from the schema: validation, OpenAPI documentation and SDKs come from the same source and cannot drift apart. The product runs on AWS, with the infrastructure described in Terraform and deploys from GitHub Actions, and the learning loop (drift checks, retraining, engine backtests) runs on scheduled jobs that kick in as real data comes in.
Technical choices
Physics as pure functions
Every physics module is maths without I/O: same input, same result. It is tested in isolation and anyone who knows the domain can check every formula, because each one cites its source.
The LLM explains, it doesn't decide
The language model writes the explanation for a person. The verdict comes from the engine, and the safety rules on lightning and air quality return "unsafe" whatever the score.
Schema before code
Validation, OpenAPI documentation and SDKs come from the same schema. The client a developer uses cannot say something different from what the API actually does.
Learning under control
A drift check every day, retraining every night and a backtest every week, which measures how often the engine would have said go on a day to stay ashore. They are already scheduled and work as real data comes in. Catalogue changes computed from the data arrive as a proposal to review, never as a direct change.
Infrastructure as code
AWS described in Terraform: a serverless API behind a CDN, queues for asynchronous work, Postgres with PostGIS and point-in-time recovery. Console and website on Vercel.
You can see when something breaks
Structured logs, alarms on errors, queues and scheduled jobs, and a public status page with uptime monitors.
In numbers
Counted on the product's source code.
- 9apps in the monorepo: API, console, website, worker and five scheduled data ingests
- 25shared packages
- 20physics modules, pure functions with no I/O
- 6Python packages for climate data and calibration
- 16scheduled jobs: 11 on GitHub Actions, 5 on AWS
- 496test files: 431 TypeScript, 65 Python
- 2public SDKs: TypeScript on npm, Python on PyPI
- 4families of sports: water, snow, air and land
Stack
- TypeScript
- Node.js
- Hono
- Zod
- OpenAPI
- PostgreSQL
- PostGIS
- Drizzle
- DynamoDB
- Python
- Anthropic Claude
- Next.js
- AWS Lambda
- Amazon SQS
- CloudFront
- Terraform
- GitHub Actions
- Vercel
- Better Stack
- Stripe
- Turborepo
- Vitest
- Playwright
