---
title: "A Harvard Master's \"Lobster-Packing\" Epiphany: AI Can't Actually Enter Real Chinese Factories"
author: "Unique Research"
sourcePublication: "Unique Research Substack"
originalPublishedAt: "2026-07-07T08:02:35+00:00"
canonical: "https://ffcap.cn/en/research/src-20260707-01html"
source: "https://uniqueresearch.substack.com/p/src-20260707-01html"
language: "en"
---

# A Harvard Master's "Lobster-Packing" Epiphany: AI Can't Actually Enter Real Chinese Factories

_Original · Unique Research · 2026-07-07_

_Editor's note: This is a first-person narrative report about Lawted (Wu Mingze), a Harvard MDes Engineering graduate and former Stanford HAI research assistant who discovered FDE (Forward Deployed Engineer) opportunities in Chinese SMEs. All personal anecdotes, company names, and numerical claims are attributed to the interviewee. Product and company names are preserved as stated._

AI Industry Observation

From Outsourcing to FDE: The Delivery Model Has Changed in the AI Era

"Isn't this just outsourcing with an English title?" — The thing is, it really isn't

This April, Wu Mingze got to know a freight forwarding company boss through "packing lobsters."

Funny story. That friend had been in logistics for exactly ten years; April was peak lobster import season, so he casually introduced Wu Mingze to this boss whose company does over 100 million RMB in annual revenue. Who is Wu Mingze? A Harvard MDes Engineering graduate, a research assistant at Stanford HAI (Human-Centered AI Institute). He's also worked as an engineer at Alibaba, Tencent, and MiniMax—a standard "Silicon Valley–Stanford–big tech" elite path. His daily contacts are either AGI geeks in Silicon Valley or researchers in Stanford labs.

Yet at this freight forwarding company's site, this boss with over 100 million RMB in annual revenue had never actually used Doubao.

It's not that the boss isn't smart, not that enterprises don't need technology. It's that AI is much farther from the mass of ordinary enterprises and ordinary people than we imagine. Sitting in cafes in Beijing's Wudaokou or Hangzhou's Future Tech City, we feel AI has turned everything upside down. But step outside these bubbles, and the real industrial floor is an entirely different world.

Lawted—what friends call him by this English name now—went to see how order coordinators work. WeChat, Excel, PDF, from 8 AM to 9 PM every day, pure human copy-paste: reading documents, entering fields, verifying information. No system integration, no automation. A workflow that might not have changed in ten years.

"That moment I realized: AI's real opportunity may not just be creating more cutting-edge technology, but bringing technology that already exists into these real industrial sites."

This epiphany directly spawned his second identity: besides running Ha7ch (an FDE community and incubator), he also founded Alvenda (鑫栩达科技), an FDE on-site delivery company. From Silicon Valley back to Hangzhou, from the lab back to the factory, he started using a "grassroots FDE" approach, diving into real enterprises one by one.

And when he started explaining the FDE concept externally, the first reaction was almost always the same—

"

"Isn't this just outsourcing with an English title?"

The thing is, it really isn't.

"Outsourcing with a Different Name?" — A Ten-Dimension Comparison Shows the Difference

Lawted specifically made a "ten-dimension comparison" video to respond to this skepticism. The difference between outsourcing and FDE starts from the very beginning.

What's the starting point of traditional outsourcing? The solution is basically already determined. The client says "I want to develop feature X," there's a PRD, a requirements document, even design mockups. The outsourcing team's endpoint is "feature done"—code delivered, project accepted, paid, walk away. Whether anyone uses the feature after launch, whether it solves a business problem—that's not in the contract scope.

FDE's starting point is the opposite extreme: an extremely vague problem. What clients say is often "I also want to use AI to improve efficiency, but I don't know where to start." No PRD, no defined solution, even the problem itself needs to be defined first. FDE engineers must enter like consultants first, spending days or even weeks understanding business processes and finding the real pain points.

The endpoint is also different. FDE doesn't deliver a feature list; it delivers business results. They dare to tie revenue to client outcomes—do it and split the money, fail and work for free. This is a performance-betting commercial contract, vastly different from outsourcing's "per-person-day pricing."

Lawted told me a case about a cross-border apparel company. The boss only said one sentence: "AI, help me make more money." Vague beyond vague. The FDE team went in and analyzed: this company only has an English website, and the Chinese-style expressions are completely unsuitable for overseas consumers—literally translated product descriptions, page layouts that don't match local habits, and overseas users click in and immediately close.

FDE proposed building localized websites for 18 countries. But the key is the pricing: billed per valid customer acquired, 5 to 10 RMB each. Didn't bring new customers? Then the website has no value, FDE works for free.

See the difference?

Outsourcing delivers "18 websites"; FDE delivers "new customers."

One sells heads, the other sells outcomes.

On the surface both are "sending engineers to client sites," but the underlying commercial contracts are completely different. Outsourcing cares about "how many pages I made, how many lines of code I wrote"; FDE cares about "did your business revenue grow."

What makes all this possible is Coding Agent.

In the past, a custom project like this needed a complete product team—product manager, designer, front-end and back-end engineers, QA—quoted at 2-3 million RMB minimum. Project cycles of three to six months, and communication costs alone could eat a third of the budget.

