Running a sailing race takes a stopwatch, a clipboard and a spreadsheet.This replaces all three, on every screen involved.
The Sailor app is live on the App Store in 22 languages. Behind it sit a Race Officer app, a watchOS app, an Android build in progress, a web platform, payments, a verified scoring engine and a marine instrument stack still in testing.
Live on the App Store · Android in progress · marine instruments in testing
A race, from entry fee to published result.
Sailing clubs run races on a Sunday morning with a stopwatch, a clipboard and a spreadsheet somebody rebuilt from memory. Flying Start is the whole of that job as software: the competitor entering and paying, the race officer running the start sequence, the scoring afterwards, and the results going out.
Two audiences, so two apps. The Sailor app is on the boat with the competitor, counting down to the gun and tracking the race. The Race Officer app is on the committee boat with the person firing it. Behind both is a web platform for the club, a backend, and the unglamorous half nobody quotes for.
Eight things to build, and their real state.
One person, so the honest version of this is a list with a status on every line rather than a screenshot of the finished one.
iOS, free, in 22 languages, with live widgets and Dynamic Island. Released May 2026 and updated since.
The countdown on the wrist, which is where a sailor actually looks in the last minute before a start.
iOS. Start sequences, recalls, abandonments and check-ins from the committee boat. Deliberately less than the web admin: race day functionality without the clutter.
Both apps. The sailor build works and is being brought to parity with iOS; the list of what is still different is written down rather than glossed.
Club admin, the public event hub, live tracking during a race, and the results afterwards. Stripe Connect handles entry fees, refunds and payouts to the club.
FAQs, feedback, product ideas and the public roadmap. See below, because this one is the interesting line item.
Resource usage, website clicks, app downloads and what the backend is doing, behind a login. Also below: it is the reason the site needs no cookie banner.
Reads wind, speed and depth off the boat's own instruments: NMEA 0183, NMEA 2000, SignalK, Bluetooth LE and WiFi transports, with device discovery. Written and under test, not shipped.
Two of these would normally be a subscription.
The parts of a product that are not the product. Most teams rent them, and then discover what renting them costs in money, in consent banners, and in where the data lives.
The community site
Feature requests, voting, FAQs, a public roadmap, and somewhere for users to say what is wrong. This is what Canny and Nolt sell, at around eighty dollars a month for the tier that does what a small product actually needs.
It is built in and self hosted instead. The same feature set, running on infrastructure that was already paid for, on the product's own domain, so a user never leaves it to file an idea and the roadmap is not on somebody else's marketing page.
The ops dashboard
Resource usage, website clicks, app downloads, and what the backend is doing. Built in the same way, on the same infrastructure, gated behind a login because it is an internal tool and not a marketing exhibit.
The consequence is the part worth noticing. Because the analytics are first party and self hosted, there is no third-party tracker on the site, and therefore no cookie banner. The compliance problem was not solved. It was declined.
This is the argument for working this way, in one line. Building the thing you would otherwise rent used to be the expensive option, and for two supporting products on a solo build it no longer is.
The parts that decide whether it survives.
Languages on the App Store, held by a translation drift gate that blocks the build when the key sets diverge. It is the one automated check that can stop a release, and it stops one regularly.
Comparisons behind the scoring engine, against results published by 99 clubs in ten countries, with the method and data public. The verification.
Test engines built and benchmarked against each other rather than picked: a backend driver, Maestro, and the native pair, XCUITest and Espresso, on simulators, emulators and a physical handset.
App Store rejections before the Sailor app went live. Both were about understanding the review process rather than the code, and both are in the talk.
There is also an on-device Core ML model with its own PyTorch training and export pipeline, a Postgres backend with row-level security and a test role that physically cannot see production data, and a continuous deployment pipeline for the web and Xcode Cloud for the apps.
None of that is interesting to a sailor. All of it is the difference between a demo and something a club will trust with its season.
The test harness benchmark found a real bug in the Race Officer Android build while proving itself: the app vibrated during the start sequence without declaring permission to, so the gun threw an exception and killed the race. It was found by running the same journey through a second engine, which is the entire argument for having more than one.
Thirty-eight people, or one.
The honest way to answer "how big is this" is to count it, name the model you push the count through, and publish both so somebody can disagree with you properly.
Lines of code still standing, counted logically: blank lines and comments removed, across 982 files. Generated output, dependencies, Xcode project files and the machine-translated copies of the website are all excluded from the count.
git ls-files, 24 Aug 2026Languages in one system: Swift, Kotlin, TypeScript, SQL, Python, JavaScript, HTML, CSS and shell. SwiftUI and Jetpack Compose at the front, Postgres and 125 migrations behind, 33 serverless functions between them, PyTorch to train a model that then runs on the phone, and a protocol stack that speaks NMEA and Bluetooth LE to the instruments on a boat.
Person months is what COCOMO II, the standard software estimating model, returns once the code that was written and then thrown away is added back, alongside a twenty-five month schedule. Divide one by the other and it is asking for about thirty-eight engineers.
COCOMO II nominal, 194.1 KSLOC after REVLDays on which code was committed, by one person, across 1,190 commits between 15 March and 24 August 2026. Not twenty-five months, and not thirty-eight people.
unique commit dates touching codeThe model is COCOMO II at nominal, run over the logical line count with the exclusions published rather than assumed. Rework is added back with COCOMO's own REVL parameter, measured from the git history at 25%, which takes the effective size to 194,100 lines and the estimate to 965 person months across twenty-five months. Both sides of the cost below are then costed the same way: fully loaded salary, not a day rate.
Sixty-four people, fully loaded, across the twenty-five months. Move the engineer blend between £55,000 and £75,000 and the loading between 1.25 and 1.5, and the band is £9.8m to £14.2m.
£4.14m salary bill a year, 1.4x loadedOne developer, costed identically. £70,000 loaded to £98,000, which is £432 of an employer's money a day across 227 working days, times the 86 days code was committed on, plus £480 of subscription.
86 days x £432, plus Claude Max 5xThe gap, between 266 and 375 as the salary moves from £85,000 to £60,000. It is the least interesting number here, and the method page explains why.
£12.1m over £37,608What buying it costs, as opposed to what building it costs: the same 86 days at the rate on the prices page. It sits between the two because a price is not a cost.
86 days x £1,200Every one of those figures is a model output with assumptions bolted on, and the assumptions, the exclusions, the staffing construction and the salary sources are all published in full, along with what the ratio is not. Read them before quoting the ratio.
Scope that used to need a team.
iOS, watchOS, Android, web, a payments integration, a hardware protocol stack, an on-device model, twenty-two locales and the CI to hold it together. Built solo, over months rather than years, with the half-finished parts labelled as half-finished.
If your team's reaction to that is suspicion, that is the correct reaction, and it is why the verification and the review panel are published in full rather than summarised. The work is checkable or it is marketing.