The moment I realized my laptop might not be the problem
Last Tuesday night, I was demoing a quoting tool for a client from a shared office in Hangzhou. The computer was brand-new, but Discord took ages to open and jumped straight to 80% memory usage. I assumed my machine wasn't powerful enough. Then I discovered Discord had shown a lighter approach to Windows apps: moving away from resource-heavy frameworks like Electron to reduce waiting and memory consumption.
That matters for us building small tools. Clients don't care which technologies we used. They care whether they can click and start working.
What Discord demonstrated this time
Electron is basically a way to build desktop software with web technologies. It's convenient, but the resulting app is often heavy. Discord's approach was to make its Windows 11 app work more natively, reducing resource use while preserving sign-in, messaging, and account switching.
My colleague Lin Yue had previously demoed a collaboration tool from a coffee shop in Chaoyang, Beijing, using Windows 11. She had two accounts signed in at once and noticed that the new interface launched faster and used noticeably less memory. Her first reaction was: “My clients finally don't have to wait for me.”
What it costs to replicate this today
If I wanted to verify this myself, the tools are essentially free and the direct cost is 0 yuan. It would take about 2 to 4 hours, with a technical barrier of writing a little code—or asking a developer to help.
The first step isn't downloading some complicated toolkit. In Windows 11, I'd open “Settings—Apps—Default apps” and check how much memory my commonly used tools actually consume before deciding whether a change was worth it.
My replication approach is deliberately conservative: test with one small internal tool, not the version clients are already using. I made this mistake before—I started by rewriting the entire app. Clients still faced the same wait times, while I spent two weeks exhausting myself for nothing.
Advice by stage: don't rebuild a product just to chase new tech
When I was just starting out, I would keep the existing tools stable and only record memory usage and startup time when clients complained about lag. It would have been fine not to test this yet.
With one or two clients, I might build a lightweight version of one non-core feature and observe it for a week. When scaling up, I'd have a developer systematically evaluate desktop options while keeping a rollback path.
Not everyone needs this. If I don't have a desktop app yet, making the core service work smoothly comes first.