Now? Two to three hundred thousand. One person who understands the business and can proficiently use Codex (OpenAI's AI coding tool) or Claude Code (Anthropic's AI coding assistant) can independently get this done. Coding Agent improved the "writing code"环节's efficiency by an order of magnitude; one knowledgeable person plus AI can accomplish what previously took a team.

Cost dropped by a full order of magnitude. This isn't quantitative change—it's qualitative change, qualitative enough to make an entirely new business model possible.

Lawted divides the FDE ecosystem into two types. One is big-tech platform FDE, doing customization based on mature platforms, essentially driving the sales, usage, and renewal of their own products. Palantir (the US big data analytics company, once valued over $100 billion) is the archetype of this model; domestically, Feishu, DingTalk, and Alibaba Cloud are also pushing similar on-site services.

The other type is what he's more interested in—startup FDE, which he calls "grassroots FDE" or FDE OPC (Independent Contractor). This type of FDE is completely technology-neutral: if the client needs GPT, use GPT; if they need a plugin, make a plugin; no preset assumptions. Don't ask "what product do I have to sell" first—ask "what does the client actually need."

LinkedIn data is intuitive: FDE-related job postings grew 42x over the past period. OpenAI even spent $4 billion to set up a dedicated deployment company. Capital and talent are both flowing in this direction—the market has already voted with its feet.

But what FDE actually is still hasn't been truly clarified. Especially in China's soil, what it will grow into—the answer is even less in Silicon Valley's templates.

Big-Tech FDE vs. Grassroots FDE: China Doesn't Need a Second Palantir

First, how does big-tech FDE work?

Take Feishu as an example. A factory in Anhui has already purchased Feishu and AI credits. Feishu sends FDE on-site, asks the boss if they want safety helmet recognition, smoke and fire recognition, then connects to a multi-dimensional table. Mature platform, stable delivery, strong compliance capability—these are all advantages. The enterprise bought Feishu, Feishu sends people to help you deploy—looks like one-stop service.

But the limitation is obvious: it often channels client problems toward their own products.

The client needs a hammer, but big-tech FDE only has a screwdriver. It's not that the screwdriver is bad—it's that the problem is different. Feishu's FDE naturally guides you to use Feishu; DingTalk's FDE guides you to use DingTalk—this is determined by the business model, nothing to blame. But enterprises need to be clear about what they're buying. What you get may not be "the solution best for you," but "the solution I happen to have."

Grassroots FDE doesn't have this problem. Technology-neutral, flexible, serving SMEs that big-tech platforms can't reach—these are natural advantages. But Lawted says, what's truly interesting isn't "who's better," but that China's market特殊性 is producing a unique FDE form.

China's economic structure has a huge number of manufacturing, logistics, cross-border trade, and traditional service enterprises. Inside these enterprises there's massive order coordination, order dispatch, review, routing, and data entry work—processes that are repetitive, rule-based, and highly structured, perfectly suited for partial AI automation. The "WeChat + Excel + PDF" combo Lawted saw at the freight forwarder is repeated countless times in Chinese factories and warehouses.

At the same time, these enterprises can only pay very little. Palantir's projects are often millions or tens of millions; Chinese SMEs can only accept tens of thousands to hundreds of thousands. The market size is here, but unit prices are completely different.

This forms a sharp contradiction: the price enterprises are willing to pay is low, while mature FDE labor costs are high. An FDE engineer coming out of Palantir might start at a million RMB annual salary—how can they serve a factory with tens of millions in annual revenue and an IT budget under 500,000?

"Chinese-style FDE isn't a scaled-down Palantir. It won't be a suited-up consulting team, nor platform salespeople sent by big tech. It's more like small teams and individuals who understand the industry, understand communication, and can independently complete delivery with Coding Agent."

Coding Agent dropped custom project cost from 2-3 million to 200-300 thousand, rewriting the boundary of "what one person can deliver." When "one person + AI" can accomplish what previously took a team, the way labor is organized will inevitably be restructured.

FDE isn't outsourcing with an English name. It's an entirely new labor organization model in the AI era—starting from vague problems, ending with business results, selling outcomes not heads. And the answer to Chinese-style FDE isn't in big tech's PPTs, but in the hands of young people willing to squat in factories, listen to order coordinators' complaints, and use Agent to turn Excel and PDFs into automatic flows. Palantir's template doesn't work in China because China's industrial soil needs something completely different—not more expensive consulting, but more site-grounded delivery.

Coding Agent has just opened this door.

"50,000 Per Year" or "One Employee's Annual Salary" — Pricing Is Essentially a Translation Problem

The door is open, but there's still a hurdle: how to make the boss willingly pay?

There's a trick here. This isn't a technical problem; it's a translation problem.

The biggest pit Lawted stepped on was using the wrong language. Say "annual subscription fee of 50,000 RMB," and the boss immediately pictures two images: either Tencent Video or iQiyi's auto-deduction—money flowing out monthly, who knows if it's worth it; or being duped by a software sales rep years ago—pitched sky-high at purchase, a mess when used. Chinese SMEs have natural suspicion of "software subscriptions." This isn't prejudice; it's built on hard-learned lessons.

