Skip to main content

A small team bringing every employee closer to 'one person is a company'

CloudBase TeamCloudBase Team
10 min read

In Shanghai, a small team of a few dozen — Meiya Fengniao — is running an experiment in organizational efficiency.

Meiya Fengniao focuses on enterprise data query and analysis services, with a business model similar to Qichacha and Tianyancha. Through the differentiated "register and get 5 years of SVIP" strategy, it's rapidly accumulating users and expanding its market. But for a team like this, sustaining product capability, service quality and market coverage in the competitive enterprise-data track by simply adding headcount isn't the optimal answer.

Over the past half year, Andy, head of the AI department, has been pushing one goal: use AI to give every employee "the productivity of one person being a company".

"What we're doing is OPC, One Person Company. This goal is becoming more and more possible." — Andy, head of AI at Shanghai Meiya Fengniao

Many things used to be shelved because of production-tool limits

A big chunk of Fengniao's business is data crawling and ingestion. A product manager decides "we need this data", files a request with a crawler engineer, who schedules it, writes the crawler, ingests it and publishes it. From requirement to usable, a complete chain is usually weeks.

Engineers have limited time; what gets scheduled is the main-product requirement. What doesn't get scheduled is the "also wanted, but not urgent" long tail. HR wanted to run a team-building vote, and used Wenjuanxing as a stopgap. A business colleague wanted to peek at a competitor's public data, and had to file a request and wait.

"Before, a product manager could basically only file requirements — they couldn't do the details. To be blunt, only people who can code can turn an idea into something that runs. The other 80% of the company, however clear their ideas, had to queue behind that 20%."

What Andy targeted first when pushing AI Native was exactly this.

A product manager opens CodeBuddy, connects to CloudBase, and runs it themselves

