Before Monday’s stand-up, “How should we build the client?” stopped me in my tracks

At 9 a.m. last Monday, we were discussing a customer request at our shared-office desk in Hangzhou: people wanted a desktop tool that felt easier to use. My first thoughts were to switch frameworks, design a prettier interface, maybe even buy a development package. After writing a few prototype lines, I realized we hadn’t even ranked the three things users did most each day. I got this wrong before: two pages on technical selection, one sentence on the user problem.

If you’re an indie developer, getting stuck here is common. The more tools you review, the harder the decision becomes. My approach is to ask first: will this only run on phones, or does it need to handle local files, work offline, or send system notifications? Those answers drive the solution; framework popularity does not.

Start with the need, then decide whether to build or borrow

The core point in the original is simple: technology selection comes second. Solve the user’s most real need first. Client development generally has two paths. One gives you finer control and fits local files, offline capabilities, complex interactions, or special hardware. The other uses existing frameworks and AI to speed up ordinary pages, forms, and settings panels.

I know Lin Ran, a freelancer building an accounting tool. In November 2024, he received a small-business commission in Chengdu. The client explicitly required Excel export and accounting without an internet connection. Rather than forcing every ordinary screen into one build, he used existing tools for accounting and reports, then moved file import into phase two. Looking back six months later, that trade-off saved substantial rework and kept the launch from being delayed to look “more complete.”

For me, AI is more like an assistant: it can quickly sketch interfaces, organize repetitive code, and explain errors, but it cannot decide whether a feature is actually needed. Existing developers also use it to generate prototypes and maintain cross-platform code. Still, an AI proposal may look complete while permissions, edge cases, and the real experience after installation remain untested.

What would it cost to replicate this decision today?

Money: personal or entry-level development tools cost roughly RMB 0–200; templates or courses may add another RMB 0–300. Time: spend half a day listing scenarios and trade-offs, then 1–3 days building a clickable prototype. Technical barrier: I need to explain the workflow clearly and be willing to handle cases where “the program works on my computer but fails on someone else’s.” I don’t need to become a professional client engineer first.

The first step isn’t opening the code editor. Take a sheet of paper and write three columns: daily, occasional, and possible later. Beside each item, note whether it must run locally and whether it needs system permissions. Then choose only the most frequent task and build the first version. If even that version gets no user feedback, postponing a complex client is completely reasonable.

Here’s how I’d arrange it by the stage I’m at

If I’m just starting, I’d build a web app or the simplest desktop version before setting up a complex framework. Even with fewer features, I’d get real users clicking through it quickly. If I already have 1–2 clients, I’d rank their feedback by frequency and add local capabilities only for recurring problems. I might use AI to improve the interface, but I’d still complete every workflow myself before launch. If I’m scaling, I’d document compatibility issues across operating systems before considering a cross-platform approach and automated testing, so every release doesn’t depend on manual firefighting.

This tool isn’t for everyone. Not trying native or client development now is fine too. Learning when a real requirement pushes me toward it may cost less. I can start by writing down one user scenario and see whether it truly deserves to become a client.