One-Person Company, Nearly 100K Monthly Revenue: The Three Businesses I Run (OPC Series-3)

93,876.60 yuan.

That's my actual income for October 2026, from three lines of business: courses, self-media brand placements, and software development delivery.

This is revenue, not net profit. Tool fees, delivery costs, and taxes still need to be deducted.

Right after the money came in, someone already came to take it.

Let me be upfront: here's a real bank screenshot, October's revenue, but how many pitfalls are actually there? This long article will spell it out for you.

I did game development for 15 years, left my job this May, and now run everything alone.

One person, one computer, a few AI tools - that sounds easy. But add the next sentence and it's different: you're the one teaching, negotiating brand deals, developing. When a client says "find me someone in charge," the person who shows up is you.

A revenue screenshot only captures numbers, not all this work. Let's spread it out.

What do these three businesses sell, where do customers come from, and how much of the money you receive has to stay aside for work?

01 Everyone's using AI, but three groups of people buy different things

Courses sell "teach me how to do it," development delivery sells "do it for me."

Students need to learn how to do it; development clients usually don't want to do it themselves. You're getting paid for doing it for them, but you send over ten development tutorials: learn this first.

They paid, but problems didn't decrease, and now they have homework.

My courses have platform channels and private channels, mainly for individual users. The biggest mistake here is thinking that if you give enough materials, students will learn.

Give a bit of theory, throw in a set of tools, add a chapter on trends.

The student just found the upload button, and the teacher is already leading them to envision the industry's future.

They see the future, but the file still hasn't been uploaded.

Recently I redesigned the course: put knowledge back where it belongs. When it's time to write a prompt, then explain how to describe the task, materials, and requirements. When it's time to check results, then explain what to check. Leave time for students to act, send, and wait for AI to respond.

The teacher finishing the lecture doesn't mean the student finished the task.

Take a report-organizing class as an example: the teacher clicks one step, the student follows one step, and the result appears. Switch to a different table, and the student asks: "Teacher, which line do I copy this time?"

The teacher prepared the materials, avoided the errors, and tuned the answer. The student just copies. The service is thorough, even the parts where the student should think for themselves are done for them.

At home, given a different table, they still can't do it, so they just bookmark the replay.

The course wasn't wasted, but the bookmark list graduated first.

So the first pass is guided, the second gives them a checklist to do it themselves, the third uses a similar type of material to do it independently. Handle duplicates, verify totals, find anomalies. Observe where they get stuck, and supplement that step.

Only when they can apply it to a new material can you say they've taken away the skill, not just a chat log.

Grading homework can't just be "your prompt isn't precise enough." If the student asks where it's imprecise, you say "think about it."

If a student buys a course and still has to guess the teacher's prompt, that's a matryoshka course.

Point out which requirement was missed, which check wasn't done, let them fix it and rerun, and see how the result changes. Students need feedback that tells them what to change next, not just a sense that the teacher is knowledgeable.

The value of a practical course must hold up after the teacher stops talking.

But you have to plan the time for grading and Q&A before the course starts. Say 12 students, each with two assignments, eight minutes per assignment, that's 192 minutes for this round alone, not counting resubmissions and Q&A.

A recorded course can be sold one more copy, but a teacher can't be copied one more.

Self-study materials, group Q&A, guided practice, and individual grading should be priced according to their service load.

Otherwise, when recruiting you say "ask any question." After the course starts, messages pop up one by one, and you just want to ask: "Can you all come one at a time?"

The students do cooperate, they come one at a time, but right after one leaves, the next one connects. You just changed "can't answer all at once" to "can't answer them one by one either."

Brand placements are another trade: brand pays, readers see content.

The effect the brand wants must be broken down first: exposure, reads, clicks, registrations, actual usage, purchases - which step are you aiming for?

Otherwise, when you deliver, you say "the reads are good," and they say "why isn't anyone buying?"

You think delivering an article is the finish line, but the brand is waiting for sales performance.

Set the goal first, then set the number of articles, revision rounds, publish times, and material usage scope.

If you don't clarify upfront, every revision makes both sides guess again what the other wants.

On the reader side, don't just change the font of a feature list and serve it up. Reeling off model parameters and feature names - readers aren't not taking it seriously, they genuinely didn't plan to attend orientation for your product.

For example, introducing a spreadsheet tool: use a sample list to demonstrate which records are duplicates, which just share a name, and how to verify nothing was accidentally deleted after cleaning.

