Day 35: The First Real Deploy
Until yesterday, I had only ever run Pinchy locally. docker compose up, localhost, done. Turns out, "it works on my machine" is not a deployment strategy.
The Call That Changed Everything
Had a call with someone who's seriously interested in Pinchy — not just as a user, but as someone who wants to bring it to other companies. He'd already tried deploying it on a Hetzner VPS. It didn't go well.
He shared his logs. Login failures. OpenClaw timing issues. Port conflicts. The kind of problems you never see locally because Docker handles everything and your machine has 32 GB of RAM.
This was exactly the feedback I needed. Not "nice product" but "here's where it breaks." So I spent the day fixing every single issue he hit.
What I Built
VPS Deployment Guides. Step-by-step documentation for deploying Pinchy on Hetzner, with cloud-init automation. One script that provisions the server, installs Docker, pulls Pinchy, sets up SSL, and starts everything. Copy, paste, wait three minutes, done.
A Loading Page. When Pinchy starts for the first time, the Docker build takes a few minutes. Previously you'd just stare at a blank page. Now there's a proper loading screen with progress steps and an elapsed timer. Small thing, but it's the difference between "is this broken?" and "okay, it's working."
Login and Timing Fixes. The setup wizard could fail because OpenClaw wasn't fully ready when Pinchy tried to connect. Added retry logic and better handoff between the loading page and the actual app. Also fixed a UFW/iptables conflict that blocked the port on some VPS configurations.
All of this goes into v0.3.0, which ships in the next few days.
The Telegram Situation
Also made progress on Telegram integration. Multi-bot support, better pairing UX, config stability improvements. But there are edge cases — unlinking and re-pairing, config conflicts between file-based and API-based approaches — that I'm not happy with yet.
I'm debating whether to hold the release for Telegram or ship v0.3.0 with the deployment improvements and add Telegram in v0.3.1. My instinct says ship what's ready. Telegram shouldn't block the deployment fixes that people need now.
The Pattern
This is becoming a pattern: someone tries Pinchy in the real world, hits friction, shares their experience, and I fix it the same day. It's the fastest feedback loop I've ever had. No issue tracker delays, no sprint planning, no "we'll get to it next quarter." Just: here's the problem, here's the fix, here's the new version.
The downside: it's reactive. I'm fixing what's broken instead of building what's next. But right now, that's exactly the right thing to do. The first five users need a smooth experience more than the next fifty need a feature they haven't asked for yet.
Day 35
VPS deployment guides. A loading page. Login fixes. Telegram progress. And the realization that the most valuable code I wrote today wasn't a feature — it was a three-minute cloud-init script that turns "deployment is scary" into "deployment is boring." Boring is good. Boring means it works.