
<p>Tabby sends you things on a schedule. A nudge in the evening if you haven't logged anything. A spending summary on Sunday night. A fresh set of budgets on the 1st of the month. A heads-up before a free trial turns into a charge.</p>

<p>The obvious way to build that is a cron job. Every hour, wake up, loop over every user, and ask each one: is it your time yet? That is exactly how Tabby worked for a long time, and it worked fine. Until I looked at what it was actually costing, and what it was quietly preventing.</p>

<h2>The cost nobody notices</h2>
<p>With hourly polling, the work you do scales with how many users you have, not with how much there is to do. Every hour, Tabby walked the entire user table to discover that almost nobody needed anything. At any given hour, the overwhelming majority of those checks are answered "no."</p>

<p>That is wasteful, but waste alone is a weak reason to rewrite something that works. The real problem was subtler.</p>

<div class="callout callout-insight">
  <strong>The thing I missed for months:</strong> if your scheduler only wakes up once an hour, then "remind me at 9:00 PM" can only ever mean "remind me sometime in the 9 PM hour." The polling interval had quietly become a product limit. I could not offer a feature I wanted to offer, because of a loop.
</div>

<p>Tabby lets you pick your reminder time, and users are spread across dozens of timezones. Hourly granularity is the coarsest possible answer to a question people asked precisely.</p>

<h2>Turning schedules into rows</h2>
<p>The fix was to stop asking "who needs something right now?" and start writing down the answer in advance.</p>

<p>Now, when you finish onboarding or change a setting, Tabby computes when your next reminder should fire, converts that moment from your local timezone into UTC, and stores it as a row in a <code>scheduled_events</code> table. One row per upcoming thing: a type, a chat, a timestamp, a status, a retry count.</p>

<p>The loop that runs every minute no longer knows anything about users. It asks one question: <em>are there any pending rows whose time has passed?</em> That query is indexed on type, status and time, and it returns nothing at all for most of the day.</p>

<div class="callout callout-tip">
  <strong>The shape of the win:</strong> the old job's cost scaled with the number of users. The new job's cost scales with the number of things actually due. Those are wildly different numbers, and only one of them grows when Tabby grows.
</div>

<p>The precision came along for free. Checking every minute instead of every hour made "9:00 PM" mean 9:00 PM, in your timezone, without a single extra line of scheduling logic.</p>

<h2>Failure gets easier, not harder</h2>
<p>The part I didn't expect: moving the schedule into the database made failure handling simpler.</p>

<p>When your scheduler lives in memory, a crash or a deploy loses whatever it was holding. When the schedule is a table, a restart loses nothing. The rows are still there, still pending, still overdue, and the next tick picks them up.</p>

<p>It also gives failure somewhere to be recorded. If Telegram is briefly unreachable, the row goes back to pending with its retry count bumped and its time pushed out a few minutes. Tabby tries three times, five minutes apart, then stops and marks the row failed rather than hammering a dead endpoint forever.</p>

<p>Those numbers aren't arbitrary. Most transient network problems clear inside five minutes. Fifteen minutes is about the longest you can delay an evening reminder before it stops being an evening reminder. Past that, retrying isn't resilience, it's noise.</p>

<p>And some failures aren't transient at all. If you've blocked the bot, no number of retries will help, so Tabby reads that specific error, marks the account inactive, and stops writing to a chat that doesn't want it.</p>

<h2>The trade-off</h2>
<p>Polling had one real virtue: it was stateless. It couldn't be wrong, because it recomputed everything from scratch every hour. There was no schedule to keep correct.</p>

<p>Pre-computed events give that up. Now there is state, and state can drift. Change your reminder time and the row that already exists is stale. Move timezones and every future row is wrong. Every setting that feeds into a schedule has to know it must regenerate the rows behind it, and forgetting that in one place is a bug polling could never have had.</p>

<div class="callout callout-insight">
  <strong>The honest summary:</strong> I traded a system that was wasteful but incapable of being wrong for one that is efficient and precise but has to be kept honest. For a feature people configure to the minute, that's the right trade. It would have been the wrong trade for something nobody tunes.