First explain how to judge duplicates, then show the cleaning process, then compare the original and cleaned tables for counts and retained records. Wherever AI helps, explain that step. Readers need to know whether this table can be safely handed over, not meet more feature buttons.

No matter how capable the product is, you have to explain what problem it solves for the reader.

After publishing, check layer by layer. If readers already clicked in but are stuck at registration, and you're still changing the title, it's like guests are inside the store, but you're taking down and putting up the sign, and there's not even a seat inside.

Look at the data for the step you can see, and judge the effect of that step. Without conversion data, pretty read counts can't be reported as revenue.

The third business is software development. I charge a development delivery fee, not subscription SaaS revenue.

Clients will take the software to use, so acceptance can't just be how smoothly you demo it. Take an order system: have the actual users use real or authorized data to go through registration, query, and status updates.

Your demo being smooth doesn't mean the client can use it. If they're lost once you leave, the handover isn't done.

After launch, people still stick to Excel. Investigate why: is entry more cumbersome? No one took over? The old process didn't stop? Or does the new system also require re-entering everything?

Before buying they filled in one form; after buying they fill in two.

Buy one get one free: buy software, get extra data entry work.

Only when the actual users can use the system according to their workflow can you say the system has been properly handed over. All feature boxes checked doesn't mean all client problems are solved.

If you want to do the same, first choose based on the results you can deliver: if you can teach others to do it, try a short course. If you can present a product in a real scenario, go for content collaborations with a complete portfolio. If you can deliver a working system, take on development.

Then ask yourself three things.

Where are the first batch of buyers, how soon can you get paid, and how much time and cost do you have to front before the money comes?

Buying an AI membership doesn't mean these three businesses will take off. The membership will remind you when it expires, but you still have to figure out why customers didn't come.

02 As one person, you can't avoid cross-departmental wrangling

A one-person company has no departmental walls, but the departmental work doesn't disappear.

When negotiating a deal, you promise to deliver on Friday. Once you start production, you realize development alone takes three days, and two existing clients are waiting for replies.

When you're the salesperson, you promise easily. When delivery time comes, you wonder who made that promise. You check the chat history, and the avatar looks familiar.

You found the person who promised, but the work is still yours.

There's only one person, but there's no shortage of roles.

With my three types of business, you need to handle at least eight responsibilities:

• Direction and product: who to sell to, what problem to solve, what not to do.
• Content and acquisition: make cases, attract the right people.
• Sales and business: negotiate needs, promises, scope, and price.
• Project coordination: chase materials, schedule, handle changes.
• Production and quality: build the thing, check if it's deliverable.
• After-sales and usage: handover, Q&A, handle issues within scope.
• Finance and admin: follow payments, invoices, costs, permissions, backups.
• Review and collaboration: adjust terms, pricing, and tests; delegate tasks, accept collaboration results.

These tasks also compete for attention: posting content gets likes, fixing tests gets no praise, new client inquiries sound like money, old client errors sound like work. Take the new order first, deal with the old problem at night. By night, the new order also starts asking for progress.

New orders and old problems don't cancel out; they just both occupy your schedule.

So scheduling can't just say "done by Wednesday."

For every order, record clearly: what you promised to deliver, who provides materials and when, when production and checking happen, who accepts, when you get paid, and until when after-sales runs.

Handle routine consultations and Q&A in batches, keep a separate channel for urgent issues that affect usage, and reserve fixed time for future acquisition. When a new order comes, look at the schedule, not the momentary impulse.

If your schedule is full and you still accept an extra order, during negotiation it's called challenging yourself; during delivery you'll know who messed you up.

Repetitive organization work, first drafts, and well-defined modules can be delegated to AI or collaborators. Professional matters like finance and tax can also get help.

Who to sell to, what you promise, and whether the result passes - you still confirm these yourself.

Still reserve time for explanation, checking, and acceptance. Provide materials and permissions as needed.

If AI writes something wrong, you have to fix it. If an outsourced collaborator delivers something wrong, you have to verify it. You can't tell a client "the person in charge is outsourced."

Every week, check again: which materials are missing, which payment is off, which after-sales issue keeps recurring, and what to change in the next quote, terms, or test. It's okay to take fewer orders, but don't let all eight roles say "received" at the same time, with none able to say "done."

03 When someone says it's troublesome, don't rush to start a business for them

Take a consolidated report as an example.

A colleague says merging spreadsheets every week is annoying. You immediately think of models, automation, deployment plans, and you almost want to start on the spot. They just vented two sentences, and you're already thinking of company names.

