PocketCFO

Inspiration Most people check their bank balance and feel okay. Then rent hits. Then payroll. Then a tax bill they didn't see coming. The number that felt safe is suddenly terrifying, and there was never a moment of warning.

We've all been there. One of our team members ran a small consultancy and nearly missed payroll because VAT was due the same week as a supplier invoice. The bank account said there was money. There wasn't, not really.

That's the lie. Your bank balance is a nominal figure. It doesn't know about the Revenue Commissioners, your AWS subscription, your staff payroll, or the office lease renewing next month. It just shows you a number and lets you figure out the rest.

We wanted to build the thing that should have existed: a dashboard that shows you your true available cash, the number after every obligation is accounted for, and an AI you can actually ask "can I afford this?"

What it does PocketCFO (built on the TrueBalance engine) is a financial clarity dashboard for SMEs and individuals in Ireland. It answers one question in real time:

After tax, subscriptions, recurring bills, and the next 30 days of committed spend — how much can I actually use?

The core metric is True Available Cash, defined as:

$$\text{True Available} = \text{Balance} - \text{Tax Reserve} - \sum_{i} \text{Recurring}_i - \text{Uncommitted Buffer}$$

Where the Tax Reserve for an SME is estimated as:

$$\text{Tax Reserve} = (\text{Revenue} \times \tau_{\text{VAT}}) + (\text{Profit} \times \tau_{\text{Corp}}) + (\text{Payroll} \times \tau_{\text{PRSI}})$$

With Irish rates:

VAT = 23%, Corp = 12.5%, PRSI = 4%.

For individuals:

Income = 20%, USC = 4%, PRSI = 4%.

Key features:

True Available Cash - the real number, not the bank number Tax Vault - a live reserve estimate so a tax bill is never a surprise 30-day Cash Runway Forecast - projects your balance forward using detected recurring patterns Recurring Payment Detection - automatically identifies subscriptions and fixed costs using a merchant-grouping + frequency algorithm with ±5% variance tolerance AI Affordability Advisor (PocketCFO) - type "Can I afford a €2,500/month hire?" and get a structured verdict with confidence score, reasoning, and impact analysis, powered by Groq CFO Insights - AI-generated financial health summary tailored to your user type (CFO-tone for SMEs, personal-finance-tone for individuals) Bank Connection via Plaid - pull in real transactions for real figures Pro tier via Stripe - AI savings recommendations powered by Groq's LLaMA 3.1 How we built it Frontend: React 18 + TypeScript + Vite, with Tailwind CSS and shadcn/ui for components. React Query handles all data fetching, caching, and mutations. Recharts for the forecast chart and expense breakdown. React Router for navigation.

Backend: Express 5 on Node.js, connecting to:

Supabase (Postgres + Auth) - user accounts, settings, subscriptions, and transaction storage Groq API - llama-3.1-8b-instant for CFO insights and Pro savings, qwen/qwen3-32b for the affordability advisor (it handles reasoning about ambiguous purchase questions better) Plaid (sandbox mode) - bank account connection and transaction sync Stripe - subscription checkout and webhook-based Pro status management The finance engine runs server-side and implements:

Recurring detection - groups transactions by merchant, checks for ~30-day intervals and ≤5% amount variance Tax estimation — applies the correct rate schedule based on user type Forecast generation — projects balance forward 30 days using detected recurring expenses and income patterns Cash runway - computes $\lfloor \text{True Available} / \text{Monthly Burn} \times 30 \rfloor$ days A smart data fallback chain ensures the app always shows something meaningful:

$$\text{Data Source} = \begin{cases} \text{Plaid (real)} & \text{if bank connected} \ \text{User DB} & \text{if manual data entered} \ \text{Sandbox JSON} & \text{otherwise (demo mode)} \end{cases}$$

Challenges we ran into