</div>

<h2>What I'd tell myself earlier</h2>
<p>I put off this rewrite because I filed it as a performance task, and performance wasn't hurting. It sat in the backlog behind things that felt more like features.</p>

<p>It was a feature. Every time I sketched something scheduled and thought "that'll need to be hourly, then," that was the old loop making a product decision on my behalf. The rewrite didn't just make the job cheaper. It removed a ceiling I'd stopped noticing was there.</p>

<p>Worth asking, if you've got a cron job of your own: is it doing what you want, or have you quietly designed around what it allows?</p>
    

The scheduler wasn't a performance problem. It was a product constraint.

How we killed the hourly cron


<p>When I started building Tabby, the first question everyone asked was: "Why not just build an app?" It's a fair question. The App Store is full of expense trackers with beautiful dashboards, fancy charts, and every feature you can imagine.</p>

<p>But here's the thing: most people don't use them.</p>

<div class="callout callout-insight">
  <strong>The real problem:</strong> Expense tracking apps fail not because they lack features, but because they add friction. You have to open the app, find the right screen, fill out a form, pick a category from a dropdown, choose a date. By the time you're done, you've spent 30 seconds on what should take 3.
</div>

<h2>Chat is the lowest-friction interface</h2>
<p>Think about what you already do dozens of times a day: send messages. It's muscle memory. You don't think about "opening an app." You just type.</p>

<p>That's the insight behind Tabby. Instead of asking people to learn a new app, we meet them where they already are: in their chat. Type <code>12 lunch</code> and you're done. No forms, no dropdowns, no navigation.</p>

<h2>Why Telegram specifically?</h2>
<p>A few reasons:</p>

<ul>
  <li><strong>Bots are first-class citizens.</strong> Telegram's bot platform is powerful: inline keyboards, mini apps, webhooks, file sharing. We can build a full experience inside the chat.</li>
  <li><strong>Groups work naturally.</strong> Adding a bot to a group chat for shared expense tracking is seamless. Try doing that with a standalone app. You'd need everyone to download it, create accounts, add friends.</li>
  <li><strong>Mini Apps bridge the gap.</strong> When you do want a dashboard with charts, Telegram's Mini App platform lets us provide that, without asking you to download anything.</li>
  <li><strong>Global reach.</strong> Telegram has 900M+ users across 200+ countries. Many of our users are travelers and expats who already live in Telegram.</li>
</ul>

<h2>The trade-off</h2>
<p>Building on Telegram means we don't control the entire experience. We can't send push notifications the way a native app can. We can't do background processing on the user's device. We're constrained by what the Telegram bot API allows.</p>

<div class="callout callout-tip">
  <strong>But here's what we've learned:</strong> The constraint is actually a feature. It forces us to keep things simple. Every interaction has to work in a chat message. That discipline has made Tabby better, not worse.
</div>

<h2>The result</h2>
<p>Our most active users log expenses multiple times a day, because it takes 3 seconds. They'd never do that with a traditional app. The best expense tracker isn't the one with the most features. It's the one you actually use.</p>

<p>That's why we built Tabby on Telegram. Not because it's the most powerful platform, but because it's the one that gets out of the way.</p>
    

The decision to build a chat-first expense tracker instead of another app.

Why we built Tabby on Telegram


<p>Tabby has a free tier. Not a "free trial that expires in 7 days" free, but genuinely free, forever. You can track unlimited expenses, get AI categorization, use group splits, and receive monthly reports without ever paying a cent.</p>

<p>Some people think this is a bad business decision. Here's why we disagree.</p>

<div class="callout callout-insight">
  <strong>The principle:</strong> The core job of an expense tracker is to track expenses. That should never be behind a paywall.
</div>

<h2>What's free and why</h2>
<p>Everything you need to track your spending effectively:</p>

