Thirteen Questions on FDE

This is a warm-up interview held ahead of the 2026 Feifan Awards (Shanghai · AI Business Summit, July 15–16). The interviewee is Ha7ch founder Lawted (Wu Mingze). The following is organized according to the original interview's five parts and thirteen questions, with the answers kept as close to the original wording as possible.

I. Identity Check: From Engineer to Ha7ch Founder

Q1｜Your resume spans a lot of ground — a master's in Design Engineering from Harvard, a research assistant at Stanford HAI, a former engineer at Alibaba/Tencent/MiniMax, and now the founder of Ha7ch (an FDE community and incubator). How did this shift happen — going from an "engineer who writes code" to building an FDE community? Was there a specific trigger?

This shift happened around April this year. Back then I got to know a friend who'd spent ten years in logistics, and we often had meals together. Lobster was really hot at the time, so through "packing lobsters" he introduced me to a friend of his — the boss of a freight forwarding company.

At first we went over just under the pretext of packing lobsters and meeting friends, but as we kept talking we discovered this boss hadn't even really used an AI product like Doubao.

That hit me hard, because a lot of what I'd been exposed to before came from Silicon Valley, Stanford, or the most cutting-edge research and products in the AI industry. In that context, everyone was talking about Agents, model capabilities, workflows, and all sorts of new technical paradigms. But once I was at a real enterprise site, I suddenly realized that AI is actually still very far from huge numbers of ordinary companies and ordinary people — there's a massive gap in between.

What's even more interesting is that these bosses aren't without anxiety. He knew perfectly well that AI is happening, and he knew his company should be putting AI to use, but he didn't know where to start, didn't know what problems AI could actually solve, and didn't know who to hire to do it.

Later we went right into his business on-site and watched how the order operators work every day. A lot of the work still relies on WeChat, Excel, PDF, and manual copying — reading documents, entering fields, checking information, handling exceptions. We quickly saw that there really were plenty of steps here that AI could optimize and make more efficient.

That experience made me feel very clearly, for the first time, that AI's real opportunity might not lie only in creating more cutting-edge technology, but in bringing technology that already exists into real industries.

From then on, my perspective began to change. I no longer just focused on the most cutting-edge overseas research and products, and I no longer saw myself only as an engineer who writes code. Instead I started putting more energy into enterprise sites — understanding real workflows, judging which problems are worth solving with AI, and then quickly building systems that can be validated.

That was also the trigger point where I really started doing FDE.

Follow-up｜How does a design engineering background (which emphasizes human-computer interaction and systems thinking) shape the way you understand FDE now? And how does that differ from the perspective of a founder with a pure computer engineering background?

As for how the design engineering background shapes my understanding of FDE — first, I wouldn't claim I'm already defining the industry standard for FDE. I'm more like putting forward an observation and a classification.

For example, I divide FDE into the "big-tech, platform FDE" and the "scrappy FDE" — the scrappy, entrepreneurial FDE who goes into small and medium-sized enterprises on their own and handles both demand discovery and delivery themselves.

The reason I can see the difference between these two kinds of FDE is inseparable from my design engineering background. Design engineering demands that one person understand product, design, engineering, and human behavior all at once. You can't only understand technology, and you can't only know how to run interviews.

You have to actually get inside the enterprise, talk with the boss and the frontline employees, and understand what they really need — while also understanding the boundaries of AI's capabilities, and having personally used Agents, Claude Code, and other tools intensively across a large number of projects, so you know whether an idea can quickly turn into a demo and whether it can actually go live. Only when all of these abilities exist at the same time can you understand what FDE is really about.

The biggest difference between me and founders with a pure computer engineering background is probably that I don't worship technology all that much. For me, what matters most isn't how new the technology being used is, but understanding the boundaries of technology and then quickly delivering a solution that's genuinely useful.

Many technical founders might start from technical innovation, first asking, "I've got a new model, a new algorithm, or a new architecture — what can I do with it?" Whereas I'd rather start from human needs and workflows, first asking, "What problem is this person facing right now, and what solution can help them most effectively?"

If technology from ten years ago could already solve the problem well, I'd use ten-year-old technology too, because what enterprises actually buy isn't whether the technology is new or old — it's whether the problem gets solved.

I think the biggest influence design engineering has had on me is that it keeps me always starting from people and their needs, while retaining enough engineering ability to quickly turn that need into a system that can be validated.

Q2｜Ha7ch's website says it's an "AI-native Builder Lab born at Stanford, the world's first FDE Accelerator." Why "Accelerator" and not a "training program" or a "consulting firm"? What's the biggest difference between an FDE accelerator and a traditional YC-style startup accelerator?

Follow-up｜What are you actually accelerating — "people" (a Builder growing into an FDE), "projects" (a product from zero to one), or "companies" (an AI-native startup)? How do you rank those three within Ha7ch's system?

Ha7ch's earliest origin was really back when I was a research assistant at Stanford.

At the time, some friends and I were discussing one thing: whether a genuinely AI-Agent-facing product form would emerge in the future. Back then we ran a lot of experiments around Claude Code. What we wanted to build wasn't simply bolting AI onto an existing product — we wanted the product to be AI-native from the very start.

In other words, its interaction model, its workflow, and its underlying logic would be designed from the ground up for an Agent to use, to collaborate with, and to get tasks done.

Later, after I came back to China and started dealing with real companies, I found that this actually lined up perfectly with what companies needed.

Of course companies want to become more AI-native — they want to use AI to boost efficiency, cut costs, even rebuild the way they work. But the problem is: who maps out the business, who decides where AI actually fits, and who turns those needs into a product that genuinely runs?

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

The reason we call ourselves an Accelerator rather than a training program is that an FDE fundamentally isn't something you learn by taking classes. It requires actually going into a company, being deployed on-site, talking to the boss and to frontline staff, and dealing with unclear requirements, legacy systems, internal resistance, and real business pressure.

None of that is easy to simulate with a curriculum.

In particular, a lot of people who have already worked for years and carry family responsibilities don't necessarily have enough time or room to fail to keep dropping into different company settings. So in the beginning we focus more on students and young Builders.

These people have more flexible schedules, are willing to use the latest AI tools, and are more willing to step into an unfamiliar industry and re-understand the problem from scratch.

What we want to give them isn't an FDE course but a real testing ground — a chance to go into a company and see whether they can actually understand the business, whether they can find the real problem behind the boss's surface-level ask, and whether they can build something that frontline staff genuinely accept.

At this stage, the most important thing is to let them actually try it once, and then get feedback from the company's boss and its frontline users.

Because a lot of what Builders make right now is essentially a toy demo — it looks cool, but it isn't solving a real problem. What they lack isn't one more tutorial to read; it's a chance to get into the field and actually solve the real problem.

This is also where Ha7ch resembles YC.

A big part of YC isn't just the money — it's that YC forms a kind of alumni culture, a high-density network, and a form of credentialing. When a founder gets into YC, it means they've entered a network where excellent founders connect with and help one another, and at the same time YC itself becomes a form of market trust.

Ha7ch wants to build something similar in the FDE space.

Right now anyone can call themselves a Builder, and anyone can change their title to FDE. But who actually has the ability to go into the field, who can map out a workflow, who can talk to the boss and to frontline staff, who can handle the tangled problems sitting between business, product, and engineering — the market really has a hard time telling.

In the future, if someone is one of Ha7ch's earliest FDEs who grew up inside real company settings, that fact itself should become a form of credentialing.

We've already held offline events in cities like Beijing, Shanghai, Shenzhen, and Hangzhou, connecting a large number of people doing AI implementation, Builders, industry practitioners, and enterprise resources. This network is itself continuously generating value.

