Day 39: The Mock Server Trick
Weekend at the in-laws in Carinthia. No coding. But I've been thinking about the Telegram integration all week, and I want to write down what made it work — because it's a pattern I'll use again.
The Problem with Telegram Development
Telegram bots need a real Telegram server to work. You create a bot, you get a token, you poll for updates or set up webhooks. Every test needs a network call. Every edge case needs a real chat. It's slow, it's flaky, and you can't automate it.
When I started building Telegram support for Pinchy, I ran into the classic integration testing problem: how do you test pairing, unlinking, re-pairing, multi-bot setups, permission checks — all the edge cases — without clicking through Telegram on your phone every time?
The Fake Telegram
I built a mock Telegram server. A small HTTP server that implements just enough of the Telegram Bot API to make Pinchy think it's talking to the real thing. getMe, getUpdates, sendMessage, setMyCommands — the handful of endpoints that matter.
The mock server runs in Docker alongside Pinchy during tests. Pinchy connects to it instead of api.telegram.org. And now I can simulate everything programmatically: a user sends a message, the mock queues it as an update, Pinchy picks it up, processes it, sends a response back to the mock. Full loop. No phone. No network. No flakiness.
The best part: the same mock runs in CI. Every pull request tests the complete Telegram flow — pairing a bot, sending a message, checking permissions, unlinking — in seconds. Claude Code can run the tests, see what fails, fix it, run again. The feedback loop that used to take minutes (deploy, open Telegram, type a message, check logs) now takes seconds.
Why This Matters Beyond Telegram
The mock server pattern is how I'll build every future integration. Outlook, Slack, Teams — each will get a mock that implements just enough of the API to test the full flow locally and in CI. No API keys needed, no rate limits, no "the test broke because Telegram was slow."
It also means Claude Code can develop integrations much faster. Give it a failing E2E test and a mock server, and the feedback loop is tight enough for real progress. That's the difference between "it should work" and "all 9 tests pass."
The Bigger Picture
This week has been a transition. After the v0.3.0 release, I had back-to-back calls — companies in Vienna wanting to deploy Pinchy, an Irish fleet management company, a German corporate startup. Meetup talks turned into meetings turned into development partnerships.
I now have a clear picture of what these companies need. Email integration. File access via OneDrive. ERP connections. The roadmap is no longer theoretical — it's driven by real people with real workflows waiting for real features.
So I'm shifting gears. Less marketing, more building. The calendar stays open for calls, but my energy goes into development. The companies I'm working with need features, not LinkedIn posts.
Day 39
No code today. Just thinking, planning, and the quiet confidence that comes from knowing exactly what to build next.