<ul>
  <li><strong>Unlimited expense tracking:</strong> The fundamental job. No caps, no limits.</li>
  <li><strong>AI categorization:</strong> Because manually categorizing every coffee is why people stop tracking.</li>
  <li><strong>Group splits:</strong> Because splitting expenses with friends shouldn't cost money.</li>
  <li><strong>Monthly reports:</strong> Because knowing where your money went is the whole point.</li>
  <li><strong>Up to 3 categories, 1 budget, 2 accounts:</strong> Enough to get real value without hitting a wall on day one.</li>
</ul>

<h2>What's Pro and why</h2>
<p>Pro features fall into two buckets: <em>power user tools</em> and <em>computationally expensive features</em>.</p>

<p><strong>Power user tools:</strong></p>
<ul>
  <li>Unlimited categories, budgets, and accounts</li>
  <li>Recurring transactions</li>
  <li>Subscription tracker</li>
  <li>Smart budget suggestions</li>
  <li>Full historical data</li>
  <li>Data export</li>
</ul>

<p><strong>Expensive to run:</strong></p>
<ul>
  <li>Voice message transcription + parsing</li>
  <li>Receipt OCR scanning</li>
</ul>

<div class="callout callout-tip">
  <strong>The line we draw:</strong> If removing a feature would make Tabby useless for a casual user, it stays free. If it's a power-user convenience or costs us real money per use, it's Pro.
</div>

<h2>Why this matters</h2>
<p>Tabby is a one-person project. I built it because I was frustrated with existing expense trackers. They were either too complex, too expensive, or too annoying to use consistently.</p>

<p>The free tier isn't a marketing trick to get you hooked. It's a genuine product that works for most people. If you track expenses casually (a few entries a day, one or two categories), free Tabby does everything you need.</p>

<p>Pro exists for people who want to go deeper: automate their recurring bills, track 10 budget categories, export data for tax season, or just speak their expenses instead of typing them.</p>

<p>That feels like the right trade-off to me.</p>
    

Our philosophy on what's free, what's Pro, and why it matters.

Why we keep the core free


<p>When you add Tabby to a group chat, it listens to every message by default. That's how it picks up expenses automatically. Someone types <code>45 dinner</code> and Tabby logs it, no tagging needed.</p>

<p>Sounds great, right? It is, until your group starts having a normal conversation.</p>

<div class="callout callout-insight">
  <strong>The problem:</strong> Nobody wants to create a separate Telegram group just to log expenses. You want to chat with your friends normally and track expenses in the same place. But when the bot is listening to everything, casual messages like "I owe you one" or "that cost me my sanity" would get picked up as expenses.
</div>

<h2>The real need</h2>
<p>People don't want to choose between chatting and tracking. They want both in the same group. Sometimes you're splitting a dinner bill. Five minutes later you're planning tomorrow's hike. The bot shouldn't be logging "let's grab 2 taxis" as an expense.</p>

<p>So we built a simple toggle: <code>/togglelistenmode</code>.</p>

<h2>How it works</h2>
<p>By default, Tabby listens to all messages and auto-detects expenses. But when you turn Listen Mode off, Tabby goes quiet. It only logs expenses when you explicitly tag <code>@tabbyfinancebot</code>. You can chat freely without worrying about accidental entries.</p>

<div class="callout callout-tip">
  <strong>Listen Mode ON (default):</strong> Tabby reads every message and auto-logs detected expenses. Great for trip groups where most messages are expenses.<br/>
  <strong>Listen Mode OFF:</strong> Tabby only responds when tagged. Perfect for casual groups where you chat normally and log expenses on your own terms.
</div>

<h2>One group, two modes</h2>
<p>The beauty is you can switch anytime. Heading on a trip? Turn Listen Mode on and let Tabby catch everything. Back to normal life? Turn it off and just tag the bot when you need to.</p>

<p>No extra groups. No friction. Just one chat where you talk, split, and track, all in the same place.</p>
    

How we made group expense tracking feel like a normal conversation.

Why we built Listen Mode


