Monday morning, stuck on a client feature again
Last Monday at 9 p.m., I was in a Hangzhou café modifying a client’s website. The client had just added a request: an “Export Quote” button. The code wasn’t difficult, but as soon as the request arrived, I remembered the previous hassle of switching between windows and copying error messages. That was when I realized my problem wasn’t inability—I was maintaining a tool that felt too heavy. I tried switching from Claude to Pi. It didn’t feel “more powerful” to me; it felt more like a local assistant that could work alongside me.
What Pi Is—and How I Tested It on My Own Project
Simply put, both Claude and Pi can help us write code in plain language, understand project files, and modify features. Pi feels more like a coding assistant living on your own computer, with a different interface and model-selection approach. Moving to Pi didn’t mean Claude was bad; I wanted a more direct workflow with fewer detours. My name is Chen Mo, and I provide freelance software services in Suzhou. In March 2025, I tested Pi with a personal bookkeeping webpage: I asked it to add a “Filter by Month” option, locate the relevant page, and make the change, then checked the result myself. The whole process took about 40 minutes. I also made mistakes: once, I asked it to modify too many files at once, and old features broke. After that, I changed my approach to one small change at a time, which became much more stable.
Reproducing My Setup Today: The Main Cost Is Time, Not Money
I barely spent anything extra on this migration. The main investment was about two hours getting familiar with the interface, model selection, and how Pi confirms projects. The technical barrier is being able to describe what I need and recognize which files it plans to change; I didn’t need to learn complicated commands first. The first step can be tiny: pick a small page with no client data and nothing connected to a live business, create a workspace in Pi or open that page, then enter one clear instruction—for example, “Only add filtering by month; don’t change the existing data format.” Review the modification plan before executing it. And please keep a backup. If you get stuck, going back to your original tool is not embarrassing. Not everyone needs this method, and there’s no rush to try it.
Depending on Your Workload, This Is How I’d Choose
If you’re just starting out: I’d use it on a practice project or static page, with the goal of understanding how it changes files—not replacing my current tool immediately.
If you already have one or two clients: I’d test it on the page with the clearest requirement and smallest impact, while keeping the old workflow so client projects have a fallback.
If you’re scaling up: I’d first track how long each use takes, how many modifications it makes, and why rework happens. Then I could judge whether the whole team should migrate, rather than interrupting delivery just to switch tools.
My conclusion is simple: the tool is only a helper. What made me less anxious was breaking changes into small pieces, keeping backups, and knowing when to stop. Want to try it alongside me on one small, non-urgent project?