Lawted later switched to different language, and the effect was completely different. He doesn't say "software," he says "digital employee." He doesn't say "subscription fee," he says "annual salary."

Bosses know human cost too well. An employee's take-home is 5,000, but the enterprise's actual cost is close to 8,000—social insurance, housing fund, recruiting costs, training costs, exit handover, management attention. Bosses don't need to calculate these numbers; they rattle them off. A coordinator doing repetitive work costs 100,000+ per year all-in.

Lawted's communication formula: first establish the baseline. How many orders per week originally? How long per order? Error rate? Number of customer complaints? The boss knows these numbers; nobody's just systematically organized them for him. Put the baseline on the table, and the room for improvement lights up naturally.

Then discuss pricing. Not "I'll sell you a system," but "I'll provide a digital employee that takes over two employees' repetitive work, annual salary 50,000." The boss says 50,000 isn't expensive, because two employees' repetitive work is worth at least 100,000—he gets this math in a second.

More importantly is the model. The system saves 100,000 in actual labor cost per year; FDE takes a percentage of the value created: 5%, 10%, or 20%. Bosses will pay for "money saved"—that's human nature. Rather than prepaying for "high-tech that might help," that's gambling.

But here's a very important qualifier: pure result-based guarantees don't work. Brand lift, sales growth, customer conversion rates—these metrics are hard to attribute entirely to FDE. A website goes live, overseas customers increase—it might be because market conditions changed, a competitor stumbled, or even the boss himself closed a big client—none of which FDE controls. If everything is billed by result, FDE becomes a pure gambler, and the model can't go far.

So how is it actually done? Tiered pricing. Pre-diagnosis, development, deployment charge a base fee—this covers FDE's time and intellectual investment regardless of outcome. After official launch, parts that can be clearly attributed are billed by performance: number of automatically processed orders, labor hours saved, error rate reduction. The system directly produces these numbers, both sides look at the data, no dispute.

Tiering has another benefit: it forces both sides to define "success criteria" clearly before the project. What's the baseline? What metrics count as improvement? What level of improvement triggers revenue sharing? These must be thoroughly discussed before project kickoff. To some extent, the pricing process itself is part of FDE's work—helping clients translate vague expectations into measurable metrics.

Lawted told a typical case. Same cross-border company, same system, two pitches.

Pitch one: "50,000 RMB annual software subscription." The boss thought for three days, didn't reply.

Pitch two: "50,000 per year, a digital employee that takes over two of your employees' repetitive work, ROI is clear." The boss signed the same day.

What's the difference? One made him think of consumer software auto-deduction; the other made him think of human resource ROI. Pricing language is itself part of the translation work FDE must do.

Where Do Grassroots FDEs Come From — Ha7ch Isn't Teaching Classes, It's Sending People to the Field

After talking about pricing, a more fundamental question: who cultivates these grassroots FDEs?

Lawted's approach is unexpected: not training schools, not business schools, but an Accelerator.

He used a particularly precise analogy—YC. What does Silicon Valley's Y Combinator (the world-famous startup accelerator that backed unicorns like Airbnb, Dropbox, Stripe) give startups? Money, of course, but more importantly, real scenarios: three months of high-density training, weekly conversations with real users, Demo Day in front of real investors. Without these, entrepreneurship is self-touching PPTs.

Ha7ch does exactly the same thing, just with a different starting point. YC gives companies capital to help them grow fast. YC's basic unit is the company. YC's most valuable thing isn't the $500,000—it's the pressure of "you must build something real people use within three months." Ha7ch gives people real scenarios to help them gain industry capability. Ha7ch's basic unit is the person. Ha7ch's most valuable thing isn't any course—it's the real battlefield of "you must enter enterprises, be on-site, face unclear requirements and legacy systems and internal resistance."

Lawted says FDE essentially can't be learned by taking classes. You can learn Python by watching videos, but you can't learn "how to sit down with a 50-year-old factory boss and clearly understand what he actually wants" from a video. This requires entering the field, observing how coordinators work, feeling the boss's hesitation about your solution, handling the crash of legacy system data format incompatibility.

So what Ha7ch cares about most right now isn't "what to teach," but "who to put on the field." More focus on students and young Builders. The reason is practical: flexible time, willing to use the latest AI tools, willing to enter unfamiliar industries. A 35-year-old big-tech P8—ask him to squat at a freight forwarder in Xiaoshan, Hangzhou for a month? He probably won't. But a 23-year-old, just graduated, full of curiosity? He might be chasing exactly that.

Lawted particularly values the "first real delivery" experience. Many Builders don't lack capability; they lack scenarios. They've made a bunch of toy demos at home—cool-looking AI applications, but never used by a real enterprise. What they lack isn't another tutorial, but the opportunity to enter the field.

What does Ha7ch provide? Real problems, enterprise entry points, a community of peers, the chance to complete the first real delivery. These elements together constitute the core of an accelerator.

The community network structure has three layers. The outermost is Meetup, entry-level events that let more people know about FDE and meet Lawted and early Builders. The middle layer is the Guild, long-term networks built by city—Beijing, Shanghai, Shenzhen, Hangzhou, Silicon Valley, already five nodes. The innermost is GuildUp, small-scale high-frequency interaction where the most active Builders meet weekly to discuss project progress, enterprise feedback, problems encountered.