For example, someone who had just arrived in Shenzhen and had almost no local friends went to a single Ha7ch offline event, and later, through the people they met there, got connected to enterprise resources and new opportunities. This kind of high-quality person-to-person connection is also something I very much want to build for the long term.

But the biggest difference between Ha7ch and YC is that YC's core starting point is giving companies capital and then helping the company grow fast; Ha7ch's core starting point is giving people real settings and then helping a Builder gain industry capability.

YC's basic unit is the company; our basic unit right now is the person. YC uses money to lower the barrier for a founder to start a company, whereas we use the company's field to lower a Builder's barrier from "can build a product" to "can solve a real problem."

YC usually accelerates a project or company after it has already appeared, whereas Ha7ch sits further upstream — we accelerate the process of a person becoming an FDE, and even the process of a person finding a problem worth building a company around.

Another difference is that an FDE can naturally generate cash flow. As long as a Builder genuinely solves a problem for a company, they can potentially earn revenue from the project, so they don't necessarily need to raise investment first to start down this path.

What we provide isn't a check but a real problem, an entry point into a company, a group of peers, and a chance to complete a first real delivery.

So among the three — people, projects, companies — what Ha7ch is most clearly accelerating right now is people.

Projects are the training ground, but they aren't the asset Ha7ch ultimately wants to own; a company may be a long-term outcome, but it isn't a goal we're forcing at this stage.

We run the Ha7ch 48-Hour FDE Sprint, dropping Builders into real companies and having them, in a very short time, map out the company's pain points, reconstruct the workflow, find the parts suited to AI-driven efficiency gains, and then build a demo strong enough to give the boss and frontline staff a visceral, tangible feel for it.

Our role is to match the right people with the right companies and to provide the method and the environment.

Afterward, if the two sides want to sign a contract and pursue commercial delivery, that can be handled by another commercial entity or driven by the Builder themselves — it doesn't have to be tied to Ha7ch. Ha7ch would rather stay in the role of a talent network and an experimental field.

So the three should be ordered like this: first accelerate the person, then validate the person through projects, and finally some of those people may, out of a string of projects, discover a genuinely recurring industry need and go on to found a company.

Over the long run, we hope the companies these Builders have served will also gradually become more AI-native.

Because the people we screen for and cultivate already think about problems in an AI-native way — they won't just think about bolting a chatbot onto a company; they'll re-examine the workflow, the way the organization is structured, and the product architecture.

Of course, what solution ultimately gets adopted still depends on the company's specific situation, rather than forcibly changing everything just to chase the AI-native label.

Q3｜You run a personal account on Xiaohongshu, and your content style leans toward "engineer narrative + entrepreneurial thinking." Does this account actually help Ha7ch with customer acquisition and brand? Or is it more of a personal outlet for you?

Follow-up｜Are you yourself also playing the role of a "super FDE" — going deep into the industry's front lines, then abstracting that experience into methodology?

Actually, I'm already slowly drifting away from the "engineer narrative."

In the past, people probably felt my content was more about talking about technology, engineering, and projects, but now what I want to express more is entrepreneurial judgment, the customer's front line, and FDE-related thinking.

I no longer spend a lot of time separately explaining some model, some framework, or some new technology. Instead, I pay more attention to what scenarios these technologies ultimately enter, what problems they solve, why some projects can get deployed while others just stop there once the demo is done.

For me, the more important role of this account now is not to show how much technology I understand, but to get different kinds of people to connect.

A Builder can see through the content what's actually happening inside real companies; a business owner can understand through the content what an FDE can actually do for them; and people who are already doing deployment work can exchange their respective judgments and experiences here.

This account is of course a very substantial help to Ha7ch, because at this stage the whole of Ha7ch still depends to a large degree on my personal IP.

Many people don't get to know Ha7ch first and then get to know me; instead, they first see my content, agree with my judgment, and only then enter Ha7ch's events and network.

I hope Ha7ch can gradually form its own brand and organizational capability in the future, but I also don't think it should be completely detached from the individual.

Especially since FDE work is itself something highly dependent on trust, front-line experience, and concrete judgment — if you turn Ha7ch into a fully institutionalized brand with no expression from specific people, it can easily lose that "living human" feel.

That's not a good thing for FDE, because in the end companies aren't buying an abstract concept; they're judging whether this group of people really understands the front line, whether they dare to take on responsibility, whether they have real experience.

So Ha7ch can gradually stop depending only on me, but it can't turn into an organization that's all official slogans and no specific people.

As for whether I'm playing the role of a "super FDE," I think to some extent I am.

These days I go into the front lines of many different industries — factories, logistics companies, cross-border teams, racing teams — talking directly with the top boss of a company as well as with frontline employees.

Because we want to invite these companies to join Ha7ch's hackathons or FDE Sprint, I not only need to explain FDE and AI-driven efficiency to them, but also to get them to understand what Ha7ch wants to do, why it's worth opening up their real problems, and what they can get out of it.

This process is itself part of FDE work: first build trust, then understand the business, and finally find a problem suitable to be validated.

These front-line experiences have also had a huge impact on me personally.

When I used to work at tech companies like Alibaba, Tencent, and MiniMax, even though I came into contact with a lot of complex software systems, I actually didn't have many chances to really see how the world we live in gets produced.

After going into factories, for the first time I seriously watched how an assembly line runs, how hardware gets manufactured, how workers and managers collaborate, how an order, a part, or a product comes into being through a whole series of real processes.

These experiences don't just help me understand FDE; they're also enriching my understanding of business, of industry, and even of how society as a whole operates.

But if you're asking whether I've already abstracted these experiences into a complete methodology, I don't think I've reached that stage yet. It hasn't yet reached the point where quantitative change produces qualitative change.

On the community-operations side, I've probably already accumulated some relatively clear methods, but FDE itself is too fragmented; different industries may need completely different solutions.

A logistics company might need AI plus ERP, or a document digital worker; a cross-border business might need an Agent workbench; a racing team might need Feishu agents and a knowledge base; a manufacturing company might instead care about visual inspection, patrol inspection, or the production process.

Their technical forms, organizational structures, evaluation metrics, and value logic are all different, so if I said right now that I've already formed a complete methodology applicable to all industries, I think that would be dishonest.

What I believe more now is that part of FDE ability can be trained, but it's impossible to quickly turn someone into a senior FDE through a single course, just as it's impossible to produce a senior consultant through a few months of courses.

Real industry judgment and front-line experience take time to accumulate.

But we can train a person with potential and make them an excellent junior FDE, or a "consulting intern": someone with strong learning ability and initiative, willing to go into the front lines, able to proactively probe for business problems, who knows how to interview frontline employees and dares to keep pressing on the surface-level needs a customer raises.

What Ha7ch really wants to do at this stage is exactly this: first discover and train this underlying ability, then let these people gradually grow their own industry experience and judgment through one real project after another.

II. Defining the FDE: Old Wine in a New Bottle, or a New Species?

Q4｜In 2025-2026 the concept of the FDE (Forward Deployed Engineer) blew up, and some people are skeptical: isn't this just the old "on-site engineer" or "outsourced delivery" with an English title slapped on? As one of the earliest people to systematically promote the FDE in China, how do you answer that?

Follow-up｜At its core, how is the FDE you define different from Palantir's original FDE, and from the FDEs that model companies are hiring now? Is there something uniquely "Chinese-style FDE" about it?

I once recorded a video specifically about a "ten-dimension comparison," putting the on-site engineer, outsourcing, consulting, the big-tech FDE, and the scrappy FDE side by side across ten different dimensions.

A lot of people ask me at first: isn't the FDE just the old on-site engineer or outsourcing with an English title slapped on?