First ask:

Is this something he's willing to pay to solve?

He says he'd like to, but the budget needs to be asked from the leader. The leader says, "Can't we still use it now?" Continuing the conversation, you find the sample table is managed by someone else.

The one complaining, the one holding the purse, and the one providing materials - finally all three are gathered.

You thought you were developing a tool, but you've actually started forming a team.

When someone truly needs a problem solved, someone can approve budget, materials are obtainable, and someone accepts the result - only when all these are clear does it approach a deal.

Don't send a long questionnaire first. Get an authorized sample, and follow the most recent work: how many tables, who merges, how often, where errors tend to occur, and who fixes them.

Then ask how they bought similar services last time: who decides, who provides materials, who confirms, and how payment works. In a small company, the boss might decide alone; in a big company, the loudest complainer may not have payment authority.

Someone desperately needing something doesn't equal immediate payment; there may be three layers of approval in between.

He's genuinely anxious, but approval genuinely takes time.

The first order can handle only one fixed format of report. For example, propose a paid trial like this:

"This time, only handle this one format. You provide a desensitized sample table, and I deliver the merged result and an anomaly list. Set the trial price, delivery time, and who verifies. If the format changes, we'll discuss separately."

Giving a small sample to prove capability doesn't mean doing the full project for free. If manual assistance can complete it, deliver the result first; don't wait for the entire automation to be built.

Negotiating this way also lets you breathe: you don't have to guarantee the whole company is worry-free from now on, just that this table is delivered clearly and verified clearly. A smaller first order leaves you room to act.

First prove someone will pay for this result, then decide which steps are worth automating.

Sometimes tech people say: "Once I've learned all the tools, I'll start finding customers." By the time you finish learning this version, the next version updates, and you have to learn again.

The customer hasn't decided whether to buy, but the vendor already decided when you open for business.

What's missing for the first order is a buyer, and you just added another server for yourself.

Next look at three things: payment, usage, and repeat delivery.

Someone pays, meaning they're willing to pay for the result you promise. The client actually uses it, meaning what you delivered is actually used. When a second similar client can be handled the same way, you're approaching a repeatable business.

The payment screenshot is sent, but the customer never logs in again. Don't just study how to format the screenshot; ask them where they're stuck. Every order makes money, but if you have to redo everything each time, that can be a fine custom service, but don't rush to label it a standard product.

A standard product can't be standard by starting from scratch every time.

When calculating value for a client, don't just pick an hourly rate, multiply the two hours saved, and declare you've earned money for them. Those two hours might go to other things, or just mean leaving work early.

Ask what was stuck before, what errors cost, and what can be accomplished now.

Only improvements the client can see and agree on are suitable for pricing.

They just left two hours early, and your PPT says they earned another batch of money - that math doesn't work.

04 Many likes, but where are the buyers?

When the comments under your content are all "awesome," it's nice. But the problem is, when you reply "thanks," your bank doesn't reply with a deposit.

First identify buyers, then choose channels. Individual learners might search for tutorials and methods; enterprise clients might trust peer referrals, complete case studies, and whether you understand their business. For overseas tool users, look at how they usually learn about products and how they pay.

Wherever customers are, go find them there.

Don't move to a new platform just because you heard there's a bonus there today. You've opened a row of accounts, but customers haven't remembered you yet. You need to remember how many accounts you haven't updated today.

Take the report case: those who want to learn should know where to go to learn, and those who want you to do it should bring what materials to ask. Make that clear.

If you leave only "welcome to chat," people come to chat, and then you complain they're not converting.

You said "let's talk," so don't be surprised they only talk. If you want to take certain orders, say so clearly.

You can do it this way: short content helps people spot the problem, full case studies in a WeChat Official Account help them judge if you can do it, those who want to know more leave contact info, and finally they choose self-study, guided practice, or done-for-you.

After leaving contact info, there should be something worth following: new cases of similar problems, public Q&A, actual updates. Contact people in the way they agreed, follow platform traffic and external-link rules, and don't treat adding a friend as authorization to send daily ads.

First get one path that brings suitable customers working, then adapt to other platforms.

The same case can reuse facts and materials, but the opening, length, presentation method, and next-step entry should change with the platform and audience, not paste one draft everywhere.

Whether self-study, guided practice, or done-for-you, every item must solve one complete problem.

Don't make a cheap course stop at the key point and say: "to learn how, go to the next course."