Here's a real collaboration flow.

  • Before: the product manager says "I want this website's data for these fields", the crawler engineer takes the requirement, develops, ingests, and it comes back to the product.
  • Now: the product manager opens CodeBuddy (Tencent's AI coding tool), connects to a CloudBase, and tells AI directly: "I want to crawl this data from this website, ingest it here." AI writes the code, runs it, and lands the data at the specified location. The product manager doesn't write a single line.

Andy knows this combo best; the standard dev chain he recommends to the team is:

  • AI coding tool: CodeBuddy (Codex / Claude Code also work; Andy prefers domestic tools)
  • Integration: MCP or Skill, letting the AI coding tool call CloudBase's capabilities over a standard protocol
  • Backend / compute: CloudBase provides static hosting and object storage

CloudBase does two things in this combo.

Give AI a "safe, physically isolated environment"

"You have to consider that AI has uncertainty when you develop with it. It's smart and flexible, but if it runs in production, it can easily cause disaster. Let AI work in a safe environment — no matter how it messes up, it won't ruin the results."

Hand the whole CloudBase to AI. AI installs environments, runs commands, writes code, debugs — anything. After development, package the whole environment into a docker image and migrate it to production (CloudBase's own image service, or the company's other host containers).

Andy calls this usage "an isolated physical machine for AI development." It solves the thorniest problem in AI coding today: AI's uncertainty vs production stability. It's a usage he figured out himself — no existing tutorial.

Make finished work immediately usable

Andy's first project trying CloudBase was directly hosting the finished app on static website hosting, getting a public link everyone in the company could access.

"Host it on CloudBase when done, and access it through a public link."

Development and deployment are continuous — no "find an ops colleague to help publish" step.

Under a month, the team produced about 10 internal apps

This combo ran through Fengniao faster than Andy expected.

The first batch was lightweight survey and voting apps. HR's team-building vote, once done through Wenjuanxing, now became the company's own small website, hosted out.

Next came data collection. Business colleagues tell AI themselves to "crawl this website's data, ingest it here", and crawlers run on CloudBase.

Then some POCs, hosting AI-written demos directly on CloudBase for internal validation.

"Now there are about 10, because we have plenty of things to do. With AI development, it's actually fast."

10 apps in a month. Behind that number is the first time non-technical roles in the company could independently deliver an accessible, usable internal app.

More concretely, the change in the collaboration chain:

  • Before: all internal needs → find R&D → schedule → wait → launch
  • Now: everyone uses AI coding tools + CloudBase to do their own needs → launch themselves

R&D colleagues are freed from the "bottleneck" position to work on architecture, models and the AI framework itself. Long-tail needs are absorbed, and main-line needs get more R&D resources.

Fengniao is an SMB, with no big-company AI platform investment and no dedicated AI tooling department. Andy and a few colleagues walked this path through in under half a year. There's no existing tutorial — they left footprints on a road no one had walked.

If this "one person independently delivering an app" capability needs a name, OPT (One Person Team) fits. One person is a small team; the AI coding tool is the keyboard, CloudBase is the backend scaffold, and the finished product is hosted out directly for others to use by opening a link. This was something business roles in B2B companies couldn't do before — now they can.

OPT is the capability unit. One level up, the OPC (One Person Company) Andy is pushing strings all these OPTs together: when everyone can deliver value independently, the company approaches "every employee is a company."

Andy's experience

Half a year of pushing AI Native, Andy distilled a few plain judgments.

The key to AI Native is whether non-technical teams can use it

"My own architecture and ops capability is fine. But going AI Native now, the most important thing isn't whether the technical team can do it — we want to popularize it to everyone in the company, especially non-technical colleagues."

The technical team using AI is baseline. Letting non-technical colleagues use AI to directly produce business value is the real turning point.

CloudBase suits non-technical roles too

"I personally think CloudBase's biggest user group isn't those doing tech or AI specifically. I have N machines and N resources, and I've probably built my own habitual way of using them — for me anything works the same. But for many non-technical people, or people without many resources, CloudBase might be their only channel."

Technical people have their own cloud-resource habits; CloudBase is an option for them. But for an HR, a product manager, a business colleague, asking them to register a Tencent Cloud account, manage SSH keys, set up environments and configure firewalls — one hurdle blocks them at the door. CloudBase flattens all this to "AI sets it up for you, you get a public link", and that's its greatest value to a company.

Design the architecture yourself, let AI write the code

"I personally prefer domestic tools, including CodeBuddy. I did some architecture design; model capability gaps are small now. If the architecture design succeeds, these tools will definitely work well. If you use Codex or Claude, you'll rely more on someone else's design — disadvantageous in the long run."

Model capability gaps are converging fast; the tool is no longer the variable. The variable is whether the architecture is your own. If the architecture is yours, the tool is just a handy tool, whoever's it is.

OPC happens in two steps

"Short term, we'll first embed the flow into the existing system; can't reach 100% OPC, only cover part of the flow. In a few months we might reach 50% OPC — no manual management, all AI. For 100% eventually, I think the key is you can't use the old framework; you have to build a completely new framework for AI, then pour the old stuff in."

Step one, embed AI into the existing flow to reach 50% OPC — half the company's flows no longer need manual follow-up. Step two, redesign a new AI-native framework, migrate all existing resources over, reaching 100% OPC.

"We're at about 15% now, preparing to do more. The biggest point in the coming months is raising the OPC ratio to about 50%."

From 15% to 50% to 100% isn't a number on a slide — it's the real timeline Andy set for his team. This is Fengniao's AI Native roadmap for itself.

Who Fengniao's practice matters to

  • If you're in business, product, operations or HR: you've probably felt this — you clearly know what an internal tool should look like, but you can't build it, and R&D's schedule is never as fast as you want.
  • If you're a tech lead or boss: you've probably done the math — R&D resources are among a company's most expensive costs, and spending them on long-tail internal needs is waste. When non-technical colleagues can build internal apps themselves with AI + CloudBase, R&D resources are freed for the truly core work.
  • If you follow AI Native, OPC/OPT topics: what Fengniao does is now referenceable by many SMBs. OPC can also happen inside an SMB's organization. From OPT (One Person Team) to OPC (One Person Company) is a progression from "capability unit" to "organizational form."

A company truly entering AI Native is measured by whether it has brought every person close to the OPT and OPC state.

The organizational difficulty is worth mentioning more than the technical one

Talking with Andy, he kept returning to one point.

The technical stuff isn't complex — half a year runs it through. The hard part is organizational. It's about willingness to change colleagues' work habits and bear the cost of short-term efficiency loss for a better long-term form.

"The early phase is definitely slow; once it's used, creating an environment takes minutes and it's fast. Promotion takes time — you gradually persuade people and change their work habits."

Willing to spend a month or two persuading colleagues to change habits, willing to genuinely make AI Native a company-wide thing — this is a rare kind of push in a small company.

CloudBase is an invisible character in their story. During development it's the AI's physically isolated machine; when done it's the public link; when no one uses it, it gets reclaimed. It's behind the scenes, present at every step.

In closing: one enterprise usage of CloudBase

Fengniao is an Enterprise-plan CloudBase user. The CodeBuddy + static hosting + Docker image migration chain was summarized by Andy and his team as they went — no tutorial, no solution consulting, assembling CloudBase's standard capabilities to their own needs.

This is one way to use CloudBase in an enterprise. You can start today; the minimal path needs just one AI coding tool account and one CloudBase environment.

🔗 Try CloudBase now: https://tcb.cloud.tencent.com/

If you're already on the path, we welcome your submissions to share!


What is CloudBase

Tencent Cloud CloudBase (cloud development) is Tencent Cloud's full-stack integrated backend infrastructure for the AI era, providing cloud functions, cloud database, object storage, static hosting, AI model hosting and other core capabilities. Paired with the Skill and MCP protocols of AI coding tools like CodeBuddy / Codex / Claude Code, it lets business roles, product and R&D all take on business needs directly.

Build your next app on CloudBase

An all-in-one backend covering database, cloud functions, static hosting, and AI capabilities.