But I think the most fundamental difference between them isn't whether you sit and work in the client's office — it's that the starting point and the ending point are completely different.

The starting point for traditional outsourcing or an on-site engineer is usually a solution that's already basically decided. The client tells you: I want to build a system, add a feature, do multilingual localization; the engineer takes the requirement and is responsible for executing it.

But the FDE's starting point is often an extremely vague problem.

Maybe it's just that you went and packed lobsters once for a logistics boss, and he suddenly says to you: "I want to use AI to boost efficiency too, but I have no idea where to even start."

That is the FDE's true starting point.

There's no PRD, no fixed solution, not even a clear sense of what the problem is.

The FDE has to go on-site, watch how the employees work, talk constantly with the boss and the frontline staff, gradually tease this extremely vague need into a clear workflow, then turn it into GitHub Issues, and only at the end into production-grade code.

The ending point is different too.

The endpoint of traditional outsourced delivery is usually the completion of the product or feature; once it passes acceptance, you get paid. Whether anyone actually uses the product in the end, whether it truly helps the client acquire customers, cut costs, or improve efficiency, is usually outside the outsourcing team's scope of responsibility.

But the FDE puts far more emphasis on delivering for outcomes.

On projects suited to being settled by results, if the system you build can't help the client generate qualified leads, lower costs, or improve processing efficiency, then the thing itself has no value — and it shouldn't earn the full fee just because the code got written.

This willingness to tie your own income to the client's outcomes is what gives the FDE its confidence, and it's one of the most important things that separates it from ordinary outsourcing or on-site development.

Of course, not every project can use pure pay-for-performance, but the FDE's judgment of value must always take the client's outcome as the endpoint, not a feature list.

Take a cross-border apparel company, for example: the boss might only say, very vaguely, "I feel like AI can help me make more money."

In the traditional outsourcing model, you'd usually wait for the boss to first put forward a clear requirement — say, "I want a multilingual version of the site with styling adapted to different regions" — and then the outsourcing company builds it to spec, charges 50,000 yuan, and the project is over.

As for whether the site, once live, actually brings in customers from Spain, Portugal, or anywhere else, that's usually no concern of the outsourcing team's.

But the FDE's work sits much further upstream.

We might first analyze his customer-acquisition methods, his site structure, his target markets, and user behavior, and then discover that right now he only has an English-language site — and one whose wording and design are still very Chinese-style, not suited to consumers in different countries.

Based on that judgment, we might then propose: use AI to rapidly build a site adapted to the languages and cultural habits of eighteen countries, and then verify the results through real traffic and the number of qualified customers.

In that case, the FDE's business model might not simply be "I'll build you eighteen sites for 30,000 yuan," but settling based on the qualified customers or leads it brings in — say, 5 or 10 yuan per qualified customer.

If all eighteen sites get built but bring in no new customers, then commercially those sites are worthless.

Outsourcing delivers eighteen websites; the FDE delivers new customers.

This example makes the difference between the two crystal clear: outsourcing starts from a fixed solution and ends with a completed feature; the FDE starts from a vague problem and ends with a business result.

Of course, the FDE isn't a brand-new species that came out of nowhere; it absorbs part of the capabilities of consulting, product, engineering, pre-sales, and implementation.

But the single biggest variable that makes this model viable today is the Coding Agents like Claude Code and Codex.

In the past, building a set of custom software for a company took a full team — frontend, backend, product, QA, and a project manager — and the cost could run into the millions.

Today, with a Coding Agent, the production cost of that same thing might drop by an order of magnitude.

In the past, small and mid-sized businesses simply couldn't afford custom solutions, but if a solution drops from two or three million to two or three hundred thousand — or even becomes an ongoing service of 40,000 to 50,000 yuan a year — it starts to enter the range that a large number of small and mid-sized businesses can accept.

A delivery that used to take a whole team can now possibly be done by one person who understands the business, the product, and engineering, plus Codex or Claude Code.

So I believe the Coding Agent isn't merely an aid to the FDE — it's the precondition for this wave of FDE to truly take off.

I personally split the FDE into two kinds: one is the big-tech, platform FDE, and the other is the scrappy FDE — that is, the entrepreneurial FDE, or FDE OPC.

The scrappy FDE faces small and mid-sized businesses directly, with no platform he's obligated to sell and no mature product backing him up.

He can freely choose his technology based on what the site needs: use GPT if GPT fits, use Codex if Codex fits; if it calls for an incremental AI-plus-ERP plugin, he builds the plugin; if it calls for a knowledge base, a workbench, or an automation flow, he builds those.

What he ultimately delivers isn't some fixed product, but the solution to the client's problem.

This is also a very big difference between the scrappy FDE and traditional software sales. The scrappy FDE doesn't first ask "what product do I have to sell," but first asks "what does this client actually need."

A lot of people also ask: with this one-person delivery model, how do you handle maintenance down the line?

Take the racing team I currently serve as an example: the client keeps raising new requirements, but the maintenance itself isn't as hard as you'd imagine.

My most important work isn't personally writing large amounts of code every day, but observing their workflow, teasing the requirements into clarity, and then turning them into GitHub Issues.

By evening, I can hand those Issues to Codex or Claude Code to finish.

The part of me that's truly irreplaceable is judging the problem, clarifying the requirements, and defining the boundaries — not mechanically writing every line of code.

As the models keep getting stronger, the implementation of more and more systems will become "get the requirements exactly right, then hand them to an Agent to execute."

So the technical implementation itself will get cheaper and cheaper, while on-site judgment and requirement definition will, on the contrary, get more and more expensive.

The logic of the big-tech, platform FDE is completely different.

Whether it's Palantir, or domestically Feishu, DingTalk, or Alibaba Cloud, they're all essentially based on a mature platform, doing a certain degree of customization for the client.

I once visited a factory in Anhui that had already bought Feishu and purchased AI credits. The Feishu team would then go on to ask whether they needed capabilities like hard-hat detection or smoke-and-fire detection, and then feed the surveillance data into Feishu Base.

Because the client had already bought the platform and the credits, the FDE service might be offered as an add-on.

The FDE sent over may have already done similar projects for twenty or thirty factories; once on-site, he confirms the camera models, the system interfaces, and the workflow, and can finish very quickly.

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

So the big-tech FDE is ultimately usually driving the sale, adoption, or renewal of some product.

Behind the Palantir FDE is Foundry; behind the Feishu FDE are Feishu and Feishu Base; behind the DingTalk FDE is DingTalk; and behind a model vendor's FDE are the models, the API, the Coding Agent, or cloud services.

Their advantages are a mature platform, stable delivery, and strong compliance capabilities, but they also have a built-in limitation: they tend to steer the client's problem toward their own product.

The scrappy FDE's advantages are technology neutrality, flexibility, and the ability to serve the small and mid-sized businesses that big tech can't yet cover, but the risk is that he easily degenerates into low-price outsourcing, and he lacks the brand, engineering, and after-sales guarantees that a big platform provides.

So I think the FDE isn't simply an on-site-engineer reskin.

If you only change the title but still write code to the client's PRD, then of course it's still traditional outsourcing.

The real change has four aspects:

First, the FDE's starting point is a vague problem, not a fixed solution;

Second, the FDE holds the right to define the problem, rather than only being responsible for execution;

Third, the FDE's endpoint is a business result, not merely a finished product;

Fourth, the Coding Agent slashes the production cost of custom software, making it possible for one person or a small team to accomplish work that used to require a full organization.

Without these changes, it's a reskin; with these changes, it's a new mode of organization and delivery.

As for the Chinese-style FDE, I think we're still exploring it.