Buying the first course is to solve a problem; buying the second is to solve the problem the first didn't.

That's not course progression, that's billing for the problem.

Of course, consultations will also include people who want materials, have no budget yet, or don't match at all. Record the source, what they ask, whether they match, quote, payment, delivery, refund, so you know which step to change.

If you don't know the source, write "don't know." Some people read an article first, then hear a friend's recommendation, and finally send a private message. The private message is the last step, but it doesn't mean no one carried the sedan chair before. Commission should be settled according to agreement, but you can't assume the customer is only influenced by that channel.

Suppose ten consultations, eight just want the free process. Look back at your entry point. If you write "one-click," "free," "free stuff," people come for that.

This time you can't blame readers for not understanding; they understood perfectly, which is why they didn't bring a budget.

If people don't match, change the cases and entry points. If the right people don't buy, check promises, evidence, price, and timing. If there's a fight after the sale, fix delivery.

When almost no one asks, distinguish: is it that the target audience didn't see you at all, or that they saw but don't know how to buy, or that this problem rarely occurs anyway? With too few samples, go talk to a few real buyers first, don't sentence the whole business to death based on two quiet days.

If delivery is already blocked, pushing more traffic is just handing out queue numbers to everyone.

You think you're doing promotion; old clients think you're preparing to vanish.

Track acquisition costs too. Shooting and tools are cash; writing, replying, and communicating are time. Keep the two books separate.

Just because you don't pay yourself a salary doesn't mean that time is a gift from the platform.

If the proportion of old clients rises, look closely: is it repeat purchases increasing, or new customers disappearing? If ten people at a table, nine left, the remaining one is 100%. A restaurant can't advertise customer loyalty doubling.

Use the same time window to look at actual repeat purchases, new additions, and headcount, not just percentages.

Percentages will selectively report good news; headcount isn't as smooth.

After a good order, ask the client how it's working, and after permission, organize a case study. If you want referrals, give a shareable description: who it's for, what problem it solves, what you don't take.

If someone agrees to refer you, they didn't agree to write your recruiting copy from scratch. Prepare the materials so the kind person doesn't have to prep a lesson first.

They open it, see who to send to, and forward it.

Don't say "just forward it" while actually making them write the intro text.

05 The better your channels sell, the more scared you become?

Someone helps you find customers, originally so you can focus on delivery. But if you agree to whatever the channel promises, you'll end up focusing on adding features, and the features are ones they promised for you.

Let's put the numbers out. Assume a product sells for 1,000 yuan, channel commission 700 yuan, delivery cost 250 yuan.

1000 - 700 - 250 = 50 yuan.

Fixed expenses, taxes, and your own labor aren't counted yet. A thousand yuan circulates through your account and leaves 50 yuan - even as a toll fee it's polite.

If commission is 800 yuan, each order loses 50 yuan. Sell one, lose one, and the other side is urging: "Quick, scale up!"

Again cry for small margins and volume: the volume is products, the thin is your savings.

Refunds also change the outcome. Still with 700 yuan commission, sell 10 orders, 2 refund. Ten orders delivery cost 2,500 yuan already spent. Remaining revenue 8,000 yuan. Even if you only pay commission on the 8 that didn't refund, that's 5,600 yuan.

8000 - 5600 - 2500 = -100 yuan.

Did ten orders, and ended up paying 100 yuan out of pocket.

It turns out the customer wasn't buying your service; you were paying to get work.

This is when you should stop and recalculate, not find another channel to sell a few more orders.

The commission cap should be calculated backward from delivery costs and the money you need to keep.

If someone offers 70-80%, first look at what they're selling and how heavy the service is. Don't just follow the split. They sell materials; you have to grade each assignment. Same course sale, but the service time you spend is far different.

A high commission is more suitable for products with low incremental delivery cost per new order and controllable refund and support burden. If you plan to make money from repeat purchases, use actual repeat data, and don't spend money that hasn't happened yet.

When choosing a partner, also look at whether their audience matches your buyers and how they've introduced products in the past. Start small, see if the customers who come are suitable, what the channel promised, how many refunds, and how much is left after costs, before deciding to expand. A big follower count only proves they can summon people, not that those people need you.

Whether commission is based on list price or actual received, whether refunds claw back commission, how new and old customers are counted, when to settle, and who handles after-sales - agree on all of it first. After money is paid out, when you discuss clawbacks, you say "that's not what we agreed," and they say the same.

Also, materials can't just be a payment QR code. Sample cases, pricing, suitable people, delivery contents, effects you can't promise, and common questions should all be explained.

