Inside Kujiale, a project-management role with a non-CS undergraduate degree shipped two complete custom apps with backends and databases for two clients. No R&D involvement, no outsourcing. One person, VS Code, and one CloudBase.
Note: "Mini App" in this article refers to the lightweight web apps in Kujiale's SaaS app marketplace, unrelated to WeChat mini programs. We'll use "Mini App" throughout below.
The old SaaS problem: who takes on client customization, and how
Anyone in B2B has likely been stuck on this kind of demand: a specific client asks for something slightly different from your main product. Do it or not? Three paths:
- Have the client's own IT do it? Most SMB clients don't have an IT team.
- Have your R&D do it? R&D runs the numbers: it only serves one client, adds no value to other clients in the main product, won't make the release schedule, and the one-off cost is absurdly high.
- Outsource to a third-party service provider? Third-party collaboration is unreliable to begin with. The outsourcer takes the job and leaves; six months later the client wants a feature changed, and the original vendor may have switched businesses or vanished — the collaboration is dead.
Going around in circles, most of the time the client counts the cost and uncertainty and says "never mind, I won't use this feature after all", and the thing stops there.
This kind of demand actually has viable ROI — what's missing is a suitable position inside the company to take it on. Zhi Yi takes exactly this kind of demand.
More specifically: Kujiale makes cloud 3D home-design SaaS for designers, merchants and home brands. Merchants publish products on the platform — cabinets, materials, furniture — and clients and stores use these products to design and order. Products have lifecycles; after a while merchants delist them. But clients often have old orders and contracts still running after-sales or in negotiation, needing continued access to an already-delisted product. Merchants want "for a specific dealer, selectively open certain delisted products for a limited time, auto-closing at expiry."
A very typical client customization. It used to stop right there.
Three to four days, and he built the tool
What Zhi Yi built lives in Kujiale's app marketplace. A merchant can create an opening plan — pick which delisted products, target which dealer, set an expiry time, submit, and the system handles it automatically at expiry. Front end has a UI, backend has APIs and a database.
The whole thing took three to four days.
The stack is simple: VS Code + Codex (OpenAI's coding assistant) writes code; the backend runs entirely on CloudBase — cloud functions for APIs, cloud database storing config per client dimension, object storage for files. He basically never entered the CloudBase console. Once CloudBase's Skill and MCP are installed, "you just say what you want", and the rest AI calls on its own.
His own description is plain:
"For development, I just use VS Code plus Codex. CloudBase, from my perspective, is like a backend server; our program here is the front end — so it's basically a front-end and back-end program."
There are a few judgments worth sharing.
First, he thought through the data model himself. "Which clients can query — I definitely have to store my data by the client dimension." He works out the architecture first, and lets AI write the cloud database's table structure and field definitions. He doesn't write code, but he understands how business lands on a table. AI types for him; he calls the architectural shots.
Second, he chose not to adopt CloudBase's identity system. Users access this Mini App on the premise they're already logged into Kujiale, "making them log in again would feel disjointed". So the front end reuses Kujiale's main-site login state, and CloudBase only handles the backend APIs, data and storage. This is a product judgment beyond "development" — he knows where CloudBase should appear and where it should stay.
Third, release follows the main-site's existing flow. After writing, the compiled front-end artifacts are uploaded through Kujiale's release flow, published to specified merchants or the public marketplace. The front end runs inside Kujiale; the backend calls CloudBase's APIs. To the end user, it's a Mini App in Kujiale's marketplace — they never see CloudBase. This "invisible backend" approach lets CloudBase fit perfectly into Kujiale's main-site experience with no disconnect.
There's another project — PDF upload and preview — where he used CloudBase's object storage. Midway he hit a small issue: the default domain showed an interstitial page on PDF preview. He didn't wait for the process; he directly had Codex work around it. Problem solved, the tool went live.
A little over a month, solo, two projects both running in client business.
What actually changed for a company's business
If you only look at technical details, this is a "business role writes software with AI" story. Placed in a company, the change is more concrete.
The chain got shorter. This kind of demand used to require gathering requirements, outsourcing, handoff, acceptance, revision — a month-scale cycle. Now it's done in-house in three to four days.
The money returns in-house. Customization used to go to the client's own IT or an outsourcer — neither path brought money into Kujiale. Now done in-house, "the company recovers this revenue too; at the same economic input, the output got bigger."
Clients can be served and maintained. Outsourcing was one-shot; six months later a client wanting a feature often couldn't find the original vendor. Now in-house:
"Before, either the client had their own IT or we found an outsourcer. Now we can take it on ourselves — and more importantly, the ongoing changes, we can take those on too."
Behind the change is another layer Zhi Yi didn't state but you can see: the role that takes on client customization used to be only R&D or outsourcing; now there's one more option — the business role. The same scale of R&D resources can focus more on the main product, while customization demand is absorbed by this new chain.
If this path needs a name, OPT (One Person Team) fits. One person, one VS Code, one CloudBase backend, can steadily take on a category of client demand. It's not "a business role switching to R&D" — it's a new role composed of "business role + AI + cloud backend".
A few of Zhi Yi's approaches
Looking back at the process, he distilled a few things that qualify as methodology. This section isn't exhaustive, because it's genuinely one person summarizing while doing.
Have R&D do a POC first. Before Zhi Yi, a Kujiale R&D colleague did a full validation round — technology selection, running through the flow, and getting the IT service-provisioning done. "When opening the service, there might be process communication with our IT; after that, usage is simple, because Skill and MCP are already quite complete." For non-R&D roles, the first-mile cost is fronted by R&D.
Design the architecture yourself, let AI write the code. Decisions stay in your hands, AI helps type. Business logic, data model and product experience judgments are all your call.
Don't take over the main site's identity. Treat CloudBase as a gap-filler, letting it solve only the part the main site doesn't cover: backend, APIs, storage. Everything else returns to the Kujiale main site.
Let AI work around boundary problems. For the PDF project, he didn't apply for a domain; he had Codex propose a workaround. Between "I don't know what to do" and "let AI try first", the difference is one action.
Allow "wild paths". He says himself, against R&D's standard process, "what we do, to be blunt, is a wild path". Business roles don't carry the "code repo, CI/CD, release norms" burden — if it runs and solves the client's problem, it's fine. This approach works on the premise that it runs in parallel with the main R&D flow, without interfering or demanding from each other.
Why this might concern you
If you're in a B2B company in business, product, operations or customer success, you've probably met the kind of demand Zhi Yi takes. What it lacked was a position to take it on. Now AI coding tools plus an out-of-the-box backend create that position — people outside R&D can stand in it too.
If you're a tech lead or boss, your angle is more direct: R&D resources are constant, and the main product never ends. The customization revenue the company couldn't collect before can now be absorbed by business roles + AI + CloudBase. Same R&D scale, bigger coverage; same staffing, a step up in organizational efficiency.
If you're just curious how far AI coding can go, Zhi Yi's case has passed the demo stage — a non-R&D person wrote it, shipped it, ran it in real business, clients using it, and it's maintainable.
In closing: one enterprise usage of CloudBase
Zhi Yi's path was run on CloudBase Standard. The stack is VS Code + Codex + CloudBase's Skill and MCP. The capability is CloudBase's base capability, already open to all users — open it today, start today. No packaged solution, no waiting.
Business roles absorbing long-tail customization, R&D fronting the first mile, CloudBase as the invisible backend — this path may apply beyond Kujiale.
"Before, either the client had their own IT or we found an outsourcer; now we can take it on ourselves." — Zhi Yi, Kujiale
