Why now
The man-day is no longer a unit of value. It is a unit of billing.
The cost of delivering software has changed order of magnitude. If your IT budget has not moved, you are no longer buying software — you are buying presence time.
We sell days. Not man-days.
The mechanism, in three steps
1. The unit of purchase is the man-day. A supplier whose methods make them three times faster does not earn three times more: they bill three times less. The productivity gain is a revenue loss for the one who produces it. The market rewards slowness.
2. Procurement frameworks are designed to reduce supplier risk. They do that well — but they can make new production models harder to evaluate. A volume discount is won once, at signature; afterwards the rates do not come down, for lack of a referenced alternative.
3. The referencing criteria describe stability, not novelty. Turnover thresholds, years in business, financial ratios, certifications: these filters are well suited to assessing established structures. A new production model, by construction, does not present them.
The third point blames no one: it describes a filter that produces this result even when everyone is doing their job correctly.
Where we speak from
Middleware Factory sold day-rate consulting and supported seventeen people in 2017-2018. The market hardened, and the team shrank to four. The one announcing the end of the man-day held the other end of the model for fifteen years — this is not a new entrant throwing stones at a market they never had access to.
The lesson is structural, and it can be stated without naming anyone: the value of a services company lives in people, and people can leave — resignation, retirement, competition, illness. That is what the capacity we now sell corrects: machines, models, a versioned method and a small team trained on it — a production capacity that cannot be poached.
One measured case
Start with the strongest objection, because it is founded: this was built on our own platform, fifteen years in the making. The platform is part of what is sold. Three months for a business application on that platform is the promise made to the next client.
What was delivered — measured
A model-driven, reactive, multi-user invoicing application, with data separated per organisation. In scope: organisations, clients and addresses; products and taxes; invoices, lines, payments and financial metrics; the draft → issued → PDF cycle; credit notes derived from an issued invoice; users, roles and rights; a multilingual interface; Factur-X export (PDF/A-3 B + XML CII EN 16931). Out of scope, in the same sentence: bank reconciliation, accounting software export, reminders, recurring billing, multi-currency, and deposit to a platform.
2026-05-21 — first commit, empty repository. 2026-05-28 — invoice lines and the first Factur-X export, seven days later. 2026-08-11 — the Factur-X chain validated end to end. Three months, and not two: the dates are in the repository.
244 commits on the application; 12,040 lines of Java; 23 production files against 32 test files; 102 test methods, 92 tests run, 0 failures. Two independent third-party oracles: veraPDF 1.28.1 for PDF/A-3 B, Mustangproject 2.17.0 for XSD and the EN 16931 Schematron rules. The XML check runs twice — on the file generated, and on the file extracted back out of the delivered PDF, that is what the recipient actually receives.
And it was not the only workstream: on the same window (21 May → 21 August), the repository records 1,034 commits and 26 changed modules — and five dated deliveries were completed on that window: the validated Factur-X chain, write-boundary rights, multilingual T0→T4, the gs-bench A1/A2 campaigns, and the GSDS cold migration. Parallelism was not dispersion.
The classic estimate
| Lot | Content | Person-days | Rate | Total (excl. tax) |
|---|---|---|---|---|
| Model and screens | domain, CRUD, navigation, reactivity | 120 | €500 | €60,000 |
| Compliance | PDF/A-3 B generation, EN 16931 XML, validator setup | 45 | €500 | €22,500 |
| Security | accounts, roles, rights, per-organisation isolation | 35 | €500 | €17,500 |
| Internationalisation | multilingual and switching | 12 | €500 | €6,000 |
| Testing and integration | regression suite, continuous integration | 60 | €500 | €30,000 |
| Management | meetings, specifications, acceptance | 48 | €500 | €24,000 |
| Total | 320 | €500 | €160,000 |
Assumptions
- Team assumed — five people at varying intensity, about four full-time equivalents over four months: a senior technical lead / full-stack engineer, two confirmed full-stack developers, a testing and integration specialist, and a part-time project manager / business analyst.
- Day rate — a deliberately low weighted-average billed rate of €500 excl. tax per day, identical across all lots. A billed rate, not a payroll cost.
- Project management — 48 days, 15% of the total: workshops, specifications, coordination, demonstrations and acceptance.
- Scope — the estimate covers exactly what the measured column delivered: business model, reactive screens, organisations, clients, addresses, products, taxes, invoices, lines, payments, financial metrics, the draft → issued → PDF cycle, credit notes, accounts, roles, rights, per-organisation isolation, multilingual, and Factur-X PDF/A-3 B with CII EN 16931 XML and validators. As the measured build, it excludes bank reconciliation, accounting-software export, reminders, recurring billing, multi-currency and deposit to a platform.
Method, stated: this column is a counter-estimate — not a timesheet, not a fixed-price quote. It assumes existing standard frameworks and components; it does not price rebuilding the Generic System platform.
Counting rule, stated: files touched, not commits — a commit crossing two modules counts in both.
What we expect you to object
« And if you disappear? »
The model, the code and the tests are delivered and versioned in your hands — not a continuity promise, the absence of dependency.
« One more supplier to manage. »
A few thousand euros a year of administration, to be compared with the rate gap on a single mission.
« You are not referenced. »
The exception path exists almost everywhere: innovation sourcing, pilot budgets, direct purchase below threshold. A workable path makes it possible to test a new production model without changing the whole framework at once.