Take an example of course distribution: you planned a weekly group Q&A, but the channel's poster says "anytime Q&A." A student sends a screenshot at night, chases progress during the day, you say it's not Q&A time yet, and they send the poster: "This doesn't say that."

You look at the course schedule, they look at the promotional image. Both have evidence, but they're not buying the same course.

You haven't launched one-on-one coaching, but someone else is already enrolling students for you.

At this point deleting the poster doesn't help. What about people who already paid? You have to explain, negotiate remedies, and handle refunds if necessary. So before sending materials out, verify the commitments.

Align service time, frequency, and feedback method item by item. Handle what's already sold according to actual commitments.

You can't let students pay for commitments that weren't aligned between both sides.

Channels amplify not just conversion but also promises. First align what you're selling, then let more people sell it.

06 Why is a 20,000-yuan order worse than a 6,000 one?

When you hear a quote of 20,000 yuan, you perk up. You haven't finished the 6,000-yuan discussion, and you already want to reply to the 20,000-yuan customer first.

But what the customer buys isn't just the result; it's your time. Take two hypothetical orders, including pre-sales communication, production, revisions, and after-sales in the hours. Don't just count the time your hands were on the keyboard.

The customer sends a half-hour voice message. Listening and replying also count as work hours. Not touching the keyboard doesn't mean you weren't working.

Order A: 20,000 yuan revenue, direct cost 4,000 yuan, 80 hours total.

Order B: 6,000 yuan revenue, direct cost 1,000 yuan, 10 hours total.

A after direct costs: 16,000 yuan remains, average 200 yuan per hour. B after direct costs: 5,000 yuan remains, average 500 yuan per hour. Fixed expenses aren't deducted yet.

This isn't net profit, nor is it an hourly wage you set for yourself.

A bigger amount isn't necessarily a better deal; sometimes it just buys you for longer.

You think you've met a big client, but they might think they got a wholesale price.

But you can't go the opposite way and only take B. Can you really find several B orders a month? If you only find one, and multiply it by eight in your spreadsheet, the other seven clients are responsible for acquisition in the calculator?

Whether you can get the order, deliver on time, and keep enough after costs - these three things together matter.

Many small orders increase communication and switching overhead. A big order with clear scope, reliable payment, and reusable assets is also worth taking. Whether the client thinks it's worth it and whether it's profitable for you - both sides need to be calculated.

If you're slow, you can't make the customer pay for every bit of fumbling. If you're fast, you don't have to offer a discount voluntarily.

The customer buys a result, not crowdfunding based on how many nights you stayed up.

Worse, the money is set, but the work keeps growing.

Take a requirement modification example:

The client says just change a little: a little on the homepage, a little on the backend, a little on the database.

Indeed, not much changed, but little by little it became another project.

The client also says it's urgent. I check the contract. They didn't buy expedited, only urgency.

Before leaving, they add: "I trust your professionalism."

I say, "Then follow my plan?"

They say, "That won't work."

Requirements grow daily, budget stays frozen. That's asking me to respond to ever-changing needs at an unchanged price.

New requirements can be done, but price and delivery time must be reconfirmed together.

If an originally promised feature has a bug, fix it. For unclear disagreements, lay out the original agreement and the added parts. Don't decide who's right by who stays up later.

Function scope, who provides materials, deployment method, who accepts, how changes are handled, maintenance until when - write it all down before work starts.

You think you're selling finished software; the other side thinks it includes being on call. Even if both sides are polite, you'll still fight later.

Long-term maintenance is separate. Say 30,000 yuan a year, 20 hours per month actual, 240 hours a year, average 125 yuan per hour, before costs.

It sounds stable at 30,000 a year, but when you put it on the calendar, you find every month has work waiting. Add "on call anytime," and the customer isn't just buying work hours; they can decide which meal you interrupt and which weekend you stay home.

"Find me anytime when something happens" - and when nothing happens? Still on standby.

Separately agree on failures, new features, response time, and handling scope.

If you need higher guarantees, match it with fees and dedicated scheduling.

You can sell cheap, but you can't sell cheaply without upper limits on promises.

For projects with too much uncertainty, first do a paid diagnostic or small prototype to pin down main issues, then deliver in phases. If you can't see the road yet, don't promise to drive the whole way.

07 The books show profit, but the card is empty?

Back to that hypothetical 20,000-yuan order.

