Engineering Effort Report

This page converts the measured size of the Solara28 codebase into a human-equivalent workload, then into a salary-based cost estimate. Every number below is derived from fixed conversion rules applied to things that were actually counted in the repository — lines of code, translation words, documentation words, and file counts. Nothing here is a recorded timesheet, an invoice, or a project quote. It is a reproducible calculation, and the calculation is described in full below so it can be checked or challenged.

The headline numbers

This is the loaded, realistic figure — it accounts for the fact that most artifacts get revised, and that a paid day is never 100% heads-down production time: it includes meetings, planning, code review, support, and normal breaks. The underlying calculation starts from a smaller, purely hypothetical artifact baseline (18,207 days / 82.8 person-years — the theoretical minimum if every line were written once, correctly, with zero revision or overhead) and then loads it up to the realistic figure above; that baseline number appears later on this page only as a documented step in the calculation, not as a standalone answer, because on its own it does not represent a realistic staffing or cost scenario. How the loading was calculated, including how much of the revision assumption is now measured from this repository's own history rather than assumed outright, is explained in full below.

How the working-day count was built

The starting point was a full, excluded-and-labelled inventory of the repository: every TypeScript/TSX source file, every Supabase edge function, every SQL schema and migration file, every translation JSON file across five languages, every configuration file for Vercel/Supabase/CI, every script, and every Markdown document. Generated code (a 31,836-line auto-generated database type file), dependency lockfiles, test-result output, and node_modules were explicitly excluded — they were not authored by a person and including them would inflate the count without representing real effort.

Each category of measured content was converted to working days using one fixed rate, applied uniformly rather than tuned per role:

The exact conversion rules, applied uniformly across every role:

These rates are stated assumptions, not figures pulled from an external productivity study — no universally agreed "lines of code per day" industry benchmark exists, and this report does not claim one does. They are applied consistently across the entire codebase so the resulting comparison between roles is at least internally fair, even though the absolute rate itself is a judgment call. PLOC means physical lines of text. Translation word counts use recursive JSON string values; JSON keys are excluded.

The measured input, and exactly how each role's day total was derived:

The legacy row exists because an earlier, single-tenant version of this application was built and later superseded. Its surviving source was deduplicated by exact file hash before conversion, so files that are byte-identical across versions are only counted once. Cloud-provider runtime remains in its owning application or edge-function row; dedicated deployment configuration, Vercel API code, scripts, CI/CD, and operational tooling are assigned to Cloud/DevOps.

From artifact days to a loaded, paid-time estimate

The 18,207-day baseline only counts the act of producing the final artifact. It does not account for two things that are true of almost all real software work: artifacts get revised, and a paid working day is never spent entirely on production.

Revision. A first pass at this estimate assumed every artifact received one flat, uniform revision equal to 30% of its value — a stated assumption, not a measurement. That flat number has since been replaced, role by role, with a revision factor measured directly from this repository's own Git history, wherever the role's source files are tracked in Git. For each role, every commit touching that role's files was walked and every deleted line counted — a deleted line is a line that existed and was later removed or rewritten, the direct signature of rework. Three one-time bulk events (the original repository import and a duplicated documentation/backup detracking commit, together 84.8% of all raw historical churn) were excluded first, since they are not iterative revision. The result is a per-role ratio ranging from 12.1% to 51.4% — tests are revised least, localization and edge functions are revised most — a 4.2× spread that a single flat percentage cannot represent. Four roles (database, architecture, technical writing, and the legacy archive) keep the original 30% assumption, disclosed as still unmeasured, because their source material lives in a part of the repository that is not tracked in Git at all and therefore has no history to measure. Applying the measured ratios where they exist, and the disclosed 30% assumption where they do not, to the 18,207-day baseline (plus a smaller, separately measured backup-only content floor for material that exists in historical backups but not in the current tree) produces a focused-effort figure of 27,206 days.

Paid-time utilization. A focused-effort day is not the same as a paid day. A peer-reviewed study of 5,971 professional software developers at Microsoft, published in IEEE Transactions on Software Engineering (Meyer, Barr, Bird & Zimmermann, 2019), measured how developers actually spend a full workday. Summing that study's own reported activity categories: 45% of a typical day is development-heavy work (coding, debugging, testing, specification, review, documentation), 36% is collaboration (meetings, email, interruptions, helping others), and the remaining 16% is other necessary work and ordinary breaks. In other words, on an average day a developer spends well under half their paid time on the activity that actually produces the artifact.

Dividing the 27,206-day focused-effort figure by that 45% development-heavy share converts it into a loaded, paid-day figure: 60,462 working days, equal to 274.8 person-years at 220 paid working days per year. This is the number that is comparable to what it would actually cost to staff and pay a team to produce this body of work under normal, real-world working conditions — not just the time spent literally writing the artifact.