The entire community is about 2,000+ people, with active Builders between 500 and 1,000. Not a big number, but Lawted says it's enough—FDE doesn't need ten thousand people, it needs a hundred who are actually doing it.

In terms of time allocation, Lawted's main energy is on Ha7ch. Alvenda (鑫栩达科技) is closer to an advisor and co-founder role, run by the team day-to-day. The reason is simple: Ha7ch burns money—no stable revenue, sustained by Lawted's personal savings; Alvenda is closer to blood-making, project payments keep it running.

But long-term, Lawted wants Ha7ch to stay non-profit. Like a school, like an alumni network—not owning its graduates. Builders gain capability at Ha7ch, then go start companies, join enterprises, do their own thing—Ha7ch doesn't charge follow-up fees. This openness is in the same lineage as YC's alumni culture: "Ha7ch's earliest cohort of FDEs who grew up in real enterprise scenarios" is itself the strongest capability endorsement.

FDE naturally generates cash flow. A Builder solves problems for an enterprise and has revenue—no need to take investment first to start. This is completely different from entrepreneurship—founders need to eat, pay rent, pay salaries, must fundraise. But an FDE Builder just needs to take one enterprise's project to have income. This means the accelerator model doesn't need to burn big money like VC; it's more like a catalyst that "helps people start making money."

Why Him — Design Engineering Taught More Than Design

By now, you might wonder: why can Lawted see all this?

His background isn't the standard answer. Harvard MDes Engineering, Stanford HAI research assistant, Alibaba/Tencent/MiniMax engineer—this path isn't short on technical credentials. But the real difference isn't on the resume; it's in the way of thinking.

Design Engineering as a discipline requires one thing: simultaneously understanding product, design, engineering, and human behavior. Can't only understand technology, can't only make PPTs. Must be able to sit down with a factory boss and clarify pain points, then go back and implement the solution with Claude Code.

Lawted's division of FDE into "big-tech platform type" and "grassroots FDE" is inseparable from his design engineering training. Pure computer engineering founders often start from technology—what can you do with a new model? What are the technical boundaries? Lawted's habit is the reverse: what problem does this person have? What solution is most effective?

How big is the gap when these two thinking modes land? If technology from ten years ago can solve the problem, use technology from ten years ago. Enterprises don't buy new vs. old technology; they buy whether the problem is solved. This sounds like common sense, but it's very rare in the AI startup circle—too many people chasing the latest model version instead of asking "does this factory boss actually need GPT-4."

Lawted isn't that tech-worshipping. This is his biggest difference from pure-tech-background founders. The most important thing isn't using the newest technology, but understanding technology boundaries and quickly implementing truly useful solutions. He positions himself as a "super FDE"—entering factories, logistics companies, cross-border teams, racing teams, talking strategy with the top leader and daily operations with frontline staff.

Previously at big tech, he dealt with abstract architectures of complex software systems; entering factories, he saw for the first time how assembly lines run, how hardware is manufactured, how workers and managers collaborate. This is exactly like his racing team experience: not asking "what model to use" first, but observing how the team manages race data, how decisions are made, then judging where AI can plug in.

Put simply, pure CS people see a new model and think "what can it do"; design engineering-trained people's habit is to first ask "what's the actual problem here." These experiences don't just help him understand FDE; they enrich his understanding of how business, industry, and society operate.

Of course, FDE capability can be trained, but it can't be quickly developed into senior FDE through a set of courses—it requires time. Lawted's阶段性 answer is: discover underlying capabilities (learning, initiative, interviewing, probing) at Ha7ch, then use real projects to build industry experience. You can teach someone how to ask questions, but you can't teach them intuition for an industry—that must be soaked in.

Back to the opening scene: April, peak lobster import season, a Harvard master's got to know a freight forwarding boss with 100 million+ RMB revenue who had never used Doubao, through "packing lobsters." Eight months later, Lawted's choice is clear: community and people as the core, projects for validation, tools for accumulation, commercialization to keep the network running—not as the end goal. Ha7ch is like a school without walls; Alvenda is the battlefield for the school's graduates.

I asked him, what would you do differently if you started over? He thought for two seconds: "Start doing self-media earlier." Continuously produce enough small projects, continuously express publicly—not for traffic, but to let more people see what FDE actually is and what it can do. Build in Public is itself a form of filtering and connecting.

At the end of the day, FDE ultimately doesn't prove itself through persuasion. No matter how beautiful the PPT, it can't move a factory boss—he's seen too many "digitalization solutions" come and go. FDE relies on producing visible results in a very short time: system goes live, orders are automatically processed, employees don't need to work overtime at night.

AI deployment isn't about buying more software. It's about letting people who understand the site go in with AI and solve problems one by one.

Did that freight forwarding boss start using Doubao?

Lawted smiled and said it doesn't matter. What matters is that his order coordinators now get off work at 6 PM every day.

More Interview Details

Q1: You went from being a coding engineer to doing an FDE community and industrial deployment. How did this change happen?

Lawted: This transition happened around this April. At the time I knew a friend who'd been in logistics for ten years, and we often ate together. Lobsters were popular then, so he introduced me to a freight forwarding company boss through this "packing lobsters" thing.