The "lying balance" problem is harder to solve than it sounds. Detecting recurring payments from raw transactions requires tolerating merchant name variation ("AWS EMEA" vs "Amazon Web Services"), amount drift (prices change), and irregular calendars (28-day vs 31-day months). Our algorithm groups by normalised merchant prefix and checks interval regularity with a fuzzy match - it works well on clean data but breaks on real-world bank exports where the same vendor appears under five different names.
Tax estimation without a tax return. We only have transaction data. We can't know what's deductible, what's already been paid, or what the actual accounting period is. Our VAT estimate assumes all revenue is VAT-applicable and all expenses are VAT-deductible, which isn't always true. We call this an estimate deliberately — and the UI makes that clear. Getting the formula right enough to be useful without being wrong enough to mislead was a careful balance.
Groq JSON reliability. The reasoning models (particularly qwen3-32b) emit ... blocks before their actual response, which broke our JSON parser on first attempt. We added a stripping pass:

const stripped = raw.replace(/[\s\S]?<\/think>/gi, '').trim(); const match = stripped.match(/{[\s\S]}/); The response_format: { type: 'json_object' } parameter on smaller models helped significantly, but wasn't available on all models we tried.

Waterfall latency on first load. The AI insights query can only fire after summary + runway data resolves, which requires two sequential backend calls first. On a cold start, the AI panel takes 5–8 seconds to appear. We mitigated this with staleTime: 5 * 60_000 (so it doesn't re-fire on every visit) and a proper loading skeleton, but it's still a noticeable delay on first render.
Dual user type tax regimes. Keeping the SME and individual tax logic cleanly separated — same UI, same engine, different numbers - required a configuration layer (tax-config.js) that the entire backend consumes. Getting the label system right ("Payroll" vs "Monthly Income", "Corp Tax Reserve" vs "Income Tax Reserve") so the UI felt native to each user type took more iteration than expected.

Accomplishments that we're proud of The affordability advisor actually works. You can type "Can I afford a Golden Retriever?" and it estimates costs, checks them against your true available cash, and gives you a reasoned verdict. That felt like magic when it first worked. The tax vault. It's a simple idea — reserve your estimated tax before you spend — but seeing it visualised as a concrete "do not touch" number makes it genuinely useful. Full-stack AI integration in a hackathon. Groq for inference, Plaid for bank data, Stripe for monetisation, Supabase for auth and persistence — all wired together and actually running. Two distinct user experiences from one codebase. SME mode feels like a CFO dashboard; individual mode feels like a personal finance tool. Same engine, same data shape, completely different framing. What we learned The hardest part of fintech is trust, not technology. Users need to believe the number. Every label, caveat, and decimal place is a trust signal. We learned to be explicit about what's estimated vs. actual everywhere in the UI. Groq is fast enough for real-time financial Q&A. Sub-2-second responses on llama-3.1-8b-instant made the advisor feel conversational rather than transactional. Sandbox data needs to feel real. Generic transaction names ("Merchant A", "Payment 1") make a demo unconvincing. Specific, recognisable merchants (AWS, Slack, HubSpot, Dublin Office Lease) make judges feel the product. Tax is a narrative, not a number. "You owe €4,200 in corp tax" lands differently than "Your tax reserve means you have €4,200 you shouldn't touch." Same number, completely different emotional response. What's next for PocketCFO Open Banking (GoCardless / TrueLayer) — Plaid's European coverage is limited. TrueLayer covers Irish banks natively, which is the actual market we're building for. Accountant-verified tax mode — partner with a chartered accountant to offer a reviewed (not just estimated) tax reserve figure, making the vault genuinely defensible. Scenario modeling - "What if I hire two people?" or "What if revenue drops 30%?" modelled as branching forecasts, not just single-point estimates. Mobile app - the core dashboard is the kind of thing you check every morning. A native app with push alerts ("⚠️ Your runway dropped below 30 days") changes the behaviour loop entirely. Multi-entity support - a founder with a Ltd and a sole trader sideline needs both views in one place. The data model supports it; the UX doesn't yet. Revenue-based forecasting — right now the forecast is expense-driven. Adding probabilistic revenue modelling (based on invoice history and payment patterns) would make the 30-day projection genuinely predictive rather than just extrapolated.