Before work starts, you have 1,000 yuan. Client pays 4,000 yuan initial payment. You spend 4,000 yuan direct cost. The account returns to 1,000 yuan.

The initial payment didn't not come; it came, signed in, and left.

Second week, fixed expenses 2,000 yuan due. The 16,000 yuan final payment arrives in the third week.

The project has margin after direct costs, but right now you're short 1,000 yuan.

The final payment comes next week, but the bill is due this week. You can wait for money, but the bill may not be willing to wait.

When payment dates don't align, profits on paper may not cover the money due now.

Arrange incoming and outgoing payments on a calendar until the committed project ends: initial payment, tools, outsourcing, fixed expenses, acceptance, invoicing, final payment, each with its date. Acceptance passing doesn't mean invoicing that day, and invoicing doesn't mean payment that day. Don't count acceptance, invoicing, and payment on the same day just because you're in a hurry to collect.

Then push the largest receivable later and see when you'll be short. If you can't bear it, adjust collection milestones, payment schedules, or set aside funds. Clients will probably pay on time, but expenses are certain to be due. You need money to cover those days.

Don't rush to spend advance payments. The balance rises, but delivery costs, refund possibilities, taxes, and pending expenses are still ahead.

Money came early, but the work didn't say it won't come.

Advance payments correspond to future obligations. First set aside enough for delivery and payable items, then see what can be moved.

Don't celebrate this month, then next month open new orders to pay for the celebration.

Annual tool subscriptions are the same. Divide the page by twelve months, like skipping a small milk tea every day. You think it's fine and click pay.

It doesn't sip with you; it gulps all twelve months at once.

Arrange based on conservative business volume and actual deduction dates. Don't let one best week guarantee the whole year.

Payment collection must follow the whole delivery process, not just be remembered after completion.

Find needs, negotiate commitments, collect materials, produce and test, accept and hand over, collect payment and after-sales, review and reuse. The previous eight roles talk about who's responsible; here we talk about how one order goes through.

Everything is your responsibility doesn't mean you can remember everything.

Only after finishing do you realize materials are missing, no acceptance person was scheduled, and the invoice wasn't submitted, so the final payment isn't even at the step where it can be paid. You wrote all this code, but the thing that blocks collection might be that "I'll send it later" email.

Keep a record for each order: what's delivered, what's not, who confirms, when payment arrives, what's stuck now, and who does the next step.

Course orders can be simpler, but development projects need detailed key milestones.

For example, if a client is missing a test material, record who provides it, by when, and which downstream date the delay affects. When a milestone is reached, confirm the milestone payment together. Don't say "happy cooperation" while both sides are waiting for the other to speak first.

At delivery, hand over files, accounts, usage instructions, known issues, and after-sales period together. Ask the designated person to confirm and keep an acceptance record. Sending successfully only proves it was sent out. Whether they can open it, use it, and accept it is the next story.

Handle common questions in batches; keep a separate channel for urgent ones.

If every message cuts the line, the schedule becomes decoration.

The client asks "why isn't it done yet?" You can't answer "I've been busy replying to you in time."

When collaborating, give only necessary materials and permissions. Back up important data, and revoke access when done. If you hire someone to fix one module, don't move the entire archive room over. Convenient full access now means inconvenient cleanup later.

08 Revenue growth shouldn't just mean you're busier

Want to take a break after earning the money from two orders, but after finishing those two new orders come, and you still can't bear to refuse.

Always thinking about resting after busy work, and also hoping new orders never stop.

Wanting both non-stop orders and free time - these two wishes aren't that easy to combine.

I prefer to stage by where you're stuck.

First 1,000 yuan: see if you can receive the money and deliver the result into the client's hands, and get them to actually use it. A monthly income of 10-20k: see if similar needs can repeat. At tens of thousands to 100k: see if orders can be delivered on time and keep money after costs.

These are capability steps, not an income upgrade table.

Income reaching a level doesn't mean you can handle all these things. Several problems may co-occur.

First barrier: someone really buys, and after buying they really use it.

The easiest place to hide is learning. Research another tool, bookmark another tutorial, and wait until you're fully prepared to start.

You have to define what counts as prepared enough to show a client. Don't let your bookmark list set the start date.

Give preparation an actionable deadline: talk to real people about a specific problem, see how they currently handle it, make a presentable sample, explain the result and scope, and then verify deal, delivery, and usage. Watching fifty tutorials can't replace the first buyer's nod.

