BonrockShould a One-Person Company Do Forward-Deployed Engineering?
A solo developer argues that forward-deployed AI work is a bad deal for one-person companies: unpaid discovery, unclear contracts and difficulty earning enterprise trust. Here is his argument and the conditions a solo practitioner should examine.
"Forward-deployed engineer" (FDE) is one of the job titles of the AI boom. The idea comes from Palantir: instead of selling software and leaving, you send engineers into the customer's business to learn how it works and build the system on site. AI labs and consultancies now hire for the role, because getting AI to do useful work inside a company takes exactly that kind of patient, embedded engineering.
So it is natural for one-person companies to ask whether they should sell FDE work themselves. The independent developer 王帅真 (Wang Shuaizhen, @qizong007), who runs his own one-person company, answered that question in a post titled "Why I don't really recommend one-person companies do FDE" (为什么我不太建议 OPC 去做 FDE？). His answer is no, and he calls it his own subjective view after talking with friends across many industries.
We should say up front that Bonrock sells exactly this kind of work, so we have a stake in the answer. That is also why his argument is worth taking seriously. Below we summarize it first, then add our own view. The translations are ours.
His case against it
1. The return on effort is poor. An FDE serves an organization, not a person, and has to learn the customer's real operations quickly enough to propose a solution and a price within the customer's patience. Then the same person builds, tests and often runs the system. The customer, he writes, sees it this way: your exploration, trial and error and understanding of my business are your cost, not mine. His sharpest example: the weeks you spend on the factory floor, talking to supervisors about shift schedules and asking veteran workers about machine settings — "which of those made it into the contract? Not one." The contract lists only features and targets.
He adds two more problems. Many companies have little usable data to start from. And the staff whose work you are automating have no reason to help: why spend extra time helping you "distill me away"? The discovery phase, he concludes, is the most expensive part of FDE work and appears nowhere in the contract. That is an unequal division of risk, and competitors will still undercut your price. After a month of work, a solo founder may have earned nothing but complaints.
2. Contracts favor the client. An individual has little power to negotiate a fair price, and has to learn contract pitfalls the hard way. Once the scope blurs, the client keeps asking for more, and "how much work for how much money" becomes impossible to settle; even getting paid is exhausting. In the worst case the client declares the work "below expectations" and walks away with your solution. Most one-person companies, he admits, himself included, have no real way to defend their interests.
3. Trust is hard to earn alone. How do you find enterprise clients, and why would they choose one person over another person or an established firm? Can one person even deliver at their scale? His observation is that the people who make FDE work are the ones good at relationships and offline networking. They win the deals, then hand delivery to technical people they know and share the money. That is traditional B2B selling, built on personal trust.
His conclusion: if, like him, you would rather work directly on users, products, content and conversion, build in the consumer market. Or do FDE as an employee of a company whose business is AI implementation, which already has the trust, the contracts and the division of labor. He ends with a joke: the best-paid people in FDE right now are the ones selling FDE training and consulting.
Where we agree
His concerns overlap with the findings discussed in our earlier article. Fudan University's report on China's one-person companies found that what decides success is the founder's experience and access to real business situations, not the tools (our summary). In FDE work, tools can help with delivery while leaving trust, access and negotiation to the practitioner.
He is also right that discovery is the expensive part. Even when agents shorten development, the practitioner may still spend days understanding the business before quoting. That time needs to be included in the economics of the project.
How to do it anyway without being exploited
His post describes what happens when a one-person company sells FDE work on the client's terms. The following arrangements can reduce those risks. They require the client's agreement, and none guarantees a profitable engagement.
Charge for discovery as its own product. Sell the first phase as a fixed-price diagnostic, for example two to four weeks with a written report: how the work flows today, where the data is, what to automate first, and a quote for building it. The client pays for your time on the factory floor whether or not they go ahead. The report is valuable on its own, and it turns his "unpaid exploration" into a paid deliverable.
Write the boundaries into the contract. Use a fixed scope, measurable acceptance criteria agreed in writing before building starts, and payment in milestones, with a deposit before work starts. Agree how ownership, licensing, payment and changes to scope will work. Have a qualified adviser review the terms for the jurisdiction and engagement. Written terms can reduce ambiguity; they cannot guarantee payment or eliminate the cost of a dispute.
Choose clients who already trust you. His third point is the strongest, and we wouldn't argue with it. Cold enterprise sales can consume substantial time before producing paid work. The workable versions are a former employer's industry, a friend's company, or a community you belong to, where trust exists before the first meeting. The one-person biotech Mithril worked partly because its founder had a decade of trust in his field before he started.
Or borrow trust. His own alternative is good: deliver through an established firm. A one-person company can be the specialist subcontractor behind an agency or consultancy that owns the client relationship. That gives up margin in exchange for trust, contracts and steady work.
Turn repeated delivery into products. Easy's One-Person Business Methodology makes the long-term point: selling time doesn't scale. If several clients need a similar order-intake workflow, investigate whether part of it can become a reusable product. Check which requirements are shared and which still need custom delivery.
Before taking the engagement
Wang's post is a warning about accepting enterprise delivery risk without the resources to manage it. Before accepting a project, check whether discovery is paid, the scope and acceptance criteria are clear, and the client has a reason to trust your delivery. If those conditions are missing, price the risk explicitly or decline. Consumer products and employment are alternatives, each with their own uncertainties.
If you are on the other side, a company that wants AI working inside its operations, the same three conditions protect you too: a paid diagnostic first, clear scope and a partner you trust. That is how we work, and you can contact us to start with a diagnostic.
Found this helpful? Pass it on.
Working on something like this?
We help organizations build AI systems that are secure, private and ready for real load.