We initially just went under the pretext of packing lobsters and making friends, but as we chatted, we found that this boss hadn't even really used AI products like Doubao. This hit me hard.

Because a lot of what I'd been exposed to before was Silicon Valley, Stanford, or the most cutting-edge AI research and products. In that context, people discuss Agents, model capabilities, workflows, and various new technical paradigms. But when I got to the real enterprise site, I suddenly found that AI is still very far from the mass of ordinary enterprises and ordinary people—there's a huge gap.

What's more interesting is that these bosses aren't without anxiety. He clearly knows AI is happening, knows his enterprise should use AI, but doesn't know where to start, doesn't know what problems AI can actually solve, and doesn't know who to find to do it.

Later we went into his business site to see how order coordinators work every day. A lot of work still relies on WeChat, Excel, PDF, and human copying—reading documents, entering fields, verifying information, handling exceptions. We quickly found that there are indeed many aspects that can be optimized and made more efficient by AI.

That experience made me feel very clearly for the first time that AI's real opportunity may not be creating more cutting-edge technology, but bringing existing technology into real industry. From then on, I stopped only focusing on the most cutting-edge overseas research and products, stopped seeing myself only as a coding engineer, and started putting more energy into enterprise sites—understanding real workflows, judging what problems are worth solving with AI, then quickly building systems that can be validated. This is also what truly triggered me to start doing FDE.

Q2: How has your design engineering background influenced your understanding of FDE? How is it different from a pure computer engineering background?

Lawted: First, I wouldn't say I'm already defining FDE industry standards; I'm more like proposing an observation and classification. For example, I divide FDE into "big-tech platform FDE" and "grassroots FDE"—that is, startup FDEs that independently enter SMEs and complete requirements discovery and delivery themselves.

My ability to see the differences between these two types of FDE is inseparable from my design engineering background. Design engineering requires a person to simultaneously understand product, design, engineering, and human behavior. You can't only understand technology, and you can't only do interviews. You must truly enter the enterprise, communicate with the boss and frontline employees, understand what they actually need, while also understanding AI capability boundaries, and have personally used Agent, Claude Code and similar tools at high intensity across many projects, knowing whether an idea can quickly become a demo and truly go live.

My biggest difference from pure computer engineering founders is probably that I'm not that tech-worshipping. For me, the most important thing isn't using the newest technology, but understanding technology boundaries and quickly implementing a truly useful solution.

Many tech-type founders might start from technology innovation and ask first: "I have a new model, new algorithm, or new architecture—what can I do with it?" But I'd rather start from human needs and workflows and ask first: "What problem is this person having right now, and what solution can most effectively help them?"

If technology from ten years ago can already solve this problem well, I'll use technology from ten years ago. Because what enterprises truly buy isn't whether technology is new or old, but whether the problem is solved.

Q3: Why does Ha7ch call itself an "FDE Accelerator" rather than a training institution or consulting company?

Lawted: Ha7ch's earliest starting point was actually when I was a research assistant at Stanford. At the time, some friends and I were discussing: will there be a product form truly aimed at AI Agents in the future? We did a lot of experimentation around Claude Code back then; what we wanted to do wasn't simply adding AI to existing products, but making products AI-native from the start.

Later I came back to China and接触 real enterprises, and found this aligns perfectly with enterprise needs. Enterprises of course want to become more AI-native, want to use AI to improve efficiency, reduce costs, even restructure their original work methods. But the problem is: who will sort out the business? Who will judge where AI is suitable? Who will turn these needs into products that actually run?

I later realized this role is FDE. So Ha7ch gradually evolved from the earliest AI-native Builder Lab into what we call the FDE Accelerator.

The reason we call ourselves an Accelerator rather than a training institution is that FDE essentially can't be learned through taking classes. It requires truly entering enterprises, being on-site, communicating with bosses and frontline employees, facing unclear requirements, legacy systems, internal resistance, and real business pressure. These things are hard to simulate through a course.

What many Builders are producing now is essentially still toy demos—cool-looking, but not solving real problems. What they lack isn't another tutorial, but the opportunity to enter the field and truly solve the real problem.

So Ha7ch is more like giving Builders a real testing ground. Let them enter enterprises, see if they can understand the business, discover the real problems behind the boss's surface-level needs, and make something that frontline employees truly认可.

If we rank "people, projects, companies," what Ha7ch most clearly accelerates right now is people. Projects are training grounds, but not assets Ha7ch ultimately wants to own; companies may be long-term outcomes, but not something we force at this stage. The ranking should be: accelerate people first, then validate people through projects, and finally some of those people may discover truly repeatable industry needs through continuous projects, and then start companies.

Q4: What exactly is the relationship between Ha7ch and Alvenda? Is the community feeding talent to the commercial company?

Lawted: I wouldn't simply understand the two as "community sustains business." Alvenda is just one link in the entire ecosystem, not Ha7ch's only commercial outlet.

I'm currently closer to an advisor and co-founder role at Alvenda, mainly providing support on project direction, FDE talent assessment, requirements analysis, and industry resources. But my personal main energy remains on Ha7ch, because what I want to build long-term is FDE talent networks, methodology, and community infrastructure.