Turning working days into a labor cost estimate

Each role's working-day total was converted to a salary-equivalent cost using published, externally sourced 2026 salary ranges for Switzerland and Germany — national salary guides (Robert Half, jobs.ch) and, where available, official government wage data (Germany's Bundesagentur für Arbeit Entgeltatlas). The formula is simple and identical for every role:

role cost = working days × annual gross salary ÷ 220

220 is used as the number of paid working days in a year. Every figure below is a national gross base salary range — it excludes bonuses, benefits, employer social contributions, recruiting cost, equipment, and facilities, because no specific employee profiles or invoices exist to price those. Two of the German government salary-data pages cited in the underlying calculation render their figures dynamically and could not be independently re-confirmed at time of writing; every other salary source was directly and successfully re-checked against the live page.

SDLC roles, salary ranges, and per-role cost (unloaded baseline days — intermediate calculation step)

The role costs below use the unloaded 18,207-day artifact baseline, before the revision and paid-time-utilization loading described further down this page is applied — they are shown to make the per-role salary math auditable, not as a realistic cost estimate on their own. The realistic, loaded per-role cost is in the "Realistic loaded TCO" section below. Each role cost below is working days × annual gross salary / 220, using published 2026 salary-market ranges (Robert Half, jobs.ch, and where available Germany's official Bundesagentur für Arbeit Entgeltatlas). The 1,307-day technical documentation/architecture row from the table above is split here without changing its total: 342 days for architecture/API/database/production-staging/testing/governance Markdown (511,903 words), and 965 days for the remaining technical-writing Markdown (1,447,346 words).

Robert Half ranges are national 2026 25th–75th-percentile starting base salaries, excluding bonuses and benefits. Swiss jobs.ch ranges use 0–2-year and 21+-year experience averages and include bonuses/13th-month salary. German government ranges are 2025 full-time monthly quartiles, annualized. Two Entgeltatlas pages (QA/security, localization) render their figures dynamically and could not be independently re-confirmed at the time of writing — marked unverified above; every other salary source was directly re-checked against its live page and matched exactly.

Cost of the hypothetical artifact baseline (intermediate calculation step, not a realistic figure)

Before loading, the same salary ranges applied to the unloaded 18,207-day baseline produce the table below. This is not presented as a cost estimate in its own right — it is the input the realistic, loaded TCO in the next section is built from, shown here only so the full calculation is auditable end to end.

Realistic loaded TCO — 60,462-day, measured-ratio scenario

Applying the same per-role salary ranges to the loaded 60,462-day figure (rather than the 18,207-day artifact baseline) produces the labor-cost sensitivity that includes the per-role measured (or, for four roles, disclosed-assumed) revision factor and the study-derived 45% paid-time utilization factor:

Measured-ratio TCO — full breakdown

This is the most defensible loaded estimate in this document, because five of its nine revision factors are measured from the repository's own history rather than assumed. The remaining four roles (database, architecture, technical writing, legacy) still rest on the disclosed 30% assumption, for the structural reason given above — their source lives in a part of the repository this project deliberately does not track in Git.

Equivalent human headcount

A person-year is one person working for one year. Converting the realistic, loaded total (274.8 person-years — the figure that accounts for revision effort and normal paid-workday overhead) into a headcount is division, not a new estimate — and it requires a delivery-window input this page has no way to measure or verify, so no single number is presented as "the" answer. Only the realistic total is used here; the smaller, unloaded 82.8-person-year artifact-baseline figure is not, because it does not represent a realistic staffing scenario on its own (see "The headline numbers" above).

This is exact division, nothing more. This page does not contain a measurement of how large a team this specific project could actually sustain, how coordination overhead would scale for this specific codebase, or what delivery timeline is achievable — those would require a separate, explicitly scoped staffing study, not a derivation from the artifact and salary data collected here. No delivery window or headcount in the table above is asserted to be more realistic than another; the table exists only to show what the realistic total implies at a few common window lengths.

What this number is, and is not

This is a reproducible calculation from measured artifacts, not a record of actual elapsed time, an audited invoice, or a certified cost estimate. Every input line count, word count, and file count in the underlying calculation was independently measured against the repository, and the revision factor for five of nine roles is now measured from the repository's own Git history rather than assumed. The conversion rates (lines per day, words per day) remain disclosed assumptions rather than externally validated constants, as does the 30% revision factor still used for the four roles whose source material is not tracked in Git at all (database, architecture, technical writing, legacy archive). The salary figures are real, current, published national data, independently re-verified against their source pages at the time of writing, with one exception (two dynamically rendered government salary pages) noted openly above rather than silently presented as confirmed.