Monday morning, the brief says only “build some software”
Last Monday, I picked up a private project in Hangzhou: a customer-management mini program. The budget was RMB 8,000. After launch, the client kept asking for statistics, notifications, and complex permissions. I got stuck too. I initially read “customer management system” as a familiar template; only in the third conversation did I realize what the client actually wanted was a daily follow-up sheet that sales staff would fill in automatically. Without confirming the delivery boundary early, I was working overtime while explaining why the price had to change.
Don’t hunt for tools yet: find out what result they’re buying
In “A Family Tree of Software Job Titles,” German software practitioner Jens Neumann organizes software roles around three branches: design, development, and operations. For freelance work, the point is not to get confused by titles such as “programmer,” “product manager,” or “full-stack developer,” but to establish whether the client wants a product designed, a system built, or an existing system operated. For example, Shenzhen freelance designer Lin Yue does not sell “hours of coding” when building a booking mini program for a flower shop. She sells three outcomes: customers can choose dates, staff can see bookings, and the owner can export the list. Conversations move faster that way. The client does not need to learn technology; we take on the translation work.
Today’s replica: RMB 0, 40 minutes, low barrier, starting from the brief
Money: RMB 0. A free online spreadsheet works, or even pen and paper. Time: about 40 minutes. Technical barrier: low; no programming required. First step: create a table with the client’s original words on the left, the work they need done in the middle, and “what will be visible after delivery” on the right. Circle the three must-have outcomes and mark everything else “phase two.” I would add three more columns: delivery date, what the client must provide, and how completion is determined. For example, “add statistics” becomes “the owner can see new-customer numbers every week”; “the system must be stable” becomes “10 records can be completed each day during seven consecutive days of testing.” Only then do I quote by phase and agree on the number of revisions, so one vague request does not consume the entire project’s profit. Not everyone needs this method; if you regularly take on the same type of project, a familiar checklist may still work.
Choose an approach based on the clients you have now
If you’re just starting and cannot yet explain what clients really need, I would first run a 40-minute requirement-mapping session with one real client. Collect three outcomes and resist the urge to build the system yet. If you already have one or two clients, I would copy their original statements from existing chat logs into a table, label each item “must deliver” or “do later,” and attach a confirmed date for every item. If you’re scaling, I would create a standard requirements form, change-order form, and acceptance sheet for every role, split quotes into phases, and confirm each addition separately. If you are not ready to organize everything now, that is okay too; start with the next quote. If you want, paste in your client’s original words, and I can help you revise them together.