<p>Most budgeting tools work like this: you set a budget, spend throughout the month, and then at the end you check a dashboard and discover you overspent. It's like weighing yourself after you've already eaten the whole cake.</p>

<div class="callout callout-insight">
  <strong>The problem:</strong> Retroactive budget tracking doesn't change behavior. By the time you see you've overspent, it's too late. The money is gone. You feel bad, set the same budget next month, and repeat.
</div>

<h2>Alerts at the right moments</h2>
<p>Tabby takes a different approach. Instead of waiting for you to check a dashboard, we text you at three critical thresholds:</p>

<ul>
  <li><strong>50%, the halfway check.</strong> "You've used half your Food budget. $250 left for the rest of the month." This is informational. No panic, just awareness.</li>
  <li><strong>75%, the warning.</strong> "You've hit 75% of your Shopping budget with 10 days left." Now you can consciously decide: slow down or accept going over.</li>
  <li><strong>100%, the line.</strong> "You've exceeded your Fun budget." No judgment, just facts. Some months you'll go over, and that's fine. But at least you chose to.</li>
</ul>

<h2>Why these specific numbers?</h2>
<p>We tested different thresholds: 25%, 40%, 60%, 80%, 90%. Here's what we found:</p>

<ul>
  <li>Alerts below 50% felt premature. "You've spent 25% of your budget" doesn't mean anything when you're barely into the month.</li>
  <li>Alerts at 90% came too late. By then, you've basically already decided to overspend.</li>
  <li>50-75-100 hits the sweet spot: early enough to adjust, spaced enough not to be annoying, and clear enough to act on.</li>
</ul>

<div class="callout callout-tip">
  <strong>The key insight:</strong> The goal isn't to prevent overspending. It's to make overspending a conscious choice instead of an accidental one.
</div>

<h2>The halfway check</h2>
<p>One feature we're particularly proud of is the halfway check. When you log an expense that pushes a category past 50%, Tabby mentions it right there in the confirmation message, not as a separate alert, but woven into the flow.</p>

<p>"Logged $150 omakase dinner → Food. You're at 67% of your Food budget ($333 of $500). $166 left for the rest of the month."</p>

<p>You see it, internalize it, and move on. No extra notification, no dashboard visit needed. The awareness happens at the moment of spending, exactly when it matters most.</p>
    

The behavioral design behind Tabby's budget alerts at 50%, 75%, and 100%.

Why budgets should text you back


<p>Tabby was built around one idea: logging expenses should be as easy as sending a text message. Type <code>12 lunch</code> and you're done. But there's one scenario where even typing feels like too much work: when you're staring at a receipt with 8 line items.</p>

<div class="callout callout-insight">
  <strong>The problem:</strong> After a grocery run or a group dinner, nobody wants to type out each item individually. They'd either log the total (losing category detail) or skip it entirely.
</div>

<h2>Just snap it</h2>
<p>Receipt scanning lets you take a photo and have Tabby extract every line item automatically. The OCR reads item names and prices, matches them to categories, and presents everything for your review before logging.</p>

<h2>Why we made it a Pro feature</h2>
<p>Receipt scanning requires real-time OCR processing and AI categorization for each item, and it's computationally expensive. We wanted to keep the core Tabby experience free (text-based logging, AI categorization, group splits), and offer receipt scanning as part of the Pro tier alongside voice logging and data export.</p>

<div class="callout callout-tip">
  <strong>Tip:</strong> Receipt scanning works best with printed receipts where text is clear. Handwritten receipts or very faded thermal paper may not parse perfectly, but you can always edit before confirming.
</div>

<h2>What's next</h2>
<p>We're working on making the scanner smarter: detecting restaurant names, splitting tips automatically, and even recognizing store loyalty card discounts. The goal is the same as always: log once, track everything.</p>
    

The case for letting your camera do the logging.

Why we added receipt scanning


<p>Tabby has two features that sound like they do the same thing: recurring transactions and the subscription tracker. People often ask why we built both. The short answer: one is about logging, the other is about awareness.</p>

