What AI Chatbot Development Actually Looks Like: A Real Build, Not a Demo When TER.A Coffee came to us to replace their paper stamp cards, the brief was narrow: track a customer's visits, calculate when they'd earned a free coffee, and let a barista confirm a visit by scanning a QR code at checkout.
This is a walkthrough of that build, still running in production — what "AI chatbot development" concretely meant for this project, including the parts that had nothing to do with AI at all.
The brief The shop had no existing loyalty infrastructure and no appetite for a recurring SaaS subscription that didn't clearly pay for itself at their volume. That constraint shaped the approach. A generic loyalty-app platform makes sense for a business buying a category of software off the shelf. It made less sense here: the actual requirement was a workflow built around how one barista works a register during a rush, not a template retrofitted to their process.
What got built The bot runs on python-telegram-bot and FastAPI, structured around a "7+1" rewards model — seven paid visits, the eighth free — the same ratio TER.A Coffee had used on their physical stamp cards, so regular customers didn't have to relearn the program when it moved from paper to a phone screen.
Two implementation details ended up mattering more than the loyalty math. Every scan pairs a specific barista account with a specific customer account, and the system verifies that pairing hasn't already been credited within the rate-limit window before logging a new visit. Without that check, an accidental double-scan — or a deliberate retry — credits two visits instead of one.
The second detail is a signed secret token on every webhook request. The bot is authorizing something with real value on every successful scan, not just holding a conversation, so an unauthenticated webhook would be able to credit rewards that were never earned. On a small project like this, it's tempting to treat that as optional; it isn't, once money or inventory is involved.
Why we skipped the language model The core interaction — scan code, log visit, calculate reward, confirm — is a fixed, four-step loop with no ambiguous input to interpret and no open-ended question a customer asks mid-transaction. Wiring a language model into a loop like that adds nondeterminism to a path that works better with none.
Deciding this early, during scoping rather than mid-build, is what kept the project simple: a fixed workflow gets fixed, testable automation; anything with genuinely open-ended input gets a model. Conflating the two is common in "AI chatbot" projects generally — a rule-based flow gets a language model bolted on because the client asked for "AI," not because the interaction needed one.
What's running now The bot has been live since September 2025 — ten months at the time of writing — with 325+ registered users on a single Telegram account. It runs on a basic Hetzner instance; loyalty traffic for one physical location doesn't come close to saturating even entry-level infrastructure. No incidents tied to the rate-limiting or webhook layer since launch.
What this means if you're evaluating a vendor The useful diagnostic question isn't "can you build me a chatbot" — most vendors will say yes regardless of what your workflow actually needs. It's whether they can tell you, before any code gets written, which parts of your process need a language model and which need something simpler running underneath a chat interface.
Forgemind Labs builds AI assistants and automation for small businesses — including MoveAI, a computer-vision estimate tool for movers, and TER.A Coffee, the bot described here. Read the full TER.A Coffee case study → · More case studies →