Alvenda's value is letting some methods and judgments be validated in a real commercial environment. Because if Ha7ch only does community, events, and idea propagation without real projects entering enterprise sites, it's hard to gain long-term credibility. People will inevitably ask: have you actually taken on projects? Have you faced delivery, go-live, client expectations, and organizational resistance?

But conversely, it shouldn't be only Alvenda's project experience that feeds back to Ha7ch. FDE itself is a very broad field; different industries have completely different workflows, business rules, and deployment methods. Logistics solutions don't necessarily apply to manufacturing, and manufacturing experience can't directly transfer to education or finance. So I'd rather Ha7ch be a place where industry knowledge continuously converges, exchanges, and iterates—not the internal training department of a single delivery company.

Currently, we haven't encountered obvious conflicts of interest. Ha7ch has insisted on non-profit and open positioning from the start. Helping a Builder grow into an FDE doesn't mean owning that person, and doesn't mean they must join Alvenda afterward.

I think it's more like a school, or an alumni network like Harvard. Harvard doesn't require a student to stay and work at Harvard after graduation just because it educated them. Ha7ch should be the same. We give Builders scenarios, feedback, connections, and endorsements, but don't bind their career choices.

If a Builder cultivated at Ha7ch in the future wants to participate in an Alvenda project but client needs don't align with their long-term growth direction, I won't force them into a project to fill a gap. Alvenda can offer opportunities, but Builders should have the choice. A healthy ecosystem can't be built on owning talent; it should be built on long-term trust and two-way matching.

Q5: Many people say FDE is just outsourcing with an English title—how do you respond?

Lawted: Many people also ask me, isn't FDE just the old on-site engineer or outsourcing with a new English title? But I think the most fundamental difference isn't whether you sit in the client's office; it's that the starting point and endpoint are completely different.

Traditional outsourcing or on-site engineers' starting point is usually that the solution is basically determined. The client tells you: I want to develop a system, add a feature, complete multilingual adaptation; the engineer receives the requirement and executes.

But FDE's starting point is often an extremely vague problem. Maybe it's just because you went to pack lobsters for a logistics boss once, and he suddenly says to you: "I also want to use AI to improve efficiency, but I completely don't know where to start." This is FDE's true starting point. It has no PRD, no defined solution, not even a clear understanding of what the problem is.

FDE needs to enter the field, observe how employees work, continuously communicate with bosses and frontline staff, gradually sort this extremely vague requirement into a clear workflow, turn it into a GitHub Issue, and finally into production-level code.

The endpoint is also different. Traditional outsourcing's delivery endpoint is usually product or feature completion; once accepted, payment can be collected. Whether anyone actually uses this product afterward, whether it truly helps clients acquire customers, reduce costs, or improve efficiency, is usually not within the outsourcing team's responsibility.

But FDE emphasizes delivering results. In projects suitable for performance-based billing, if the system produced can't help clients generate qualified leads, reduce costs, or improve processing efficiency, then the thing itself has no value, and shouldn't receive full payment just because the code is written.

Of course, not all projects can use pure performance payment. But FDE's value judgment must always end with client results, not with a feature list.

So I think FDE isn't simply reskinned on-site work. If you just change the title and still write code according to client PRDs, it's still traditional outsourcing. The real changes are four: first, FDE's starting point is vague problems, not determined solutions; second, FDE has problem-defining authority, not just execution; third, FDE's endpoint is business results, not just completing products; fourth, Coding Agent dramatically reduces custom software production cost, making it possible for one person or a small team to complete what previously required a complete organization.

Without these changes, it's a reskin; with these changes, it's a new organizational and delivery model.

Q6: Why do you say Coding Agent isn't FDE's auxiliary tool, but the prerequisite for this round of FDE explosion?

Lawted: FDE didn't appear out of nowhere as a brand new species. It absorbed part of the capabilities of consulting, product, engineering, pre-sales, and implementation. But the biggest variable that truly makes this model viable today is Claude Code, Codex, and similar Coding Agents.

In the past, building a custom software system for an enterprise required a complete team—front-end, back-end, product, QA, and project manager—costing potentially millions.

Today, with Coding Agent, the production cost of the same system can drop by an order of magnitude. In the past, SMEs simply couldn't afford custom solutions; but if a solution drops from 2-3 million to 200-300 thousand, or even becomes an ongoing service of 40-50 thousand a year, it starts entering the range that mass SMEs can accept.

What used to require a team to deliver can now be done by one person who understands business, product, and engineering, plus Codex or Claude Code.

So I think Coding Agent isn't FDE's auxiliary tool, but the prerequisite for this round of FDE truly exploding.

Take the racing team I currently serve as an example. The client keeps proposing new requirements, but maintenance itself isn't as difficult as imagined. My most important work isn't personally writing large amounts of code every day, but observing their workflow, clarifying requirements, and turning them into GitHub Issues. At night, I can have Codex or Claude Code complete those Issues.

The part I'm truly irreplaceable in is judging problems, clarifying requirements, and defining boundaries—not mechanically writing every line of code. As models continue to strengthen, more and more system implementation will become "organize requirements accurately, then hand to the Agent to execute." So technical implementation itself will get cheaper and cheaper, while on-site judgment and requirement definition will get more expensive.