<h2>What recurring transactions do</h2>
<p>Recurring transactions auto-log an expense or income on a schedule. You set it up once ("$1,800 rent, monthly, on the 1st") and Tabby logs it automatically every month. No manual entry needed.</p>

<p>It's great for things that are predictable and consistent:</p>

<ul>
  <li>Rent or mortgage payments</li>
  <li>Salary deposits</li>
  <li>Utility bills</li>
  <li>Gym memberships</li>
</ul>

<p>The goal is simple: save you from typing the same expense every month. Tabby handles it, your budget stays accurate, and you don't have to think about it.</p>

<h2>What the subscription tracker does</h2>
<p>The subscription tracker is different. It's not about logging. It's about knowing what you're paying for.</p>

<div class="callout callout-insight">
  <strong>The problem it solves:</strong> Most people have no idea how many subscriptions they're paying for. A streaming service here, a cloud storage plan there, a free trial you forgot to cancel. They add up quietly, and by the time you notice, you've been paying for months.
</div>

<p>The subscription tracker gives you a single view of every subscription you have: the name, the price, the billing cycle, and when the next renewal is. More importantly, it reminds you <em>before</em> a renewal happens, so you can decide whether to keep it or cancel.</p>

<h2>Why both exist</h2>
<p>Here's the key difference:</p>

<div class="callout callout-tip">
  <strong>Recurring transactions</strong> answer: "Can Tabby log this for me automatically?"<br/>
  <strong>Subscription tracker</strong> answers: "What am I actually paying for, and should I still be?"
</div>

<p>You might have a Netflix subscription in the tracker (so you see it in your overview and get renewal reminders) <em>and</em> link it to a recurring transaction (so the charge gets auto-logged to your expenses each month). Or you might only use one or the other.</p>

<h2>The real story</h2>
<p>I built the subscription tracker after realizing I had been paying for a cloud storage plan for 8 months without using it. The charge was small enough that I never noticed it in my bank statements. If I'd had a single place showing all my active subscriptions with renewal dates, I would have caught it immediately.</p>

<p>That's the difference. Recurring transactions keep your expense log accurate. The subscription tracker keeps you aware of where your money is quietly going.</p>
    

They sound similar, but they solve very different problems.

Recurring transactions vs. subscription tracking


<p>Here's a scenario we kept seeing: a group of friends goes on a trip. They add Tabby to track expenses. Trip ends, everything's settled. Then a few months later, the same group plans another trip, and they create a <em>whole new Telegram group</em> just for expense tracking.</p>

<div class="callout callout-insight">
  <strong>The problem:</strong> People were creating new groups for every trip, event, or project. Their Telegram was filling up with "Bali Trip Expenses," "Japan 2026," "Housemate Bills Q2." Each with the same members.
</div>

<h2>Contexts, not groups</h2>
<p>The solution was simple: let one group hold multiple expense contexts. Think of a context like a folder: "Bali Trip," "Monthly Groceries," "Office Lunch Fund," all living inside the same group chat.</p>

<p>Switch to "Bali Trip" and every expense gets logged there. Switch to "Monthly Groceries" and the context changes. Stats, budgets, and settlements are all scoped to the active context.</p>

<h2>Why it matters</h2>
<p>It's a small feature, but it solves a real organizational headache:</p>

<ul>
  <li>No more creating new groups for every trip</li>
  <li>Historical data from past trips stays accessible</li>
  <li>Same members, same chat, different expense buckets</li>
  <li>Close a context when a trip ends, then start a new one when the next trip begins</li>
</ul>

<div class="callout callout-tip">
  <strong>How we use it:</strong> Our own team has one group with contexts for "Team Lunches," "Office Supplies," and "Company Retreat 2026." One group, zero clutter.
</div>

<p>Sometimes the best features aren't flashy. They just remove a small annoyance you didn't realize you had.</p>
    

The thinking behind Group Contexts

Contexts, not groups

Why it matters