How the thirty-eight was arrived at.
The sizing section publishes four numbers and this page publishes the working behind them: what the count does and does not include, why rework is added back, where the model breaks, how the organisation around it was constructed, and what the ratio is not. Read it before quoting any of it.
Counting what survived undercounts the work
A line count only sees the code still standing. If a screen was built, rebuilt and rebuilt again, it sees one screen and charges for one screen, and the two rewrites vanish. Rework is the most ordinary thing in software and the crudest way to measure a codebase is blind to all of it.
The history is not blind to it. Across 1,190 commits the repository added 252,828 lines and deleted 50,683, against 155,298 still in place. A quarter of the surviving codebase was written a second time.
COCOMO has a parameter for precisely this, REVL, which inflates the size to cover discarded work. Measured at 25% it takes the effective size to 194,100 lines, and the estimate from 755 person months to 965. That is the difference between thirty-two engineers and thirty-eight, and the thirty-eight is the honest one.
The same history says the work was lumpier than five months implies. Code was committed on 86 separate days, 74% of the working days in the window and 22 of them weekends, but there is a 32 day stretch across May and June with no code at all. Eighty-six is the number to argue with, because it is the only figure on this page that is a fact about the repository rather than the output of a model.
A line is not a line
Adding every language together and treating the total as one number is the crude method, and it is worth saying so out loud. A line of SwiftUI that lays out a button is not a line of SQL that defines a security policy, and neither is a line of PyTorch. Counting them as equal is a convenience, not a measurement.
The proper correction is function points: convert each language to a common unit using its own gearing ratio, then estimate from that. It is better, and it is also why the figure here is a band rather than a point. Published gearing tables disagree with each other by enough that quoting one to three significant figures would be false precision.
So the figure is a band. Drop the markup and count only the programming languages and the model asks for thirty-five; count everything and it asks for thirty-eight. The direction of the error that remains is genuinely unknown, because the same count holds both the most repetitive code in the repository and the least.
What the model cannot see
COCOMO II was calibrated on projects delivered before there was an agent in the room. Read thirty-eight as what this scope used to cost, not what it ought to cost now.
Its exponent is greater than one on purpose: it charges a project more per line as it gets bigger, because coordination gets more expensive as the team grows. That penalty is a team-size effect, and a team of one does not pay it. The model structurally cannot price the thing that actually happened here.
It also runs at nominal, with all seventeen effort multipliers set to one. Turning up the ones for tooling and for the team's familiarity with the domain would pull the estimate down; turning up required reliability and complexity would push it back up. Nominal is the defensible default, not the flattering one.
Thirty-eight of whom, exactly?
The model returns undifferentiated technical effort. It assumes thirty-eight interchangeable engineers who can each do all of it. Nobody has that team, and the shares below show why: split strictly by line count, machine learning is a tenth of a person. You cannot hire a tenth of a machine learning engineer. Every specialism rounds up to one, which is the first place the real team gets bigger than the model's.
Swift and SwiftUI across twenty build targets: the Sailor app, the Race Officer app, a watch app and widgets for both.
Kotlin and Jetpack Compose, two apps again. A different language, a different toolchain and a different store review process, for the same product.
React and TypeScript across three separate applications, the ops dashboard, the admin tool and the community site, plus a marketing site published in twenty-two locales.
Postgres with row level security and a test role that physically cannot read production data, 125 migrations, 33 serverless and edge functions.
Clubs take entry fees, the platform handles refunds and payouts. Normally its own specialist, because this is the part where being wrong costs money rather than uptime.
A PyTorch training, evaluation and export pipeline producing a Core ML model that runs on the device. The smallest directory in the repository and the least substitutable skill in it.
NMEA 0183, NMEA 2000, SignalK and Bluetooth LE. Talking to instruments on a boat is not web engineering, and hiring for it is not web hiring.
XCUITest, Espresso, Maestro and a backend driver, benchmarked against each other. A localisation drift gate that blocks the build. Xcode Cloud, four auto-deploying sites and a nightly database backup.
And that is only the people who write code
COCOMO prices building the software. It does not price the organisation that a corporate programme puts around building software. Assume delivery teams of eight, which makes thirty-eight engineers into five teams, and staff it the way a programme of that size is normally staffed.
Per team, times five
A product owner to hold the backlog, a delivery lead to run the ceremonies, and a test lead, because five teams shipping to two app stores and a web platform do not share one release train by accident.
Fifteen people.
Across the programme
A programme manager, a solution architect, two business analysts, a release manager, two in operations, one in security, two in design and one running twenty-two locales.
Eleven people.
Twenty-six people who never commit, on top of thirty-eight who do. Sixty-four people, for about two years, to arrive at what is on the App Store today.
What sixty-four people cost, and what one did
Salaries from published 2026 UK guides, a blended engineer at £65,000, and a fully loaded multiplier of 1.4, which is the middle of the 35% to 45% that UK sources put the true cost of an employee above their headline salary. Employer National Insurance is 15% on everything above £5,000 a year, auto enrolment pension adds 3%, and recruitment, equipment, premises and management time make up the rest.
The comparison is only worth anything if both sides are costed the same way, so the solo column is not a day rate. It is one senior developer on a payroll at £70,000, loaded at the same 1.4, pro rata across the 86 days, plus the Claude Max subscription that did the rest. The subscription is £480 of it. That is 1.3%, and it is the entire tooling bill.
Where the numbers come from
Engineer, architect, analyst and delivery salaries are the midpoints of the 2026 UK guides: Indeed, PayScale, Morgan McKinley and the Adria Solutions guide. They disagree with each other, which is why the answer is a band.
The 15% employer National Insurance rate and the £5,000 secondary threshold are HMRC's published 2026 to 2027 figures. The 1.25 to 1.5 loading range is the standard fully loaded cost calculation.
The senior developer salary is the midpoint of the 2026 guides, which run from about £60,000 to £85,000 depending on who you ask and where you are: Indeed and PayScale for the senior figure. The subscription is the Max 5x plan at the published price, held for the six calendar months the work spans rather than pro rata, because that is how you would actually pay for it.
227 working days is 260 weekdays less twenty-five days of holiday and eight bank holidays. £103,200 is a price rather than a cost and is not a quote for anything.
What that ratio is not
Three hundred and twenty-two times is arithmetic, not an argument, and anybody buying software should refuse to read it as one. It is the most fragile number on the page, because a small denominator swings hard: the honest version is somewhere between two hundred and sixty and three hundred and seventy-five.
It also charges the solo build for 86 days and the programme for every one of its twenty-five months, and real employers pay people whether or not they commit that day. Pay the developer for the whole window instead, all 163 days of it, and it is 274 times. That is the number to use if you want the conservative one.
Twelve million pounds buys things a solo build does not have, starting with the obvious one: sixty-four people means somebody answers the phone when the person who wrote the sync engine is on holiday, or ill, or gone.
It also buys a support function, a governance trail, a security specialist whose actual job that is, and a bus factor above one. This build has none of those, and if you are considering work like it, that risk is real and you should price it rather than take my word that it is fine.
So the honest reading is narrower and more useful than any single multiple. The build cost and the organisation cost are separable, the organisation is the larger of the two, and the half that writes the code is now the cheap half.
Every number in that org chart and that cost is an assumption, and they are written down above so you can change them. Halve the overhead and it is still fifty-one people. Take the cost band at its lowest and it is still nine point eight million. The exact figures are not the point.
The point is which half the model can see. The work it measures, writing the lines, is precisely the work that has got dramatically faster. The work it leaves out, the twenty-six people, exists because there are sixty-four people. Take the people away and most of the coordination goes with them, which is why eighty-six days and twenty-five months are not the same task done at different speeds. They are different tasks.
Counted with a script over the tracked files in the repository, by extension, excluding build output, dependencies, Xcode project files and the machine-translated locale copies of the website, then stripping blank lines and comment-only lines. Tests are counted, because writing them was work. Rework is measured from the git history with the same filter applied to every commit. The staffing and cost models are constructions from the assumptions and sources stated above, not a quote and not a citation. Run the same script next month and the number will have moved.