Q7: How do you see the difference between "big-tech platform FDE" and "grassroots FDE"?

Lawted: I divide FDE into two types myself: one is big-tech platform FDE, the other is grassroots FDE—that is, startup FDE, or FDE OPC.

Grassroots FDE directly faces SMEs, with no platform they must sell and no mature product behind them. They can freely choose technology based on on-site needs: use GPT if GPT, use Codex if Codex, make an AI+ERP incremental plugin if needed, make a knowledge base, workbench, or automated workflow if needed.

What they ultimately deliver isn't a fixed product, but a solution to the client's problem. This is also the huge difference between grassroots FDE and traditional software sales. Grassroots FDE doesn't ask "what product do I have to sell" first; they ask "what does this client actually need" first.

Big-tech platform FDE logic is completely different. Whether Palantir, or domestic Feishu, DingTalk, Alibaba Cloud, they're all essentially based on a mature platform, completing a degree of customization for clients.

For example, I previously visited a factory in Anhui that had already purchased Feishu and AI credits. The Feishu team would further ask if they needed safety helmet recognition, smoke and fire recognition, then connect surveillance data to Feishu multi-dimensional tables. Because the client already bought the platform and credits, FDE services might be offered as add-on services. The FDE sent may have done similar projects for 20-30 factories; on-site they confirm camera models, system interfaces, and processes, and can complete it quickly.

This is typical big-tech FDE: on the surface customizing for one client, but behind it there's already a mature platform, standard components, and repeated delivery experience.

So big-tech FDE ultimately usually drives sales, usage, or renewal of a product. Behind Palantir FDE is Foundry; behind Feishu FDE is Feishu and multi-dimensional tables; behind DingTalk FDE is DingTalk; behind model vendor FDE are models, APIs, Coding Agent, or cloud services.

Their advantages are mature platforms, stable delivery, and strong compliance capability, but they also have natural limitations: they tend to channel client problems toward their own products. Grassroots FDE's advantages are technology-neutrality, flexibility, and ability to serve SMEs that big tech temporarily can't cover; but the risk is easily becoming low-price outsourcing, and lacking the brand, engineering, and after-sales guarantees that big platforms provide.

So the two aren't replacing each other; they serve different tiers of the market.

Q8: What will Chinese-style FDE look like? Will it be a scaled-down Palantir?

Lawted: I think Chinese-style FDE is still being explored.

China has a large number of manufacturing, logistics, cross-border trade, and traditional service enterprises, with massive internal order coordination, dispatch, review, routing, data entry, and communication processes. These tasks are very suitable for partial AI automation.

But China's market also has a very practical contradiction: the price enterprises are willing to pay is relatively low, while currently mature FDE labor costs are relatively high. Palantir typically serves projects in the millions, tens of millions, or even larger, but China's vast number of SMEs may only accept budgets from tens of thousands to hundreds of thousands.

This means Chinese-style FDE must be lighter, faster, more Agent-dependent, and more focused on embedding into existing systems rather than rebuilding a platform.

I don't think all Chinese enterprises need to copy Palantir's Ontology path. Ontology isn't just about uniformly modeling objects, relationships, and actions in an enterprise; more importantly, it builds a layer of traceable, auditable, permission-controlled, and data-compliance-reviewed governance structure within complex organizations. For governments, large financial institutions, multinational enterprises, or highly regulated industries, this is of course important.

But for China's vast number of SMEs, it's often too heavy. What many SMEs need to solve first isn't whether a decision can be fully audited, or how to unify cross-department, cross-country data permissions; it's that five employees are still manually entering orders today, a PDF needs to be copied twenty times, an order needs to be repeatedly confirmed between WeChat and Excel.

At this stage, building a complete ontology, permissions, and audit system first may cost far more than the actual problem itself.

So for SMEs, a more realistic approach is to first find a high-frequency, clearly bounded process, use AI or a digital employee to do it well, then gradually add permissions, logging, tracing, and audit capabilities based on enterprise size, risk, and compliance requirements.

Not every enterprise needs a scaled-down Palantir. What they need more is lightweight, fast, embeddable solutions.

I think the most likely form Chinese-style FDE will take isn't a scaled-down Palantir, but a large number of small teams and super-individuals who understand the industry, understand communication, and can independently complete delivery with Agent.

Q9: You say FDE should "sell outcomes," but do Chinese enterprises really accept performance-based payment?

Lawted: Based on my current接触 with enterprises, Chinese bosses don't actually reject performance-based payment; in many cases, they accept it more readily than traditional software subscriptions.

The first reason is that if AI truly enters a high-frequency workflow, the results it brings are usually quite significant. For example, what originally required several people to repeatedly enter, verify, and coordinate can now be mostly handled by the system, with only exceptions sent to humans; or customer service that originally needed to handle large numbers of repetitive questions daily can now have AI take on a significant portion. As long as this effect can be truly observed and quantified, bosses easily understand its value.

The second key is not to communicate with traditional enterprise bosses using "software subscription fee" language at the start. The moment you say how much annual subscription fee, they easily associate it with Tencent Video, iQiyi, or various software they rarely use but that charges monthly. They naturally feel a subscription is an ongoing cost with uncertain value.

