A former real estate worker built an AI sales workflow for a manufacturer — they grew revenue $30M/year. He got paid $32,000.
I want to share something that's been rattling around in my head, because the numbers don't line up the way I expected.
A friend of mine used to work in real estate. He's not a coder. He's not a startup founder. He spent the last year building out a complete AI-powered workflow for a manufacturer — from the finished product all the way through to sales. AI digital humans presenting and selling the product, the whole chain.
The result on the business side: that manufacturer's annual revenue went up by roughly $30 million.
What he got paid for the project: $32,000.
That gap has been stuck with me. $30M in new value, and the person who actually built the system walked away with about a tenth of a percent.
I'm not telling this story to complain, and I'm definitely not saying "you could do this and make bank." This is one person, one deal, one moment. Most AI projects don't turn into $30M wins. Most people who try this won't get a single client.
But it raises a question I haven't been able to shake: where does the value actually sit in an AI service project?
Everyone online is arguing about whether AI is overhyped or underhyped. Meanwhile, a former real estate worker with no technical background walked into a manufacturer's messy process and built something that moved the needle by tens of millions. The AI wasn't the hard part. The hard part was understanding what the business actually needed, and then shipping something that worked end to end.
And then there's the other side: he built something worth $30M and got $32K. That feels like the market hasn't figured out how to price AI service work yet.
Curious what others here think. When you build AI workflows for real businesses — who captures the value? The business, because they own the customer? The builder, because they made the thing work? Or is that gap actually the opportunity?
I think the missing piece is that the builder usually gets paid for the work, while the business captures the outcome. The difficult part is figuring out how much of that outcome was actually caused by the system versus the existing business, sales process, market, and execution.
That’s probably where pricing gets interesting. A fixed project fee makes sense when the scope is clear, but when the system directly creates measurable business value, some form of performance-based or value-based pricing seems worth exploring. The challenge is defining the attribution and risk fairly for both sides.
You nailed the attribution problem. That's exactly the hard part.
In the case I mentioned, the manufacturer already had sales — they had customers, a product, a process that sort of worked. My friend came in and automated and cleaned up the broken parts. So how much of that $30M was the system, versus them finally executing on something they'd been meaning to do anyway?
Nobody knows. Not them, not him.
That's why the fixed-price model feels off here. If you can't measure your contribution cleanly, you either underprice (like he did) or you spend forever arguing about what caused what. Performance-based pricing sounds right in theory, but one side always has more information about their own business — and the builder is the one who has to trust that the numbers are real.
Yeah, that information asymmetry is probably the bigger problem than attribution itself. Maybe the answer isn't trying to prove exactly how much revenue the system created, but agreeing upfront on a few measurable outcomes the builder can actually influence.
For example, define the baseline, the specific process being changed, and 2–3 measurable KPIs before the project starts. Then a hybrid model could make more sense — a fixed implementation fee plus a performance component tied to those agreed metrics. It wouldn't eliminate the attribution problem, but it could make the risk and upside more balanced for both sides.
The pricing gap exists because the builder sold implementation time, not outcome. Fixed deliverable, fixed price, done. The manufacturer kept the compounding returns.
What changed recently is that the build cost is dropping fast. I built a seven-language SaaS entirely through AI coding sessions. The latest model upgrade means debugging a broken route takes one pass instead of three because the model reads the actual error trace now instead of guessing. That speed improvement is real, but it makes the pricing problem worse — if the build takes fewer hours, a time-based contract pays even less.
The opportunity is in the gap your friend missed: stop selling build hours and start selling the ongoing system. Revenue share, maintenance contracts, equity in the outcome. The AI made building cheaper. It did not make understanding what the business needs cheaper.
That’s a useful distinction. If the builder only owns implementation, a fixed project fee is clean. But if they’re also responsible for keeping the system running, that feels like a different deal. How do you price the ongoing part fairly when revenue depends on so many other factors?