I replaced my Telegram bot and Google Sheet with my own MCP enabled open-source finance app
DEV Community Grade 8 2d ago

I replaced my Telegram bot and Google Sheet with my own MCP enabled open-source finance app

For a long time, my personal accounting system was a small automation stack: a Telegram bot wizard collected transaction details, wrote rows into Google Sheets, and custom spreadsheet charts handled the statistics. It was a good setup because Telegram made capture fast and Sheets made analysis flexible. But every improvement also meant keeping bot prompts, spreadsheet columns, formulas, and charts aligned. I built xpenser to keep the useful parts of that workflow while moving the repetitive structure into a small web app: transactions, vendors, nested categories, currencies, dashboard periods, reports, Telegram workflows, and email summaries. The project also became a reference app for the stack behind it. The same schema-first TypeScript contracts drive validation, OpenAPI output, typed clients, React forms, auth-aware endpoints, telemetry, Telegram integration, and MCP access. This post walks through what shipped, what I deliberately did not build yet, and why chat/agent-friendly finance data needs careful permission wording. Outline: The Telegram bot + Google Sheets origin story and the broader expense-tracking problem. Product scope: manual tracking and structured reporting first, not a bank-sync suite. Data model surfaces: transactions, vendors, categories, currencies, periods. App workflows: dashboard, reports, preferences, Telegram capture, email summaries. Developer surfaces: API keys, typed client, OpenAPI, Telegram. MCP access: why it is useful, why it should be treated as full account access. Self-hosting and open-source tradeoffs. Current limitations and what feedback would be useful. The app is live at https://xpenser.cleverbrush.com and the source is at https://github.com/cleverbrush/xpenser . I would appreciate feedback on what you use today to track and analyze expenses, whether xpenser could replace or complement it, the README/self-hosting path, and whether MCP access feels useful enough to justify the risk surface.

For a long time, my personal accounting system was a small automation stack: a Telegram bot wizard collected transaction details, wrote rows into Google Sheets, and custom spreadsheet charts handled the statistics. It was a good setup because Telegram made capture fast and Sheets made analysis flexible. But every improvement also meant keeping bot prompts, spreadsheet columns, formulas, and charts aligned. I built xpenser to keep the useful parts of that workflow while moving the repetitive structure into a small web app: transactions, vendors, nested categories, currencies, dashboard periods, reports, Telegram workflows, and email summaries. The project also became a reference app for the stack behind it. The same schema-first TypeScript contracts drive validation, OpenAPI output, typed clients, React forms, auth-aware endpoints, telemetry, Telegram integration, and MCP access. This post walks through what shipped, what I deliberately did not build yet, and why chat/agent-friendly finance data needs careful permission wording. Outline: - The Telegram bot + Google Sheets origin story and the broader expense-tracking problem. - Product scope: manual tracking and structured reporting first, not a bank-sync suite. - Data model surfaces: transactions, vendors, categories, currencies, periods. - App workflows: dashboard, reports, preferences, Telegram capture, email summaries. - Developer surfaces: API keys, typed client, OpenAPI, Telegram. - MCP access: why it is useful, why it should be treated as full account access. - Self-hosting and open-source tradeoffs. - Current limitations and what feedback would be useful. The app is live at https://xpenser.cleverbrush.com and the source is at https://github.com/cleverbrush/xpenser. I would appreciate feedback on what you use today to track and analyze expenses, whether xpenser could replace or complement it, the README/self-hosting path, and whether MCP access feels useful enough to justify the risk surface. Top comments (0)

Comments

No comments yet. Start the discussion.