What we more commonly use is "digital employee annual salary." Strictly speaking it's not a real digital employee, but for traditional enterprise bosses it's a more understandable value language.

Bosses are very familiar with human cost. They know how much salary, social security, and benefits an employee costs per year, plus recruiting, training, turnover, and management costs. When we tell them this system can take over part of what several people used to do, and its annual fee is equivalent to a digital employee's annual salary, they can more easily compare and make decisions.

For example, after a system is validated, if it can save the enterprise 100,000, 200,000, or more in actual labor costs per year, we can discuss taking a percentage of the value created as a service fee—maybe 5%, 10%, or 20%. As long as the calculation method is transparent, enterprises usually accept it.

But here we also need to distinguish "value pricing" from "pure result guarantee." Not all projects are suitable for promising "if it doesn't deliver results, no charge at all."

Some results are very easy to attribute—like how many orders the system actually processed, how much manual entry time was reduced, how much correction rate dropped. These types of projects can use per-volume billing, cost savings revenue sharing, or base fee plus performance bonus.

But brand lift, sales growth, and customer conversion are often simultaneously affected by product, price, channel, and market environment; it's hard to attribute all results to FDE. If we directly commit to pure performance payment before metrics, baselines, and both parties' responsibilities are clearly defined, disputes will easily arise later.

So a more realistic approach is to first clearly define the original baseline, measurement metrics, and variables both parties can control before project start. For parts that can be clearly attributed, bill by result; for pre-diagnosis, system development, deployment, and maintenance, keep base or milestone fees.

The "selling outcomes" I understand doesn't mean the service provider takes on all of the enterprise's uncontrollable risk, but that the entire project's value judgment must end with business results, not just because feature development is complete and the project is declared a success.

Q10: If you could give only one piece of advice to enterprise decision-makers, AI entrepreneurs, and engineers in transition, what would it be?

Lawted: If I could only give one piece of advice on "how to truly deploy AI," I think the first thing isn't to keep taking courses or read more industry reports, but to use Claude Code at high intensity, and use it to build a large number of things you always wanted to do but never did because of time and cost.

Many people say they've used Claude Code, but if you coded the way you did before and only handed part of the code to Claude Code, I think that's not enough. The real qualitative change comes from using it at high enough frequency that you start reunderstanding what an Agent is, what an Agent can take on, and how far one person's capability boundary can be amplified.

My own obvious qualitative change was after I started using the $200/month plan. At that time I was maintaining many products simultaneously, made about eight or nine relatively complete products in one month, started over ten projects. It was at that stage that I truly realized how much one person plus AI can do.

In the past, if I thought of an idea at 3 AM, I might jot it down and say do it in a few days, and most likely never did. But now I can open my computer, clearly explain the background, users, requirements, and desired outcome, and let the Agent start working. By the next morning, I might already see a runnable version, then publish, find first testers, and iterate based on feedback.

Only when you continuously go from idea to product to real users at this frequency will you truly understand Agent capabilities, rather than staying at "it can help me fill in code."

So whether you're an enterprise decision-maker, an AI entrepreneur, or an engineer preparing to transition, I suggest you first continuously produce enough small projects. These projects can't just be demos sitting locally for self-admiration; best if they can be truly published, attract real users, even if at first only ten people use them.

My second piece of advice is that everyone preparing to transition into FDE should seriously consider doing self-media—that is, Build in Public. Because one of FDE's most difficult problems isn't coding, but customer acquisition and building trust. How do you let enterprises know you can solve problems? How do you let the next client believe you don't just make demos? One of the most effective methods is to continuously record the problems, thinking process, failures, results, and methods you encounter in real projects.

If you don't do public expression at all, just keep delivering project after project with your head down, you easily revert to traditional outsourcing. After the project ends, experience stays only in your head; no brand, methodology, or new customer source is formed, so there's no compound interest.

For enterprise decision-makers, I think there are three signals to judge whether your team needs an FDE.

The first signal is that you already have obvious AI anxiety. You know peers are starting to use AI, know the enterprise needs to change, but no one internally can make this concrete.

The second signal is that your company is still continuously hiring people to do repetitive work that you intuitively feel AI can already replace—like data entry, organizing, reviewing, order coordination, information搬运, and repeated communication.

The third signal isn't necessarily cost reduction and efficiency gains; it's that you simply hope the enterprise keeps improving. Some bosses don't have very specific KPIs, don't necessarily require immediate profit growth or immediate cost reduction, but hope that looking back five years from now, starting AI today was the right decision.

As for how to choose an FDE or FDE service provider, I think it's hard to give an absolute standard now because the market is still early and truly mature service providers are few. But one principle is: don't over-worship titles, elite school backgrounds, and various packaging. The most important thing is whether the other party can continuously produce things in a very short time.

I'd suggest enterprises don't sign a very large contract at the start, and don't choose based only on PPT and titles. You can first pay for one real, small-scale, high-intensity collaboration and see if the other party can enter the field, understand the business, quickly build, and continuously deliver.

FDE ultimately doesn't prove itself through persuasion; it proves itself by producing visible results in a very short time.

---

Original publication: https://uniqueresearch.substack.com/p/src-20260707-01html
On-site reading page: https://ffcap.cn/en/research/src-20260707-01html