Original · Unique Research · 2026-07-14
Editor's note: The interview and its judgments belong to the original Chinese author and the interviewee, Jiang Yaokai (蒋耀锴), founder and CEO of Functor Technology (函子科技). This English rendition translates the full article in source order, including the opening essay, four analysis sections, and all fifteen Q&A items. All company, product, and person names are preserved as source attributions; official English forms are used where known and transliterated where unverified. Revenue figures, user counts, and performance claims are speaker claims, not independently verified findings.
AI Industry Observation
AI Coding Has Demos Down Cold — What's Actually Scarce Is Running a Product
"Not knowing how to code should not disqualify you from building a product."
These days, the easiest part of building an AI product is making something that looks like a product.
Type in a prompt, generate a page in minutes; plug in a large model, add a few buttons, and an AI app prototype emerges. What used to take a team weeks, one person can now knock out in hours using Cursor, Claude Code, or various Vibe Coding tools.
But then what?
After users register, where does their data live? What can different users see? Who has permission to modify orders? How do you handle payment failures? Can the model read business data, and can it safely write back to the database? When users grow from ten to a hundred thousand, can the system keep running?
These questions are almost invisible in a Demo.
This is also the most direct judgment from Jiang Yaokai (蒋耀锴), founder and CEO of Functor Technology (函子科技), on this wave of AI Coding:
"The frontend is no longer scarce. What remains unsolved is the backend behind the product: permissions, data consistency, and long-term operations. AI is dramatically lowering the cost of writing code, but it has not automatically eliminated the responsibility required to run a software product."
AI Solved "Write It," Not "Run It"
Jiang Yaokai spent eight years as a backend engineer at Silicon Valley enterprise software company Medallia.
While there, he and a partner built many side projects: QR code ordering, NFC self-checkout, stock strategy backtesting. Every project meant rebuilding the database, writing APIs, connecting the frontend, and managing page state.
The more he did, the more certain he became: software development contains enormous amounts of repetitive labor, and not all of it requires someone trained in engineering for years.
More importantly, many people who understand industries, customers, and commercial opportunities ultimately fail to turn ideas into products not because they lack ideas, but because the technical barrier is too high.
"Not knowing how to code should not disqualify you from building a product."
This became the starting point for his return to China to found Functor Technology and launch Zion and its overseas version Momen.
But now that AI Coding has exploded, this problem seems solved. People who can't code can have AI generate code. Why would they still need a no-code platform?
Jiang Yaokai's answer: AI has lowered the barrier to generating code, but it has not lowered the barrier for ordinary people to understand and control code.
A developer who receives AI-generated code can inspect the database schema, modify permission policies, trace logs, and handle production incidents.
Someone who doesn't understand code at all, receiving the same output, can only check whether the page opens and buttons click. Whether the underlying data model is sound, whether permissions are secure, whether the business logic has holes — these are hard to judge.
A frontend error usually means an ugly page or clunky interaction.
A backend error can mean data loss, privilege escalation, accounting errors, or outright security incidents.
So Jiang Yaokai believes the biggest breakpoint in AI Coding today is not "can't write code," but that the backend structure, permissions, consistency, and long-term operability after generation remain unsolved. What Zion wants to fill is exactly this half: letting non-technical users not just generate a product, but understand, modify, verify, and maintain it.
This is why he proposes "AI No Coding."
AI Coding lets AI help developers write code.
AI No Coding lets AI help ordinary people build applications within a structured, visual system.
The difference is not simply whether code exists at the end, but who has control over the result.
What No-Code Actually Sells Is Not Less Code, But Less High-Risk Responsibility
For a long time, no-code has been understood as a simpler way to develop.
Drag a few components, connect a few flows, write no code, and quickly build an app.
But in Jiang Yaokai's view, this understanding stays on the surface.
What no-code truly provides is not "fewer lines of code," but that the platform has already handled a batch of engineering responsibilities that ordinary people cannot independently bear.
Take a product backend: it includes at least a database, user authentication, role permissions, row-level and column-level permissions, business logic, APIs, file management, deployment, runtime environment, and subsequent scaling.
Developer tools like Supabase also provide these capabilities, but the user needs to understand PostgreSQL, SQL, RLS permission policies, and function logic.
Zion also provides database, auth, permissions, and APIs, but it tries to make these into visual structures and reduce the chance of user error through platform rules.
"Jiang Yaokai summarizes the difference in two words: control. For professional developers, code itself is the control tool. For non-technical users, a pile of unreadable code does not mean control; it may instead be another black box. Therefore, the value of no-code is not giving users unlimited freedom, but through guardrails, letting them stably solve real problems within a range suitable for the platform's abstraction."
This is also why he doesn't believe AI Coding will fully replace no-code.
People who can read code and handle backend and operations are reasonable to use Cursor. Many users will mix both: frontend generated by AI, backend managed in Zion.
But for people who don't understand technology, what matters most is not how much code is generated at once, but whether they can keep operating after generation.
Between a product that can demo and a product that can collect money long-term, there is still a lot of invisible work.
If an Agent Can't Connect to Business, It's Just a Chatting Shell
Similar problems appear on Agent platforms.
Building an Agent is no longer hard. Configure a prompt, choose a model, add a knowledge base, connect a few tools, and quickly get a conversational agent.
But Jiang Yaokai believes a large number of Agent products face a common problem:
Easy to create, hard to charge.
The reason is that many Agents are still isolated chat boxes.
They can answer questions but cannot read the enterprise's own business data; they can generate content but cannot write results back to systems; they can demonstrate capability but cannot connect payments, launch independently, or operate continuously.
Such an Agent is closer to a functional demo than a complete product.
Zion's understanding of Agents is not adding a separate chat entry, but growing Agents inside the full-stack application.
It can read the application's own database, write results back to data tables, trigger business processes, call external APIs, and connect payment systems.
In this structure, the Agent is not the product itself, but an execution role within the product.
So Jiang Yaokai's positioning for the Zion Agent builder is very clear:
"Visualization is only the entry point; the full stack is the essence. What really separates products is not whether you can build an Agent, but whether that Agent can enter real business and ultimately form a commercial closed loop."
This also explains why he remains bullish on Agentic Workflow rather than fully end-to-end autonomous Agents.
The end-to-end Agent story is compelling: give it a goal, and it plans, calls tools, and completes the entire task on its own.
But the more task steps, the harder it is to locate the error source. After thirty steps producing a wrong result, the problem could be in step three, step twenty-seven, or an interaction between two intermediate states.
Engineers can inspect logs, trace states, set breakpoints.
Non-technical users facing a black box can usually only tell the system: "The result is wrong."
This feedback is insufficient to help the system find the problem in a rapidly expanding state space.
Therefore, what can truly enter production environments is more likely well-bounded Agentic Workflows: AI placed in defined process nodes with clear context, tools, and permissions, where every step can be checked, rolled back, and when necessary, intervened by humans.
An end-to-end Agent is like an imagined omnipotent employee.
An Agentic Workflow is like a digital employee integrated into organizational processes with clear job responsibilities and permission boundaries.
Development Cost Drops Tenfold — Small Markets Are Finally Worth Doing
What Jiang Yaokai really wants to serve is not large enterprises' IT departments.
Over 80% of Zion's users are individual developers, with another portion being small teams, and enterprise clients a smaller share. After 2024, the company further narrowed its target customers to non-technical founders, independent developers, and OPCs (one-person companies).
This choice doesn't look like a traditional SaaS company's growth path.
Enterprise clients have bigger budgets and larger contracts — why not go upmarket to enterprise low-code platforms?
Because the opportunity Jiang Yaokai sees is not helping large enterprises optimize existing processes by another notch, but enabling software products that simply would not have existed before.
Many real demand markets are not large.
A specialized calculation tool for one industry, a trading community for a small circle, a local event platform, a management system serving a particular type of merchant — annual revenue might only be a few hundred thousand to a few million RMB.
Such markets were not viable before.
Not because there were no users, but because development costs were too high. Hiring a product manager, frontend, backend, designer, and ops for a limited-scope demand made the investment hard to recover.
But if development cost drops tenfold and market size stays the same, the business model can fundamentally change.
Small markets previously "not worth doing" can now be served by one person or a few people.
There is a case on Zion that Jiang Yaokai often mentions.
A fund manager initially just wanted to manage his sports card collection, so he built a mini-program. Later, other collectors started using it, and the product gradually added trading, matching, and purchasing agent features.
This project's revenue grew from 5 million to 7 million RMB, operated essentially by one person.
There was also a sophomore who built a resource marketplace for his school, adding user registration, product listings, orders, payments, and AI recommendations and customer service, later earning over 10,000 RMB per month.
These products may not become the next unicorn, but they are no longer Demos or one-off works.
They serve specific groups, generate real transactions, and form stable cash flow.
This is the result Jiang Yaokai cares about most.
Not how many apps users publish, not how many "AI startup stories" the platform manufactures, but how many apps are still alive, used daily, generating transactions, and continuously called.
He Doesn't Want to Create More Fundraising Projects, But More Cash Flow Businesses
In the AI startup narrative, fundraising is often treated as proof of success.
But Jiang Yaokai doesn't want Zion users to think about fundraising first.
He wants them to build Cashflow Businesses: not necessarily large in scale, but able to continuously charge and sustain themselves.
This also determines Zion's business model.
The platform charges a subscription fee; AI and cloud resources are billed by actual usage, but there is no revenue share on user earnings. After users build a product, their data, business logic, and revenue remain theirs.
For individual entrepreneurs, what they are buying is not ordinary office software, but a means of production.
A tool costing a few hundred yuan per month, if it helps one person launch a business that could not have started otherwise, has a decent ROI.
The real question is not whether individual customers have a high enough AOV, but whether the platform can get enough people with real motivation to keep using it and earn income on it.
Therefore, Functor Technology does not serve everyone who wants to "build an app."
Jiang Yaokai divides users into several types.
One type is industry experts. They understand civil engineering, manufacturing, healthcare, legal, and other professional scenarios; they know industry rules that general software doesn't cover, but they can't write code.
Another type is opportunity monetizers. They have ideas and limited capital, and want to complete the journey from idea to first revenue in the shortest time.
There are also traffic and asset owners. They already have communities, content, or customers, and want to build their own product and data assets to reduce dependence on third-party platforms.
These three types have different capabilities but one thing in common: they all want to do it themselves and are willing to operate long-term.
Conversely, people who only want to pay for ready-made results without understanding the business are better off buying SaaS or hiring outsourced development, not using Zion.
"We serve people who want to slay dragons, not people who want to eat dragon meat. What Zion wants to be is not to finish the work for entrepreneurs, but to be the knife in the dragon-slayer's hand."
The Next Round of Competition Is Not Who Generates Faster, But Who Makes Results More Controllable
AI development tools keep shortening generation time.
Weeks become days, days become hours, and in the future it may take only minutes.
But as generation speed keeps improving, speed itself will gradually lose differentiation.
What truly determines whether a product can enter production will be other questions:
Can the generated result be understood by humans?
Can data and permissions be verified?
When errors occur, can they be located and rolled back?
After model changes, can the product keep running?
After user growth, can the system be continuously maintained?
This is also why Jiang Yaokai is more bullish on "AI combined with DSL."
DSL can be understood as a structured, domain-specific expression system. AI doesn't generate a pile of black-box code humans can't control; it works within a structured system of data, components, processes, and permissions.
AI is responsible for improving building efficiency, while humans can still understand the system structure — knowing where the data is, how processes run, and how permissions take effect.
From this perspective, no-code and AI Coding are not simply replacements.
AI Coding lowers the cost of producing code.
No-code platforms lower the cost for ordinary people to control complex software systems.
What is truly worth watching is not whether people still write code in the future, but who enables someone who can't code to also take responsibility for their product.
AI has made producing a passing-grade Demo very easy.
What will be scarcer in the next stage is not more beautiful pages, more Agent entries, or another demo that can generate an entire product.
It is turning a real small need into a closed loop that can charge, operate, maintain, and continuously iterate.
Jiang Yaokai's advice to non-technical entrepreneurs is simple:
"Don't start by asking if you can build an impressive AI product. Start by answering four questions: Who is the user? What is their most painful problem right now? What three to five steps are needed to solve it? At which step can you start charging earliest? Because startups rarely die from 'can't build it.' More often, they die because nobody needs it at all."
Selected Interview Q&A
Q1. You moved from a Silicon Valley engineer to startup — why did you decide to build a tool that lets non-coders also develop products?
Jiang Yaokai: I decided to start a company from a young age. Going to Medallia was itself about learning how a startup and engineering team actually operate. After the company went public, I started "scratching my own itch" — building things I genuinely wanted.
Those years, while doing backend at Medallia, I built side projects with a partner: QR code ordering, NFC self-checkout, stock strategy backtesting. Every project meant rebuilding the database, opening APIs, connecting the frontend, and handling a pile of page states and styles. After doing enough, I felt strongly that a lot of this is repetitive labor, and not all of it needs someone with full engineering training.
What really convinced me was realizing that many smart, business-savvy, commercially-minded people don't turn ideas into products not because they lack ideas, but because the technical barrier is too high. Not knowing how to code should not disqualify you from building a product.
So Zion/Momen is essentially not me jumping from programmer to non-programmer, but taking my past experience building infrastructure, backend, and high-performance systems and making it into a tool. This tool no longer only serves engineers, but serves people who want to build products but haven't spent years learning programming.
Q2. You previously described the startup environment as "opportunity, barrenness, isolation." By mid-2026, how have these three words changed?
Jiang Yaokai: If I rank them again now, I'd say: opportunity hasn't changed much, barrenness is still there, and isolation is somewhat better than last year.
Opportunity hasn't changed because I've always believed all structural social changes come from some order-of-magnitude drop in marginal cost. The steam engine, container shipping, the internet, smartphones were all like this. This time, AI is lowering the marginal cost of cognition. When development cost drops tenfold, many small markets previously not worth doing suddenly become viable and profitable.
Barrenness still exists in China. A small business looking for digital solutions has very limited resources and capability. It's not that there's no demand, but the soil for turning demand into action is still thin.
Isolation is somewhat better than last year. The OpenClaw wave, and the subsequent Claude Code-style Agentic Coding tools from various companies, let more people actually use Agentic workflows for the first time, narrowing the information gap considerably.
But the information gap hasn't disappeared — it just changed form. The old question was "do you know this thing exists?" The new question is "can you understand it, verify it, and integrate it into real business?" Many people see Demos; few see Workflows. Many remember model names; few truly focus on context engineering, tool calling, memory, permissions, and data sources. The information gap has shifted from whether you have information to whether you have the ability to turn information into results.
Q3. AI Coding tools can already quickly generate apps — what is Zion's real differentiator?
Jiang Yaokai: Zion is a full-stack visual application builder. Precisely because it is visual and structured, AI can complete a full loop on it: first think through what to build, then generate, then verify.
The truly difficult part is verification. For someone who can't code, just looking at the frontend running, or a few specific inputs and outputs, is far from enough. You can't confirm whether the underlying data, logic, and permissions are actually correct.
For Vibe Coders today, the hardest part has never been the frontend. The frontend AI can already do fast and beautiful, but the backend is where data models, permissions, consistency, transactions, deployment, and long-term maintenance are truly hidden. These are invisible in Demos, but quietly go wrong after real users grow.
AI Coding solves AI helping you write code. The counterpart should be "AI No Coding" — AI helping users build on a no-code system. What Zion solves is not writing a bit more code, but letting ordinary people understand, modify, maintain, and run their own products, truly going from Prototype to Production.
Q4. Have users said: "I'm already writing code directly in Cursor, why do I still need Zion?"
Jiang Yaokai: Yes, and that's normal. Some users do migrate to AI Coding. If they can already read code and take backend responsibility themselves, that's entirely reasonable. Many users also mix both — frontend built and generated with AI, backend on Zion.
AI Coding will erode part of no-code's space, but won't fully replace it. A person who doesn't code at all, building a full-stack app from scratch, used to take six months; with Cursor maybe a month; with no-code it's often still about a week.
The real difference isn't generation speed but control method. If you're a developer, Cursor is great. If you're non-technical, AI generates a pile of code and you have no idea what it's doing, whether permissions have issues, or whether the backend has hidden pitfalls.
For non-technical users, being able to understand, modify, verify, and continuously iterate matters more than generating more things at once. If you can stably use Cursor to handle backend, permissions, database, payments, deployment, and ops, of course you don't need us. But many people eventually find that what they've built is something that can demo, not necessarily a product that can be operated long-term.
Zion's value is not helping you write more code, but helping you avoid taking on a batch of high-risk responsibilities.
Q5. Zion as the backend for Vibe Coding — what's the most essential difference from Supabase?
Jiang Yaokai: The most essential difference isn't the service list, it's control. If you can read it, you truly have control.
Supabase is a very principled product path. The foundation is real Postgres, with strong data sovereignty, ecosystem, and developer mindshare. But it defaults to serving developers; data modeling, SQL, RLS policies, Edge Functions, frontend integration, and production permission troubleshooting are all the user's responsibility.
That's fine for technical teams, but for people who can't code, or users relying mainly on AI Coding, the barrier is still high. Especially permissions — RLS is very powerful, but once written wrong, it can become a security incident.
Zion's BaaS includes PostgreSQL database, user authentication, RBAC role permissions, row-level and column-level permissions, Actionflow visual business logic, auto-generated GraphQL API, file capabilities, AI Agent, RAG, plus deployment, dedicated compute, and private deployment support.
If you only list services, the two overlap heavily. The real difference is that on Zion, these capabilities are visual and active by default. Users can understand them, and the platform tries not to give users the chance to write things wrong. Supabase hands backend building blocks to developers; Zion assembles them into a product backend system that even non-technical users can control.
Q6. Zion's Agent builder versus Coze, Bailian, and other Agent platforms — what's the core difference?
Jiang Yaokai: Platforms like Coze and Bailian are very good at helping users quickly create an Agent, whether conversational or workflow. The creation part is convenient. But they share a common problem: easy to create, hard to charge.
The Agents they produce are often islands that can't connect to their own real business data; independent deployment, charging, and long-term operation are relatively difficult.
Zion's Agent builder's biggest difference is that the Agent is not a standalone shell, but grows inside a complete full-stack product. It can read the user's own database, write back to data tables, trigger Actionflows, connect payments, and launch and operate independently.
What others provide may be a chat-capable Agent; what we want to provide is an Agent embedded in real business, that can run and also make money.
So visualization is only the entry point; the full stack is the essence. What truly separates products is not whether you can visually build an Agent, but whether that Agent can connect to real business and ultimately form a commercial closed loop.
Q7. The Agent concept is getting hotter — why do you still believe Agentic Workflow is closer to real deployment than end-to-end Agents?
Jiang Yaokai: End-to-end Agents are great for storytelling and demos. Give it a goal and it plans, calls tools, and completes tasks on its own — it sounds very tempting. But once it enters real business, you encounter controllability, stability, cost, permission boundaries, error recovery, and how to locate problems when they occur.
The most fundamental reason is that complexity grows multiplicatively, not additively. Each added step multiplies the state space, but the feedback signal "it's wrong" carries the same amount of information.
A 30-step task produces an error — is it in step 3, step 27, or the interaction between steps 12 and 19? For an engineer who can read code, "it's wrong" isn't information, just a trigger — he'll trace further, inspect intermediate states, and set breakpoints. But non-technical users can only evaluate in a black box, which is insufficient to find the problem in an exponentially expanding state space.
What can truly land is still Agentic Workflow: putting AI into a system with boundaries, context, tools, process nodes, and human-in-the-loop when necessary. Every step can be checked and rolled back.
An end-to-end Agent is like an imagined omnipotent employee; an Agentic Workflow is like a digital employee placed inside organizational processes. The latter is closer to what can actually be delivered today.
Q8. Who exactly are Zion's core users?
Jiang Yaokai: Internally, we don't just divide by individual, small team, and enterprise. We focus more on three user profiles.
The first is industry experts. They're mostly in their thirties or forties, from traditional industries like civil engineering, real estate, manufacturing, healthcare, and legal. They understand the business, including the "unspoken rules" that general software doesn't cover. They're very proficient with Excel and flowcharts, but can't write code. For them, the most important thing is logical accuracy. Professional calculations must be 100% correct; 99% can ruin their reputation.
The second is opportunity monetizers, including serial entrepreneurs, college students, and various Vibe Coders. They have strong commercial instincts, limited capital, but lots of ideas. For them, the app is a monetization funnel; what matters most is speed. From idea to first WeChat Pay, ideally within 72 hours. Their success criterion is simple: how fast can they receive real money.
The third is asset or traffic monetizers, such as influencers, community owners, and e-commerce practitioners. They strongly dislike platform taxes and being dependent on others. After building several million in revenue on other platforms, once that platform raises its cut, changes rules, or bans them, the entire business is affected. So they value sovereignty: their own data, their own logic, no revenue share, and the ability to migrate anytime.
What these three types share is that they all want to do it themselves, demand low cost, fast launch, and system stability, and all face the same difficulties: can't afford reliable full-stack engineers, outsourced deliverables can't be modified, WeChat ecosystem barriers are high, and there's a maintenance gap after AI writes code.
Q9. When do users truly believe no-code tools can run real business?
Jiang Yaokai: The real Aha moment is when users see something real move for the first time.
Data actually changed, an API actually connected, data in another system changed along with it, the page actually changed, and the Agent actually output a result. Most people in their hearts don't really believe no-code can run real business, so when they see the product actually running, their cognition shifts from "I actually built this" to "this thing actually runs the business."
We serve people who want to slay dragons, not people who want to eat dragon meat. Users first need a specific problem, then build the pages, data, and processes. When they discover the product isn't just a Demo but can actually log in, save data, collect money, and deliver to others, willingness to pay rises significantly.
We don't measure user success by registrations, app count, or launch count. What we really care about is daily active apps, revenue, and API calls. In one sentence: how many "alive and useful apps" are on the platform.
Q10. What is Zion's business model? How do you avoid AI invocation costs becoming a black box?
Jiang Yaokai: It's essentially two axes: platform subscription and AI usage billing. To put it bluntly, we're basically cloud middlemen, just making a more usable cloud.
Pricing isn't a revenue share on user earnings; it's closer to cloud services. Users pay subscription fees for platform capabilities, and pay more as they use more AI or cloud resources. Our principle is that as long as the product a user builds has clear commercial value, buying Zion should be a relatively easy decision.
We strongly dislike pricing structures that users can't understand, can't calculate, and then suddenly receive a huge bill. Platform costs are made as predictable subscriptions as possible, while AI calls are billed separately but explained as clearly as possible.
We also made a dedicated AI price calculator to help users estimate total cost based on model, input/output, and business volume. Users don't need to understand Tokenizer principles; they just need to know which actions generate AI costs, roughly at what scale, and how much business value that corresponds to.
I have a very clear principle: every AI call either generates commercial value, increases revenue, or saves cost. AI startups can't rely on burning service costs to acquire users — unit economics that lose money per customer mean the bigger the scale, the faster you die.
Q11. What projects on Zion have already grown from personal ideas into sustainably profitable small businesses?
Jiang Yaokai: Quite a few projects have grown from personal ideas into sustainably operating small businesses, though of course some rise and fall.
For example, an engineer who hadn't written code in ten years built a virtual girlfriend mini-program, which was later banned by Tencent; a UX designer built monetization templates for Coze users, which declined as Coze's popularity faded. But more projects survived, and some grew larger.
The most typical is the sports card project. It started as a collection management tool a fund manager built for himself, then more people used it, and it added trading, matching, and purchasing agent features. Revenue grew from 5 million to 7 million RMB, operated essentially by one person.
There's also a sophomore who built a digital order-tracking system for his family's factory that has been running stably; a K-pop merchandise community, a Hong Kong offline events community, and a community serving OPC entrepreneurs in the AI era.
They may not all grow into big companies, but they're no longer one-off works — they're small businesses that continuously generate income and serve specific groups. What I care about most has never been whether there's fundraising, but whether the product has gone from "I made something" to "this thing can continuously create value, and people keep paying."
Q12. What kind of users or projects are not suited for Zion?
Jiang Yaokai: A sign of mature business is not saying everything can be done, but knowing which scenarios shouldn't be taken on.
Zion is best suited for non-technical founders and OPCs who don't have an existing engineering team, want to quickly build a real product, and are willing to do it themselves.
The first type of unsuitable user is someone who only wants to spend money without understanding the product and business. What they need is more like a solution, outsourced development, or off-the-shelf SaaS, not a tool platform.
The second is projects that are heavily customized from the start, or require modifying complex legacy systems. We have fixed requirements for database structure; if an enterprise already has a complex database and wants Zion to directly connect and modify it, that's usually not in our strength zone.
The third is when what the user really needs is already a standardized business module. They don't want to build, they just want to buy a ready-made result — then choosing vertical SaaS directly is more appropriate.
A tool has maximum value only when the user has clear motivation, is willing to do the work, and is willing to operate long-term.
Q13. Why go all-in on individual entrepreneurs instead of going upmarket to enterprise low-code?
Jiang Yaokai: If I could only choose one direction, I'd choose "no-code + AI" individual entrepreneurs and non-technical founders.
Four reasons: first, this market has almost no real competitors; second, we've accumulated a long time on this path; third, we've already built some brand recognition among these users; fourth, it's my personal preference — I just want to serve these people.
A lot of real demand isn't large enough to justify maintaining a long-term engineering team. Many markets have annual revenue of only a few hundred thousand or one to two million RMB. In the past, high development costs made these markets not worth doing; when development cost drops tenfold, they suddenly become viable.
Enterprise low-code is of course also a market, but it's heavier on sales, organization, and customization, and easier to enter competitive environments where big companies excel. I'm also bullish on AI Agent app stores, but that should naturally emerge after tools and development platforms mature. Without stable building capability and real developers making money on the platform, doing a marketplace alone easily becomes hollow.
We want to be the knife in the dragon-slayer's hand, not slay the dragon for him.
Q14. Do you think the large model bubble will burst? What does that mean for the application layer?
Jiang Yaokai: I think the general direction is being validated. Data center construction already shows signs of overcapacity; capital expenditure no longer corresponds to market cap growth; Capex efficiency is declining, much of it stuck on memory bottlenecks. This bubble will definitely burst, comparable to the peak of the internet bubble.
But what's truly scarce has never been another model, but how to turn model capability into real, operable products. The model is not the endpoint; what's truly hard is connecting it to business processes, permission systems, data systems, payments, and long-term operations.
Frontend Demos are easy; backend structure, permissions, consistency, maintenance, and commercial closed loops are hard. This gap is being seen by more people.
Even if the model bubble bursts, the capability gains accumulated over the past year remain; they won't disappear with valuation corrections. For the application layer, usable capabilities still exist, and even as the industry becomes more sober, it becomes easier to find genuinely valuable use cases.
We designed from the start as "model-replaceable." Whichever model is better or cheaper, users can use it. What users ultimately can't leave is not a particular model API, but their own data, processes, permissions, frontend and backend, payments, and operating systems. The model is the engine, not the whole car.
Q15. For non-technical entrepreneurs, how do you judge whether an idea is worth turning into a product immediately?
Jiang Yaokai: Don't start by thinking "can I build an impressive AI product." Start by thinking "can I turn a real small need into a closed loop that can charge, operate, and continuously iterate."
Many people start by going for something big and comprehensive, or an AI experience that looks stunning. But what actually runs is often not the flashiest product, but the one that solves a specific problem first.
Especially for non-technical people, you should start from scenarios you truly understand. You understand users, processes, and why needs exist better than others — that matters far more than whether you can code. AI and no-code help you shorten the path from idea to launch, but they don't decide what problem you should solve.
Specifically, check three things.
First, can you articulate the user journey? Can you explain it without technical jargon, in plain language: who uses it, what they see first, what they click, what they submit, and what they ultimately get.
Second, can you list the data structures? At minimum, you should be able to write out core data like users, orders, products, content, appointments, and payment records, and how they relate. Many projects don't die on the page — they die from not thinking through data relationships from the start.
Third, can you build a minimal closed loop in one to two weeks, give it to real users, and get the first person to pay? If not, the cut is probably still too broad.
Condensed further, you only need to answer four questions: Who is the user? What is their most painful problem? What three to five steps are needed to solve it? At which step can you start charging earliest?
Startups rarely die from not being able to build it; more often they die because nobody wanted it in the first place.