Even if a friend buys one order, don't declare market validation complete. Find another similar buyer who isn't a friend, and see if they're still willing to pay for this result. If you only get praise but no materials or willingness to pay, narrow the problem or change direction. Don't expect that continuing development will make them too embarrassed to not buy.

Second barrier: doing similar work again, with less hassle.

On the second order, you're still asking about material formats. On the third, you're digging through chat logs for steps.

The business is old, but every day you're new.

Organize commonly used materials, steps, and acceptance methods. Use them next time. Having fewer explanations, fewer omissions, and less rework is what experience accumulation means. If you only create an SOP folder but don't write into it, the house is there, but the experience hasn't moved in.

Third barrier: when orders increase, checking and delivery can keep up.

Suppose you can produce 4 drafts a week, but only carefully check 2. In two weeks, 4 pile up. You buy a faster generation tool.

It wasn't that you were too busy; now it's too busy, accelerated.

Divide tasks into: waiting for materials, ready to start, in production, pending check, pending client confirmation, completed. Don't just look at which column is tallest; look at who's near deadline, how long something's been stuck, and which waits truly block downstream delivery. If materials are missing, schedule a completion time. If checking can't keep up, first reduce new tasks and set aside checking time. If client confirmation is slow, agree on milestones in advance.

If you're stuck at checking, arrange checking first. Don't keep adding drafts pending check.

Fourth barrier: standardize stable, repeatable parts, or delegate them to collaborators.

Productization doesn't have to mean subscription software. For similar needs, fix the material format, delivery result, and acceptance method, then define price and delivery mode. You can make it a standardized service, with a human still doing the work.

If you rush to build a platform before the service is smooth, you still owe the previous client, and now you owe yourself a platform. No one is pushing, but you stay up late voluntarily.

Before you actually need to hire someone, you can try a small module: clearly state input, delivery sample, deadline, and acceptance criteria, and see if communication, quality, and rework are controllable. Once it works, keep reliable people and backups, so you don't beg for help at delivery time.

For outsourcing, calculate net time saved. Say you'd spend 20 hours doing it yourself. After delegating, explaining needs, checking, and rework take 7 hours. Released: 13 hours.

20 - 7 = 13 hours, not all 20 returned.

With a new order, those 13 hours might increase income. Without an order, resting is fine too.

If you free up an afternoon, you don't have to find three new clients. Eating on time and resting well is also doing less work. It doesn't have to become a revenue poster.

If the freed time hasn't attracted a new order yet, don't fill in three income entries in Excel and declare outsourcing made you money.

When a certain type of work is stable long-term, then consider a fixed hire. Beyond salary, count training, coordination, idle time, and rework. First have stable work, then find a person to take it, not hire someone to keep you company thinking about what the company should do.

Separate money you must pay regardless of orders from money that happens only when you take an order.

Ongoing expenses like office, fixed staff, and subscriptions eat cash in slow seasons. Project-based collaboration is more flexible, but unit price, communication, and quality management aren't necessarily lower. Compare the total burden under expected workload, not the word "outsourcing" meaning savings.

You can also take fewer scattered small jobs and do higher-value tasks, backing your price with results.

You being tired can be a reason to raise prices, but it's not a reason for the customer to pay more.

There's no line item on the quote for "the boss has been working hard lately."

Subscriptions especially need to think about ongoing value: reliable operation, necessary updates, support, maintaining effects. Don't feel that collecting a monthly fee means you must stuff in three new features every month. The customer wants stable use; you make them re-onboard monthly.

When income rises, also look at how much work hasn't been delivered.

A well-collected payment can be followed by half a year of catch-up deliveries.

The account is celebrating New Year, but you're still on duty.

09 AI got cheaper, so why are you more tired?

Some AI tool call fees are indeed cheap, but when the result has errors, how long you have to fix them isn't on the bill.

Assume processing 100 tasks, all needing 100 qualified results.

The cheap plan costs 100 yuan in call fees, with 10 hours of manual rework. Another plan costs 300 yuan, with 2 hours of manual rework. Internally, value your time at 100 yuan per hour:

Cheap plan: 100 + 10*100 = 1,100 yuan, so 11 yuan per qualified result.

Other plan: 300 + 2*100 = 500 yuan, so 5 yuan per qualified result.

You saved 200 yuan in call fees, but remediation took up 800 yuan worth of time.

It was said AI works for you, so why did you end up wiping its ass for eight hours?

This 800 yuan is a time comparison, not another cash payment to yourself. Cash tight but time free, versus orders full and no spare time, are different choices. Look at both books. Don't treat time as cash deposited, and don't treat not paying yourself as being free.

