Skadi’s Edge
- Role
- Product design, architecture and full-stack implementation
- Timeline
- 2025 — present
- Find it at
- skadisedge.com
- Get the app
- Google Play
Skadi’s Edge gives archery coaches and the athletes they work with a shared picture of training. Athletes log sessions from their phone and get performance feedback on their shooting; coaches see the same data rolled up across their squad in a web dashboard.
Billing was the part that needed the most care. The coach platform subscribes through Stripe, while the in-app tier has to go through Play Billing and StoreKit, so the same entitlement arrives by three different routes. Stripe delivers webhooks at least once rather than exactly once, which means every handler for activation, renewal, cancellation and failed payment has to be idempotent — a replayed event must not double-charge anyone or resurrect a cancelled subscription.
It is in real use: four teams, and 75 archers with the app installed — 36 on Android, 39 on the iOS TestFlight build. Android is live on Google Play, published there in partnership with Stormpeak Performance, the coaching practice the product is built alongside; iOS is in TestFlight beta, and I am happy to add testers on request.
What was built
- Flutter client athletes use to record sessions at the shooting line and review their feedback
- Go REST API over Firestore, with Firebase Auth and one typed data model shared across mobile and web
- Svelte dashboards giving coaches squad-wide visibility
- Cloud sync keeping an athlete’s training data consistent across their devices
- GitHub Actions builds and runs the test suite on every push and produces the release images; production deploy is still a manual cutover script
- Each service in its own Docker container behind an NGINX reverse proxy, on a Linux VPS with no public ports but the proxy, and SSH restricted to key-only auth with passwords disabled
- Flutter
- Dart
- Go
- Firestore
- Firebase
- Svelte
- Stripe
- Linux / VPS
- Docker
- NGINX