China has a huge number of manufacturing, logistics, cross-border trade, and traditional service businesses, and inside them there are enormous amounts of order-operating, order-dispatching, reviewing, routing, data-entry, and communication processes — work that's very well suited to being partly automated by AI.

But the Chinese market also has a very real contradiction: the price businesses are willing to pay is relatively low, while the labor cost of a mature FDE right now is relatively high.

Palantir tends to serve projects worth millions, tens of millions, or even more, but a large number of small and mid-sized Chinese businesses can perhaps only accept a budget of tens of thousands to a few hundred thousand yuan.

This means the Chinese-style FDE has to be lighter, faster, and more reliant on Agents, and put more emphasis on embedding into existing systems rather than rebuilding a whole platform.

In the future, as more big-tech engineers and product talent enter the market, and as Coding Agents further raise individual productivity, the supply of FDEs and the price businesses can accept may reach a new equilibrium.

I believe the form the Chinese-style FDE is most likely to take is not a miniature Palantir, but a large number of small teams and super-individuals who understand their industry, understand communication, and can independently complete delivery with the help of Agents.

Q5｜The core paradox of the FDE model is this: you have to "go deep into the client's site and do custom work" (which doesn't scale), and also "abstract that experience into products/methodologies" (which does scale). Palantir solved this with the Ontology model. How do you think an FDE should handle the tension between customization and scale — one SOP per industry, or a common core plus an industry-adaptation layer?

Follow-up｜Is there any industry whose knowledge "can't be abstracted" — where you have to go on-site and figure it out from scratch every time? What industry is that?

I think the way an FDE scales doesn't necessarily start with turning every industry into a standardized product; it comes from a person's abilities being replicable and amplifiable.

A mature enough FDE, especially an FDE in the OPC form, isn't necessarily limited to a single industry.

Because a lot of enterprise scenarios belong to different industries on the surface, but the workflows that actually need solving are in fact highly similar.

Take order entry, order operating, review, breaking documents apart, field extraction, exception handling — whether these happen in selling clothes, selling shoes, logistics, or cross-border trade, the underlying structure is pretty much the same.

Of course we need to pick up a certain amount of domain knowledge, but it's not like every time you enter a new industry you have to understand all of that industry's knowledge from scratch.

The key is to distinguish between two kinds of problems.

The first kind is core professional judgment — like which clothes are worth selling, which shoes will become bestsellers, which medical device is safer, whether a given diagnosis holds up.

These problems really do depend heavily on industry experts, and they're hard for a generalist FDE to transfer into quickly.

The second kind is the repetitive workflows embedded inside an industry — data entry, splitting, organizing, checking, templating, approvals, and exception handling.

An FDE is better suited to going after the second kind first, because these processes have a lot in common across industries.

For example, when we worked on a medical-device scenario, we weren't having the AI judge which medical device is better, nor were we having the system replace doctors or professionals in making critical judgments — we were handling the huge amount of dirty, grinding, repetitive work inside it.

For instance, breaking design drawings down into parts, organizing them into templates, classifying fields, or automating processes that used to need people to handle them over and over.

That way you produce clear value without crossing the line into professional judgment.

So I don't think an FDE has to first become a ten-year expert in an industry every time they enter a new one.

What's really transferable is the ability to identify workflows, judge what's suitable for automation, quickly build thin slices, and push things into production.

From that angle, I lean toward "a common underlying capability plus the necessary industry adaptation," rather than independently developing a whole heavy methodology for every single industry.

A great FDE can work across multiple industries, but they have to know what can transfer and where they must rely on domain experts.

What transfers is workflow judgment and engineering ability; what doesn't transfer easily is the critical professional decisions.

As for Palantir using the Ontology to solve the customization-versus-scale problem, I think you first have to understand what the Ontology actually solves.

It's not just about uniformly modeling the objects, relationships, and actions inside an enterprise; more importantly, it builds a governance layer in a complex organization that is traceable, auditable, and capable of access control and data-compliance review.

Where a piece of data came from, what processing it went through, who has permission to view it, who made what decision, and whether accountability can be assigned when something goes wrong — these matter enormously for governments, large financial institutions, multinationals, or heavily regulated industries.

So Palantir's Ontology is essentially not just solving software reuse — it's also solving data governance, lines of responsibility, and compliance in complex organizations.

But I don't think every Chinese company needs to copy this path wholesale.

For large enterprises and heavily regulated industries, this Ontology layer can be extremely valuable; but for the vast number of small and medium-sized businesses in China, it's often too heavy.

What a lot of SMEs need to solve first isn't whether a decision can be fully audited, nor how to unify data permissions across departments and countries — it's that today there are still five employees entering orders by hand, one PDF has to be copied twenty times, and a single order has to be confirmed back and forth between WeChat and Excel.

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

A lot of the projects we deal with aren't million- or ten-million-yuan mega-deals; they're real needs in the range of tens of thousands to hundreds of thousands of yuan.

In that situation, if you start out building a complex ontology, a unified data model, and a large platform, the client's budget may be gone before they've even seen any value.

It's like solving a simple problem — you don't need to build an extremely complex solving system first.

For SMEs, the more realistic approach is to first find a high-frequency, clearly bounded process, do it well with AI or a digital employee, and then gradually add permissions, logging, traceability, and audit capabilities according to the company's size, risk, and compliance requirements.

Not every company needs a shrunk-down Palantir; what they need more is a lightweight, fast solution that can embed into their existing systems.

So the way I understand scaling isn't cramming every client into the same platform — it's three things:

First, training up the FDE's ability to identify problems and break down workflows;

Second, accumulating the components, templates, and delivery methods that recur across industries;

Third, where it genuinely involves critical industry judgment, data governance, and compliance responsibility, bringing in domain experts and a more complete audit system — instead of pretending one general-purpose model can solve everything.

III. Ha7ch's Real Status

Q6｜Ha7ch has now built local networks in Beijing, Shanghai, Shenzhen, and Hangzhou. Roughly what scale is the Ha7ch community at right now? How many active Builders are there? On average, how long does it take to go from "joining the community" to "becoming an FDE who can be deployed on-site independently"?

Follow-up｜Between university students and "lateral-hire" engineers, which group is better suited to being an FDE? Are the university partnerships signed as framework agreements, or is there actual course, credit, or hands-on training embedded in them?

The Ha7ch community right now is at roughly over 2,000 people, and of those, the ones who are relatively active — who keep an eye on FDE, AI deployment, and Builder-related opportunities — number somewhere around 500 to 1,000.

This measure of "active Builder" doesn't mean all of these people can already do FDE work independently; it means they keep taking part in discussions, show up to offline events, follow real projects, or are themselves already building AI applications and doing enterprise deployment.

Our network now reaches beyond China — we've held events in Beijing, Shanghai, Shenzhen, and Hangzhou, and we're starting to build offline connections in Silicon Valley too.

The people we meet in Silicon Valley are more often big-tech, platform FDEs, or people who want to get into companies like Google, OpenAI, or Anthropic to do customer engineering, model deployment, and enterprise deployment.

In China, and especially in Shenzhen, there are a lot of people who are closer to the scrappy FDE or the FDE OPC — they deal directly with small and mid-sized businesses, and a single person or a small team handles demand discovery, product design, and delivery.

As for how long it takes on average to go from joining the community to being deployable on-site independently, we don't yet have a mature, trustworthy set of statistics.

Because what Ha7ch does right now is mainly not a training mechanism, but a screening mechanism.

The first thing we have to figure out is: what kind of person genuinely has FDE potential, what kind of person can only build a demo, and what kind of person can walk into the site, talk to both the boss and the frontline staff, and turn a fuzzy problem into a system that actually runs.

I think an FDE is very hard to mass-produce through a short course; it takes real projects, industry experience, and repeated on-site feedback.

So for now we'd rather first establish the screening criteria — for example, using Echo and Delta to judge whether someone lacks demand-discovery ability or end-to-end build ability — and then match the right people to the right enterprise scenarios.

Even if we can't yet give a single unified training timeline, as long as we can raise the accuracy with which the whole industry screens for FDEs, I think that in itself is a kind of positive infrastructure.

University students and lateral-hire talent each have their own strengths.

A student's biggest advantages are strong initiative, fast learning, more flexible time, and very high openness to new tools like Claude Code and Codex.

They're willing to step into an unfamiliar industry, and they're more willing to spend a day or two straight doing intense on-site research and prototyping.

But they usually lack experience communicating within a company, they don't understand the web of interests inside an organization, and they don't necessarily know what resistance a system will run into on the way from demo to launch.

Lateral-hire talent, on the other hand, shouldn't be understood as just engineers.

In fact, people who've worked as product managers, in operations, in solutions, in consulting, or in startups may more easily have the Echo an FDE needs than a pure engineer does.

They already have mature experience in communication, coordination, and business judgment; they know how to talk to a client, and they know how to sort out the problem from a mess of information.

A pure engineer's Delta tends to be strong, but if they're long used to waiting for a clear PRD and unwilling to meet clients, they aren't necessarily a natural fit for FDE work either.

Of course, the real problem with experienced talent is that they have less time and higher opportunity cost — a day of on-site work costs far more for them than for a student, and they find it harder to accept a stretch of exploration with no steady return.

So I don't think there's an absolute better-or-worse between students and experienced talent.

A student is more like a high-potential, low-cost Builder who needs to grow on-site; mature product, operations, or industry talent has a stronger foundation in communication and business, but needs to shore up their AI-native build ability.

The ideal team is often a combination of the two, rather than pulling people from only one kind of background.

University partnerships are still in an exploratory phase for now.

We'll try lectures, workshops, real enterprise problem sets, and FDE Sprints, but we're not yet at the point where we can claim to have built a mature curriculum, a credit system, or a mechanism for training talent at scale.

Ha7ch has really only been doing FDE content and community systematically for a little over a month — no more than sixty days — so it's still a very early stage right now.

At this point, what matters more is honestly distinguishing what has already happened, what is being validated, and what is just a long-term vision.

If any organization claims, in this short a time, that it has already fully run through multiple industries and built a mature training system, I'd look at that pretty cautiously.

We'd rather first screen the right people and do the first real project well, and then gradually answer the questions of average training time and scaled-up partnerships.

IV. Cognitive Reversals and Industry Judgment

Q7｜You've worked as an engineer at Alibaba, Tencent, and MiniMax, and now you're out on your own building Ha7ch. Is there anything like an FDE role inside big tech companies — solutions architect, customer success engineer, that sort of thing? How do you see the relationship between the big-tech, platform FDE and the independent FDE?

Follow-up｜If ByteDance or Tencent announced tomorrow that they were setting up an "FDE middle platform" and deploying on-site engineers to all their enterprise customers, where would the value of the independent FDE and the FDE community be?

I don't actually think of what I'm doing right now as building so-called "FDE infrastructure." A more accurate way to describe my position is that I'm building an FDE community — connecting different kinds of Builders, companies, and the people who are actually out there doing the deployment work.

Big tech companies obviously already have roles that come very close to FDE. Feishu, for example, already deploys engineers to enterprise customers to help them combine Feishu, Feishu Base, AI capabilities, and their existing workflows.

So I don't think big tech is incapable of doing FDE well, and I don't think the FDE has to exist independently, outside of big tech.

The more accurate judgment is that there's a very clear market split between the big-tech, platform FDE and the scrappy FDE, the FDE OPC.

Some large AI service companies or platform vendors can serve a big bank like HSBC, because those customers have enough budget and also have complex security, compliance, audit, and systems-integration requirements — they need a mature brand, a complete platform, and a large delivery team to support them.

But the scrappy FDE usually doesn't enter that kind of market. It serves the vast number of small and medium-sized companies — small logistics companies, cross-border trading companies, regional manufacturers, or traditional service-industry firms.

These companies may not even be willing to buy the flagship version of Feishu — not necessarily because the product is bad, but because they think their existing tools are already good enough, and they're unwilling to keep paying a relatively high fee for a large, general-purpose platform.

In this situation, the big-tech FDE and the scrappy FDE face completely different customers, budgets, sales approaches, and delivery models.

The core goal of the big-tech FDE is usually still to help the company sell, deploy, and renew an existing general-purpose product.

Feishu's FDE ultimately has to drive usage of Feishu, Feishu Base, and AI credits; Alibaba Cloud's team has to drive consumption of cloud services, models, or Tokens; and other model vendors likewise want customers to use their APIs and platforms more deeply.

The FDE here is a very important form of added value — it helps customers bring general-purpose products down into specific scenarios, and it helps big tech lower the barrier to customer adoption. But in the end it still serves the growth of the platform product.

The logic of the scrappy FDE is the opposite: there's no platform it has to sell, so it can freely choose tools based on the customer's problem.

If the customer needs Feishu, use Feishu; if they need DingTalk, use DingTalk; if they need a custom-built plugin, build a plugin; and if ten-year-old technology can solve the problem, there's no need to force the use of the latest model.

So it's not a matter of one replacing the other — they serve different tiers of the market.

If ByteDance, Tencent, Feishu, or Alibaba announced tomorrow that they were setting up an even bigger FDE middle platform, I don't think it would directly wipe out the scrappy FDE. If anything, it might further educate the market and help more companies understand what an FDE is.

Big tech will prioritize serving large customers with bigger contract sizes — the ones who can buy platforms and cloud resources. There's no way they'll pour large amounts of pre-sales and on-site resources into every small business whose annual budget is only a few tens of thousands of yuan.

And the opportunity for the scrappy FDE lies precisely in that highly fragmented, non-standardized, budget-limited, but demand-rich market of small and medium-sized companies.

Its competitive edge isn't that its technology is more advanced than big tech's, but that it's lighter, faster, more flexible, and more willing to start from a very small, concrete problem.

Of course, the scrappy FDE can't simply position itself as "cheaper outsourcing."

If it's just writing code on the cheap, big tech doesn't need to step in personally — traditional outsourcing companies can already handle that.

The scrappy FDE's real competitive edge should be technology neutrality, problem orientation, and an extremely low cost of delivery.

It can go on-site, untangle a vague problem into something clear, use Agents to quickly produce results, and not require the customer to first procure an entire platform.

In the long run, the big-tech FDE will keep serving large enterprises, making its mature platform deeper; the scrappy FDE will cover the vast number of small and medium-sized companies that big tech can't serve economically.

The two aren't in direct competition — it's more like a layered market.

Q8｜You used to run a Web3 project, and now you're all in on AI plus FDE. That whole Web3 ethos of "decentralization" and "community self-governance" — how does it shape how you run the Ha7ch community now? Or has that chapter already been "wiped clean" for you?

Follow-up｜Does the Ha7ch community borrow any governance mechanisms from Web3? For example, how do you quantify a Builder's contribution, and how do you incentivize it?

Oh my God, so even this chapter got dug up.

I did run a Web3 project before, called Snails Finance.

That experience does still have some influence on how I run Ha7ch now, but I'm not going to copy over the DAO, the Token, or a fully decentralized governance mechanism from Web3 as-is.

What I actually kept is the idea that a community shouldn't be run forever in one direction, top-down, by the founder alone.

A community with real life in it should let members gradually take part in building it, form a sense of identity, and grow their own local networks in different cities.

The structure we're building right now is Meetup, Guild, and GuildUp.

At the very start, someone can enter the community through a Ha7ch city Meetup.

The Meetup is more like a doorway — its job is to let new people get to know FDEs, and to get to know the local Builders, companies, and industry practitioners who are doing AI deployment.

After attending a Meetup, they can enter the Guild that corresponds to that city.

A Guild isn't a one-off event group chat — it should become the FDE network that exists for them long-term in that city.

For example, Beijing, Shanghai, Shenzhen, Hangzhou — each city can gradually form its own Guild.

Each Guild will also have relatively active leads or organizers.

They aren't necessarily "branch office heads" in the traditional sense — they're more like the conveners of the local network.

They'll regularly organize meals, coffee meetups, company visits, or small gatherings, and we call this kind of ongoing get-together a GuildUp.

The point of GuildUp is to get people who've been to a Meetup once to keep meeting up, to understand more about what each other is working on, and to deepen their understanding of FDEs, of the industry, and of how companies actually deploy.

I think GuildUp is absolutely necessary.

The problem with a lot of communities is that people meet once at an offline event, add each other on WeChat, join a group chat, and then the relationship just stalls there.

A single Meetup can generate a huge number of weak connections, but without follow-up, small-scale, high-frequency interaction, those connections rarely turn into real trust, and they rarely produce project collaboration, career opportunities, or industry knowledge exchange.

The value of GuildUp is to gradually turn one-off weak connections into long-term strong connections.

So Ha7ch's growth logic isn't to keep pulling everyone into one ever-larger WeChat group.

Overall, Ha7ch will keep hosting Meetups to connect new Builders and companies; the city Guilds take in the people who've already entered the network; and GuildUp lets existing members keep forming deeper relationships with each other.

This forms a layered structure: Meetup handles acquiring new people, Guild handles forming a city identity, and GuildUp handles increasing connection density.

That's mainly where my Web3 experience shows up.

I believe community members can jointly take part in governance and operations, and a city network shouldn't depend entirely on me personally.

But I won't treat "decentralization" as the goal.

Especially once Ha7ch moves into real corporate projects, there still has to be a clear person in charge, quality standards, and clear boundaries of responsibility.

Community activities can be co-built by members, but commercial delivery can't run on votes, and when a project fails, no one can be left unaccountable just because "everyone governs it together."

As for how to quantify and incentivize a Builder's contribution, we're still at a fairly early stage right now, and I don't want to introduce points, a Token, or a complex set of gamification mechanics too soon.

The contributions that are genuinely valuable in the future might include organizing GuildUps, connecting corporate resources, sharing real cases, helping other Builders, taking part in the FDE Sprint, and distilling project experience back into the community.

But these contributions won't all necessarily be well-suited to simply being converted into a single number.

What I'd rather Ha7ch end up forming is a reputation and identity system.

When someone consistently organizes events in a city, helps members, and completes real projects, everyone naturally knows who they are and trusts their ability.

The best incentive for them isn't necessarily points either — it might be higher-quality connections, corporate opportunities, industry influence, and the identity of being the representative figure of that city's Guild.

So that Web3 chapter hasn't been wiped clean for me — what I kept is the value of community co-building, identity, and network, and what I gave up is decentralizing for the sake of decentralization.

Ha7ch can be run by more people together, but in the end it still has to center on real connections, real contributions, and real projects.

Q9｜In 2026, huge numbers of companies overseas and in China are hiring FDEs, and FDE has gone from a "niche role" to a "hot title." Won't this overheating dilute the concept of FDE — say, traditional outsourcing firms rebranding their on-site engineers as FDEs, and training programs slapping the FDE label on their courses?

Follow-up｜How do you prevent "bad money driving out good"? Does Ha7ch have any certification system or quality endorsement to tell a "real FDE" from a "fake FDE"?

I think the FDE concept is genuinely starting to get muddy right now.

A lot of companies, when they hire, haven't actually figured out what an FDE should even be responsible for. They just see the title getting hot and repackage their old solutions, pre-sales, on-site development, or AI application engineer roles as FDE.

At the same time, training programs are starting to roll out FDE courses, but a lot of the content feels like it was thrown together at the last minute — stitching together some product, consulting, AI-tools, and project-management knowledge and then claiming they can quickly turn out an FDE.

I think this phenomenon is bound to happen, because any new role, once it gets hot, goes through a stage of concept diffusion, over-packaging, and messy standards.

But honestly, I'm not going to spend much energy arguing over who's a real FDE and who's a fake one.

FDE is itself a very broad role. It can lean toward product, toward engineering, toward consulting, or toward delivery, and different companies will define it differently.

If you insist that some person doesn't count as an FDE, he can just as easily say he's doing FDE work. I think this kind of fight over the title doesn't mean all that much in itself.

What actually matters isn't what he calls himself, but whether he's gone into a real site, whether he's taken a fuzzy problem and made it clear, whether he's built something that actually gets used, and whether it ultimately produced a result.

The market will end up separating these people through projects and delivery, not through a debate about definitions.

Right now Ha7ch also hasn't set up any formal certification system or quality-endorsement mechanism.

For now we mostly maintain quality through community culture, real projects, and long-term interaction between members.

Because if an organization that has just started doing FDE immediately rolls out a set of exams and certificates, then defines the standard itself, trains people itself, and hands out the certificates itself, I think it very easily turns back into a training business.

And the most crucial abilities of an FDE are hard to prove through an exam anyway — they need to be validated inside a real company.

In the future we might give a kind of identity to people who have actually taken part in an FDE Sprint, a hackathon, or a company project and have completed a real delivery — something like a Ha7ch Fellowship.

This identity shouldn't just be a "you attended the event" souvenir certificate; it should correspond to an experience that can be verified: what company he went into, what problem he faced, what system he built, whether the company used it, and what he specifically took on.

We'd rather it be a reputation formed jointly by projects and the community, rather than a certification you can get just by finishing a course.

So even if Ha7ch does quality endorsement in the future, it won't be the "pass the exam equals qualified FDE" approach.

It's more likely to be through project records, company feedback, peer evaluation, and sustained contribution that a person's ability record takes shape.

Whether it's called FDE isn't the most important thing; what matters is what this person has done, and whether his results can be verified by others.

We don't need to become title police, judging who's qualified to use the word FDE. But through real projects, we can make it easier for the market to see who genuinely has this kind of ability.

Q10｜If you could do it all over again, on the path from Alibaba/Tencent/MiniMax engineer to founding Ha7ch, which decision would you make differently? Building the community earlier, commercializing earlier, or defining the standard later?

Follow-up｜Is there one specific "do-over" moment? How was that decision made at the time, and looking back now, where did it go wrong?

If I could do it over, I'd probably start doing my own content much earlier.

Because I keep realizing more and more that I'm actually pretty well suited to this, and I genuinely enjoy the process.

I like sharing what I've seen, the projects I've worked on, and the judgments I'm still forming, and I like connecting with all kinds of people through content.

A lot of people tell me I have a good feel for what plays online, and I think so too — I probably do have some intuition for what content sparks discussion and what way of putting things is easiest for people to understand.

When I first started getting into FDE, I was basically learning the concept while continuously publishing content about it.

Later an investor said to me, you should try being a Growth Hacker.

I asked him, what exactly is a Growth Hacker.

He said, it's simple — I give you a target: get to 10,000 followers within a month. If you can figure out how to pull it off, you're a Growth Hacker.

And I said, OK, let me try.

Since the social media platform I personally use the most is Xiaohongshu, I started with Xiaohongshu.

But at the start I honestly had no idea that getting to 10,000 followers on Xiaohongshu isn't an easy thing at all.

Back then I was just constantly testing content, testing topics, testing ways of putting things, watching what people responded to.

I didn't quite hit the target within a month, but at the current pace I have a shot at getting close to that result in about two months.

This process made me realize that I don't just enjoy making content — I treat it as a product and growth problem to study.

So if you sent me back to the stage where I'd left Alibaba and gone to Stanford to do research, I'd probably have started documenting and publishing content consistently right from then.

There was actually a lot worth sharing in that period — going from big-tech engineer to research, switching between different cultures and ways of working, and the shifts in how I think about AI, Agents, products, and startups.

If I'd started building that up back then, I might have formed a stable channel for expression earlier, and connected earlier with the Builders, business owners, and industry practitioners I know now.

But I wouldn't frame this as simply chasing followers or traffic.

What I actually find interesting is the process of sharing knowledge and connecting people.

I really like putting out the thinking I'm still forming, and I like seeing someone start to understand FDE, join Ha7ch, or find a new project or collaboration because of one piece of content.

To me, doing my own content isn't just a promotion tool — it's also a way of thinking in public, getting fast feedback, and building a community.

So the decision I'd really change isn't necessarily commercializing earlier, and it isn't defining the standard earlier — it's starting to express myself in public earlier.

Because a lot of opportunities don't show up only after you've finished everything; they take shape gradually as you keep sharing and keep talking with people.

V. Looking Ahead and Recommended Actions

Q11｜If you could only go all in on one direction: keep deepening Ha7ch's "talent incubation + community network" (asset-light, slow to scale but a deep moat), go all out expanding "on-site delivery" (asset-heavy, fast cash flow but labor-intensive), or build an "FDE SaaS tool" (productize the methodology, sell software instead of headcount)? Why?

Follow-up｜If you pick "talent incubation," how do you cope with the pressure of "slow monetization"? If you pick "on-site delivery," how do you solve the "scaling bottleneck"? If you pick a "SaaS tool," won't it clash with the FDE core principle of "selling outcomes, not tools"?

If I could only go all in on one direction, I'd still choose to keep deepening talent incubation and the community network.

It really is a relatively asset-light model. Scaling up early on is fairly slow, and monetization won't be as direct as commercial delivery, but I think once it takes shape, the moat will be extremely deep.

Especially after you've built up talent density, a network of cities, and community identity in the early days, the person-to-person referral effect afterward will be very strong.

An outstanding Builder joining Ha7ch might bring in their friends, colleagues, and industry resources; a company that finds the right person through the community might also bring more real-world scenarios in.

Once this network starts growing on its own, it could move much faster than scaling purely through ads and sales.

As for commercialization and cash flow, I'm not in that much of a hurry right now.

Because once a community is genuinely valuable, it's not like there's no way to monetize at all.

Down the road it can sustain itself through corporate sponsorships, joint events, talent matching, industry partnerships, the FDE Sprint, co-created projects, and even support from a foundation or industry resources.

But that revenue should serve the community, not turn Ha7ch into a course-selling outfit, a recruiting agency, or a pure commercial-delivery company in the end.

Personally, I do genuinely prefer building community.

I like connecting people, I like watching people from different backgrounds meet each other through a Meetup, a GuildUp, or a real project, and then create new collaborations and opportunities.

The satisfaction this long-term network gives me is stronger than simply scaling up a delivery team fast.

So I'll still keep deepening Ha7ch, and try to keep it non-profit in its positioning.

If I chose on-site delivery, the biggest risk is that it's easy to fall into labor-intensive expansion: the more projects, the bigger the team, the heavier the management and after-sales, and in the end it might become a traditional project-based company.

This direction can generate cash flow and has real value, so it can be run by an independent commercial entity, but it's not the thing I personally most want to go all in on.

As for FDE SaaS, I think it also shouldn't be built too early at this stage.

Because right now we haven't accumulated enough on real enterprise scenarios, and if we productize the methodology too early, it'll probably just end up as another Agent platform or project-management tool, without actually solving the core problem of the FDE.

Tools should grow out of real projects, not start from the assumption that every FDE needs one unified piece of software.

So my choice isn't simply "give up delivery and only do community," but to make community and talent the core, while keeping a small amount of real projects as a training ground and feedback mechanism.

Talent is the main body, projects are the validation, tools are the sediment, and commercialization is the means to keep this network running long-term, not the ultimate goal.

Q12｜A year from now, which currently popular FDE plays or companies will have disappeared? And conversely, which things that look niche or unfashionable right now will turn out to have been right?

Follow-up｜You've talked about "letting the best Builders grow into FDEs, entrepreneurs, and the founders of the next generation of AI companies inside real industries." This funnel — talent → FDE → entrepreneur — how far along is it actually running? Has any Builder who came out of Ha7ch already started a new AI company?

My view is that a year from now, most of the FDE plays we see today won't actually disappear outright, because the supply-and-demand relationship behind them holds up.

On one side, companies have widespread AI anxiety; they need to redesign processes, boost efficiency, and upgrade their organizations. On the other side, a large number of engineers, product managers, operators, and other highly skilled people are going to be looking for a new place for themselves as AI disrupts their old roles.

So companies have the demand, and talent needs to transition — this market is going to exist for a long time.

It's a bit like the matchmaking market.

You can say a particular guy and a particular girl aren't a match, but you can't conclude from that that the whole matchmaking market doesn't exist.

FDE is the same. A large enterprise might not match with a small team; a small or mid-sized company might not be able to afford the cost of a big-tech FDE. But there will always be some portion of companies and some portion of talent that manage to match successfully.

What really needs to be solved is matching efficiency, not whether the market exists.

So what might actually gradually disappear isn't a particular organizational form — it's the models that can't prove results, that are just traditional outsourcing repackaged as FDE.

For example, ones that still just wait for a PRD, charge by headcount, or can only build a demo and never get into a real production environment.

These plays won't automatically earn long-term value just because they changed the name on the label.

In the end the market still looks at whether anyone is using the system, whether the process has actually changed, whether the company has genuinely gotten results.

Conversely, the direction that I think is relatively niche right now but may prove correct in the long run is AI-native companies.

Right now everyone is more focused on how to bolt AI features onto an existing ERP, or how to deliver a project at lower cost.

These things obviously have value, but if you stop at simple efficiency gains and never think about how a company's whole organization and systems should change once model capabilities keep getting stronger, I think that's not enough.

Because AI is going to keep getting smarter.

Today it can maybe only replace a small slice of the work — data entry, organizing, review — but in the future it may take on much more of the communication, judgment, and execution.

If a company's systems can continuously plug in AI from the very start, and record people's corrections and process changes, then as the models get stronger, the human-in-the-loop part can keep shrinking, and the company's overall operating efficiency will keep getting higher.

So what I'm more bullish on is a kind of company that can keep re-engineering itself as the models evolve — not just one that bolts an AI plug-in onto a legacy system.

Of course, building a fully AI-native company from scratch is still very hard today, especially while domestic models, local deployment, reliability, and data security aren't fully mature yet.

But we also can't wait until the models are completely mature to start.

You can already go into a company now, gradually replace the simple, repetitive, labor-intensive work, and then keep iterating as model capabilities grow stronger.

As for the path Ha7ch envisions — "Builders growing into FDEs, then becoming entrepreneurs and the founders of the next generation of AI companies" — it's still at a very early stage.

We've only been doing FDE content and community systematically for about two months. If we claimed right now that we'd already gotten the full funnel running, that would actually be not credible.

Reddit was in YC's very first batch back in 2005, and it was acquired quite early, but it still took many years to reach the scale and influence it has in the later sense.

So a project or a talent network getting recognized very early doesn't mean its long-term value has already been proven.

What Ha7ch has really validated so far is just the very front of the funnel: finding Builders through content and Meetups, judging who has FDE potential through real enterprise scenarios, and then getting some of them into a Sprint or a project.

The later stages — independent delivery, industry accumulation, discovering entrepreneurial opportunities, and actually founding companies — all need a much longer cycle.

I hope that by the end of this year we'll see the first batch of concrete cases: for example, someone who got into a real company through Ha7ch, completed their first independent delivery, and maybe even found a startup direction worth committing to for the long haul.

But whether this path ultimately holds up should be proven by the people and companies who actually walk it over the next few years — not announced in advance by us when we're two months old.

Q13｜If you could give the audience at the Feifan Awards — corporate decision-makers, AI founders, engineers in transition — just one piece of advice about "how to actually get AI to land in the real world," what would it be?

Follow-up｜Could you give a concrete action or checklist people can execute right away? Something like "three signals that tell you whether your team needs an FDE" or "three criteria for choosing an FDE provider"?

If I could give corporate decision-makers, AI founders, and engineers preparing to make the switch just one piece of advice about how to actually get AI to land in the real world, I think the first thing isn't to keep taking courses, and it isn't to read more industry reports — it's to use Claude Code intensely, and use it to build a large number of things you'd always wanted to make but never got around to because of time and cost.

A lot of people will say they've used Claude Code, but if the way you used to write code hasn't really changed and you're now just handing off part of the code to Claude Code, I don't think that's enough.

The real leap comes from using it frequently enough — frequently enough that you start to re-understand what an Agent is, what an Agent can take on, and just how far a single person's capabilities can be amplified.

For me, the most obvious leap came after I started using the $200/month plan.

The reason I signed up for that plan was that I was maintaining a lot of products at the same time — in one month I built roughly eight or nine relatively complete products and kicked off more than ten projects.

It was during that stage that I truly realized just how much one person plus AI can do.

In the past, if an idea came to me at three in the morning, I'd probably just jot it down, put it off for a few days, and most likely never build it.

But now I can just open my laptop, lay out the background, the users, the requirements, and the outcome I want, and let the Agent get to work.

By the next morning I might already have a running version, and then I can ship it, go find my first batch of testers, and keep iterating based on their feedback.

Only when you go from idea to product to real users at that kind of cadence, over and over, do you truly understand what an Agent can do — rather than staying at the level of "it can help me autocomplete code."

So whether you're a corporate decision-maker, an AI founder, or an engineer preparing to make the switch, my advice is to first build a large enough number of small projects back to back.

These projects can't just be demos you keep on your own machine and admire yourself — ideally they should actually be shipped, attract real users, even if only ten people use them at the start.

Because only when a product actually faces users do you run into changing requirements, deployment, feedback, bugs, and maintenance — and only then can you understand what AI has actually done for you, and where it still can't replace human judgment.

My second piece of advice is that everyone preparing to become an FDE should seriously consider doing their own media — that is, Build in Public.

Because one of the hardest problems for an FDE isn't actually writing code — it's acquiring customers and building trust.

How do you get a company to know you can solve its problems? How do you make the next client believe you're not just someone who can build a demo?

One of the most effective methods is to continuously document the problems you run into on real projects, your thought process, your failures, your results, and your methods.

For example: you walk into a factory and find some problem in their order process; you try a solution and get stuck at a certain step; how you finally redesigned the workflow; and what happened to the manual-correction rate after it went live.

All of this can become content.

Every time you finish a project, you shouldn't only deliver it to the current client — you should also distill whatever can be made public, so it keeps attracting your next client for you.

If you do no public expression at all and just keep your head down delivering one project after another, it's easy to slide back into traditional outsourcing.

Once a project ends, the experience stays only in your own head — it never becomes a brand, a methodology, or a new source of clients — so there's no compounding.

This is exactly what a lot of great independent designers do: they don't wait until the whole project is done to show the result — they keep sharing new color schemes, motion, layouts, and design decisions throughout the process.

On one hand this content attracts their next client, and on the other it helps them distill their own workflow.

FDEs should do the same.

For corporate decision-makers, I think there are three signals that tell you whether your team needs an FDE.

The first signal is very direct: you already have obvious AI anxiety.

You know your peers are starting to use AI, you know the company needs to change, but no one inside can make it concrete.

At that point, rather than keep holding meetings to discuss it, it's better to bring in an FDE to run a small-scale trial on-site, or take part in one of Ha7ch's Ha7chthons.

The reason we call it a Ha7chthon rather than just a traditional hackathon is that a traditional hackathon is usually held at a fixed venue, where everyone builds demos around a hypothetical problem; but with a Ha7chthon, wherever the company is, that's where the event happens.

Builders go straight into a real company, observe real employees and real workflows, and complete demand discovery and prototype validation on-site.

It's not a competition around a set prompt — it's work around a company's real problems.

The second signal is that your company is still constantly hiring people to take on repetitive work that your gut tells you AI can already replace.

Things like data entry, organizing, review, order operations, moving information around, and repeated back-and-forth communication.

If on one hand you feel this work is very mechanical, and on the other you keep hiring people to fill it, then it's worth letting an FDE come in and take a look, and judge which processes can be redesigned.

This doesn't necessarily mean directly cutting a certain number of people — it means first seeing whether it's even necessary to keep solving the problem by adding headcount.

The third signal isn't necessarily cost-cutting or efficiency gains — it's that you simply want the company to keep progressing.

I'd split companies' motivations for using AI into two kinds: one is clear cost-cutting and efficiency gains, and the other is company progress.

Some bosses don't have a very specific KPI — they don't necessarily require profits to jump by so much or costs to drop by so much right away — but they want to look back in five years and see that starting on AI today was the right decision.

Especially some second-generation factory owners or business operators who are taking over the family company: they may care more about whether the company will still be competitive in the future.

Because no one can fully predict what AI will look like in five years.

If you start right now to re-examine the company's processes, data, and organization from an AI-native angle — even if it's just a small trial first — it could become the foundation for the company to stay ahead in the future.

An FDE doesn't only have to be about cutting costs — they can also help a company understand what the next generation of ways of working should be.

As for how to choose an FDE or an FDE provider, I don't think you can give an absolute set of standards right now, because the whole market is still very early and there aren't many truly mature providers.

But one principle is: don't put too much faith in titles, prestigious-school backgrounds, or all kinds of packaging — the most important thing is whether they can keep making things in a very short time.

A lot of traditional business bosses might be willing to sign a deal outright because the other side is a Tsinghua or Peking University team, yet unwilling to first spend some money to actually let them give it a try.

But if it were me, I'd rather cover the travel costs first, then — at a reasonably, even somewhat high, day rate — let the team come into the company and work for seven or fourteen days.

By the end of that period, I'd look at how much of the problem they actually understood, what they built, and whether anyone is willing to use the system.

One important change in the AI era is that delivery speed can be extremely fast.

A reliable FDE shouldn't spend two weeks stuck writing proposals, giving briefings, and discussing requirements — they should keep delivering.

Day one, map out the problem; day two, produce a workflow; day three, a prototype appears; and after that, keep revising based on feedback.

Seven to fourteen days is actually already enough to judge whether a person or a team is reliable.

So my advice to companies is: don't sign a particularly large contract right at the start, and don't make your choice based only on slide decks and reputations.

First pay for one real, small-scale, high-intensity engagement, and see whether the other side can get on-site, understand the business, build fast, and keep delivering.

In the end, an FDE doesn't prove themselves by persuasion — they prove themselves by producing visible results in a very short time.