Don't test only with clean materials. When formats are neat, info complete, and requirements simple, tools look like honor students. In real work, a missing page, a wrong column, contradictions - suddenly you're the head teacher again.

Test with tasks you'll actually encounter, using the same qualification standard. Record waiting, retries, manual checks, and maintenance together.

If one tool only needs a glance to pass, and another needs to meet client acceptance criteria, of course it's unfair. It's not that the tool is cheaper; you lowered the pass bar for it.

Expensive isn't necessarily suitable, cheap isn't necessarily bad. Start with a small batch of real tasks to test: if the low-cost option meets the standard, use it. For a type of task that repeatedly has missing items, errors, or takes too long to fix, switch that type to a different option, then retest with the same standard. Don't switch the entire pipeline to the most expensive just because one task is hard.

For steps that rules and formulas can handle stably, let rules and formulas do it. Addition and subtraction already have answers; no need to ask a model for its opinion.

Look at how much work the whole process saves, not just how many seconds generation got faster.

Still check client materials, external conclusions, and final deliverables. If something goes wrong, reporting the model name to the client doesn't help. The client didn't fill in the model's payment code.

10 After this order, don't clear out the experience too

After delivery, you shut down the computer. Next time a similar task arrives, you re-find files, re-ask for materials, re-write steps.

The client's first time is understandable. Why are you also like a first-timer?

Courses leave exercises, checklists, common errors. Brand deals leave expression structures, material sorting, and test methods. Development leaves reusable modules, test samples, and deployment flows.

These accumulations can make the next order less effortful, but new products need retesting, and new clients' businesses still need to be learned.

What's reusable is the checking method, not the previous answer.

Otherwise, one review is enough, and from then on just change the product name.

If you really only change the name and the pros/cons and conclusion stay the same, that's convenient. But what you saved is exactly the review.

Who you write for should follow the problem. Technical readers want implementation, so talk implementation. Ordinary users want choices, so say who it's for, how to use, how much, and which step is error-prone.

It's nice that you've researched a lot, but that doesn't mean readers must learn all the terms to leave. If they ask whether they can save an hour, and you spend half an hour explaining terms, you haven't started saving their time; you've occupied it first.

AI can easily write introductions. What's worth keeping is actual judgment: under what conditions something really works, which step is wasted effort, and why this over that.

If you only change the avatar and not the content, readers might even mistake you for someone else, but it doesn't affect understanding.

After a review, at least one place in the next quote, course package, or test must actually change.

If Q&A runs over time, change course benefits and time budget. If requirements keep expanding at the same point, change quote boundaries. If the same error reappears, put it into testing.

On the next order, check whether it was used. Did rework decrease? Did communication save time? Change the step, not just bold "next time pay attention."

Actually change that step, and next time you can follow the new method. Have one less missing material to chase, one less delivery scope to re-explain - that's the real benefit of a review.

General methods and modules can be accumulated. Client data, work products, and materials must be used per authorization and made public appropriately. Having done it doesn't mean it's yours. Don't stuff the client's data into your case archive wholesale.

When talking to peers, bring a specific question: a quote, a sample, or a stuck step. That way they can point out what to change. After suggestions come back, test them in your own clients and orders.

Scrolling through hundreds of group messages without touching your to-do list isn't expanding business; it's just changing the chat background of busyness.

In Closing

93,876.60 yuan, worth being happy about.

But I'd rather explain the other side: courses, brand placements, and development delivery - you receive three kinds of money and take on three kinds of commitments. For now, these are still handled by me alone.

Students must learn, readers must understand, clients must use. The arrival notification only reports good news, not how much work is still pending.

As income climbs, delivery must keep up. After this order, leave something for the next order that saves effort.

If you want to start, you don't have to copy me and do three at once. First pick one problem you can solve, find someone who truly needs it, clarify scope, price, and delivery, from receiving the first payment to the other side actually using it.

Do it a second time, see if you can reduce rework and keep more money.

Don't rush to copy someone else's revenue screenshot.

First let yourself avoid repeating the first order's detours on the second order.

Thank you for reading my article.

If it's good, give it a like, a "watching", and a share. 🙂

If you want first-time push notifications, give me a star ⭐. Thanks for reading.

Open source knowledge base (real-time updates, discussion group): https://my.feishu.cn/wiki/OhQ8wqntFihcI1kWVDlcNdpznFf