I have qualms and disagreements with the whole "software factory" concept, but your math doesn't help the argument. The cost of human labor is more than salary—or even hourly rate, if you're thinking of paying a contractor.

I'm comparing cost per $ of revenue, not labor. And my math is for a scenario assuming a company is running this type of software factory year-round.

Now one could say that the same feature that a customer would've paid $1M for was done in $4k instead of $160k. But buyers are going to demand much more as they see this kind of pace. You'd be able to charge maybe only $10k, because your opportunity cost goes down since you only spent 2 days; you can't keep the same margins that you needed to in order to justify spending 9 months on it. I think it gets very complicated and we're yet to see these economic effects.

I don't get your maths? [1] 160/9 months != 600 for any given number of days a week e.g. 5,6,7 (something between 6 and 7), but where did the 9 come from, is it some kind of adjustment for weekends? Anyway there is also a concept of "fully loaded employee cost".

In any case the way to think of this is not "/day".

The reason is simple. If you buy 1000 barrels of oil, you buy 1000 barrels of oil not 17.4 days of oil. There is now a disconnect between work done and time. Infact you would be sane if you said "that result I can get in 2 days for $4172, if you can get me that same result in 1 hour, I'd pay $8344". See where this is going?

Yes a lot of thought work is now a commodity, and if you want the commodity faster (last minute booking, uber to come quicker etc.) you pay more not less. Value being $/hour is over.

[1] The ? acts as both a question and a regex.

Its an approximate 160k ÷ (9 months x 28 days a month) = 635.

I dont think this is comparable to buying a barrel of oil at all. A software factory like this, I'm assuming is going to be run 24/7.

I get what you're saying, but thats assuming someone's buying their software at the faster pace as well, which we don't know.

True but the pace of buying doesn't matter for this argument (of course it matters for business longevity!). What matters is if you spend $160k on tokens or an employee then ... what gets more done.

For some jobs the employee comes out top, for others the tokens. This landscape will continually shift. However definitely the "per hour" is just some intermediate part of the value calculation can can't be directed compared.

If there were a way to pop out the next Lovable with $160k tokens and you can have that land in 4 hours, would you pay. Well yeah someone would, just like they'd buy $160k of oil if they needed it. It would be even better than paying $80k to an employee who took 6 months.

Only one of the two trends is downwards.

... Token cost is still heavily subsidized by the frontier labs while they're private companies and raise billions whenever they decide. The downward cost in tokens is unsustainable long term without revolutions training or inference of models.

There is no evidence whatsoever token cost is heavily subsidized.

I run Deepseek v4.1 flash and pay per token.

I get more intelligence and mileage out of few tens of euros on their APIs than I would've got out of Codex+Claude 200$ subscription in June.

If you don't see the downward trend that's a you problem.

Rather than per-day costs, I think it might be more meaningful to look at per-result costs. It took us about 9 months (and $160k using our napkin math) to add support for Oracle. Adding Db2 support using this agent pipeline took 2 days and $4,172 in tokens.

One caveat to the number for DB2 is that it doesn't consider review costs. We weren’t reviewing the hospital’s code during that sprint. Since we’re still confirming correctness for Db2, a more accurate comparison would add the human time to verify this.

I’m not going to claim this tripled our revenue. But revenue is also a function of time to deliver too. When a missing feature in the migration tool is what’s blocking a customer’s migration or a deal, shipping it in days instead of months can move revenue directly if it means the customer doesn't choose a different alternative.

Thank you for the reply. My question is - will you be able to charge the same amount for work done in days instead of months? Or even a proportional amount?

If its work that was blocking an existing deal, I can see this playing out in your favour. Whereas, if you were trying to negotiate a deal where you wanted the customer to pay x$ for a feature you have yet to develop, you might now have to charge lesser.