# Personal Finance App > Data-entry-first financial planning, the missing tool between budgeting apps and advisor software - HTML version: https://robbiepalmer.me/projects/personal-finance-app - Status: idea - Started: 2026-01-11 - Updated: 2026-09-27 - Technologies: Frankfurter Read the shorter [project pitch deck](https://robbiepalmer.me/projects/personal-finance-app/deck.md). # Problem Financially savvy individuals and startup founders face a fundamental gap in personal finance tooling. The market offers two inadequate extremes: * **Consumer budgeting apps** (Monarch, YNAB, Emma) focus on expense categorisation and week-to-week budgeting, missing the strategic view entirely * **Financial advisor tools** (Voyant, eMoney, RightCapital) provide proper modelling but are B2B, require certification, and cost thousands per year The result: power users default to spreadsheets. But spreadsheets are fundamentally broken for this use case: * Fragile formulas that silently break when rows are inserted or cells are copy-pasted * No documentation, version control, or testing infrastructure * Zero compounding returns: every model starts from scratch * Difficult to maintain multi-entity models (individual + partner + household) * No support for multi-currency, tax jurisdiction complexity, or inter-linked accounts This creates a painful irony: a tool for modelling compounding returns offers zero compounding returns itself. **What this actually looks like:** You buy a house with a partner. You've each contributed different amounts to the deposit, have a joint mortgage at a fixed rate that's about to expire, and need to track equity over time. Meanwhile, you have RSUs from a previous employer priced in USD, which you converted to GBP and put into index funds that are themselves mostly US-centric. You want to record a large purchase without rescanning every account you own just to keep the graphs accurate. You've closed some old accounts but don't want to lose the historical trend data, so you're entering rows of zeros. And you want a rough sense of monthly expenditure based on income minus current account balance, not the soul-crushing exercise of categorising every coffee and receipt. In a spreadsheet, each of these is a separate tab with its own formula logic, its own currency assumptions, and its own way of breaking when you touch anything else. It's impossible to maintain, and a complete time sink. # Proposal A web application designed for wealth trajectory tracking and financial forecasting, optimised for data entry and casual recording rather than model-first complexity. **Working title:** Asset Tracker. Branding is not a priority. The product earns a name when it earns users. ## Core Principles 1. **Data-entry first:** UX optimised for quickly and flexibly recording financial reality on mobile, not forcing users into rigid models. Open Banking integration comes later as an accelerant, not a dependency 2. **Multi-entity by default:** Support for individual users, partners, and shared household entities with ownership percentages 3. **Multi-currency native:** Track accounts in different currencies with historical exchange rate handling 4. **Forecast vs. reality reconciliation:** Highlight when forecasts diverge from actuals as new data is entered 5. **Beautiful, glanceable output:** Plots that answer "am I on track?" rather than tables that require interpretation 6. **UK-first, internationally minded:** Launch with GBP defaults and first-class UK tax modelling, an area where competitors like ProjectionLab remain shallow, with architecture that supports expansion to other jurisdictions 7. **Free until proven:** Ship free with full functionality. Introduce paid tiers only after real usage reveals which features command willingness to pay ## Key Features ### v1: Track and understand * Asset/liability tracking over time with CAGR calculations * Stock tracking by units, to enable tracking independent of currency swings * Recurring transfers and loan tracking * Inter-linked accounts * Multiple income stream tracking with trend analysis * UK tax impact modelling (income tax, CGT, ISA/pension allowances) ### Later: Automate and forecast * Open Banking integration for automated imports * Tax modelling for additional jurisdictions * Scenario-based forecasting (what-if modelling) * Actionable insights: ready to invest, need emergency fund, should pay down debt # Competitor Analysis ## [ProjectionLab](https://projectionlab.com) **Overview:** Bootstrapped financial planning tool founded in 2021 by Kyle Nolan (Boston). Self-funded via subscriptions, no VC backing. Targets the FIRE community and sophisticated DIY planners. **Pricing:** [$130/year (Premium) or $550/year (Pro for advisors). Lifetime option available for $1200.](https://projectionlab.com/pricing) ### Strengths * Excellent forecasting and Monte Carlo simulations * Strong international tax presets (UK, Canada, Australia, Germany, Netherlands) * Beautiful Sankey cash flow visualisations * Privacy-first: no account linking required * Active community and transparent development (#buildinpublic) * Historical backtesting against real market data * Self-hosting option for lifetime customers ### Gaps (Opportunities) * Model-first design: not optimised for casual data entry * No multi-currency account support * Limited to single user + spouse (no extended household/entity modelling) * No support for inter-linked user accounts (spouse and user come under single account) * No recurring transfer or inter-linked account tracking * Stocks must be entered as prices, not units (no automatic CAGR) * No mobile app * Key features paywalled with no true freemium tier (data doesn't persist without subscription) ## [Monarch Money](https://www.monarchmoney.com) **Overview:** VC-backed personal finance app ([$95M total funding](https://www.crunchbase.com/organization/monarch-money-inc)). Positioned as the Mint replacement after Intuit shut down Mint in early 2024. Founded 2018 in San Francisco. **Pricing:** [$100/year or $15/month. 7-day free trial.](https://www.monarchmoney.com/pricing) ### Strengths * Excellent Open Banking integration (13,000+ institutions via Plaid, MX, Finicity) * Strong couples/collaboration features * Net worth tracking and investment monitoring * Slick UI with cross-platform sync (web, iOS, Android) * Credit score monitoring included * 20x user growth post-Mint shutdown ### Gaps (Opportunities) * Budgeting-focused: lacks sophisticated forecasting and scenario modelling * No retirement/goal projections * US-centric: limited international tax support * VC-backed: potential for feature bloat or pivot pressure * Requires account linking (privacy concerns for some users) ## Other Competitors | Tool | Price/yr | Focus | Forecasting | Data Entry | Multi-currency | | ------------------------------------ | ---------- | ----------- | ----------- | ---------- | -------------- | | [YNAB](https://www.ynab.com) | $109 | Budgeting | None | Manual | No | | [Copilot](https://copilot.money) | $95 | Tracking | Basic | Auto-sync | No | | [Empower](https://www.empower.com) | Free\* | Investments | Retirement | Auto-sync | No | | [Kubera](https://www.kubera.com) | $150 | Net worth | Limited | Both | Yes | | [Ghostfolio](https://ghostfolio.dev) | Free (OSS) | Investments | None | Manual | Yes | \*Empower upsells advisory services (0.89%+ AUM) ## Positioning map | | Rigid / model-first | Flexible / entry-first | | -------------------------- | ------------------------------------------- | ------------------------------ | | **Forecasting & planning** | ProjectionLab, Voyant, eMoney, RightCapital | **← The gap** | | **Budgeting & tracking** | YNAB | Monarch, Copilot, Spreadsheets | Every competitor sits in one of three quadrants. The top-right, sophisticated financial planning with flexible, low-friction data entry, is empty. That's the target. # Market Opportunity ## The prosumer gap The personal finance market has a structural gap. Consumer apps (YNAB, Monarch) top out at \~$100/year and focus on budgeting, expense categorisation, envelope allocation, week-to-week tracking. Professional advisor tools (Voyant, NaviPlan, eMoney) offer proper modelling but are B2B, cost $2,000–10,000+/year per seat, and often require CFP certification. No product today combines flexible data capture with advisor-grade forecasting at prosumer pricing, particularly with multi-currency, multi-entity, and UK-first positioning. ## Spreadsheet users are the market Among people who actively budget, [\~40% use spreadsheets](https://wallethub.com/edu/budgeting-statistics/146387). Only 14% use a dedicated budgeting app. Higher-income and 30–44 age demographics skew even more heavily toward spreadsheets. These users have self-selected as "too sophisticated for consumer apps". They want control and flexibility, but are stuck with fragile formulas, no version control, and models that they rebuild from zero every time. This is the target user: someone already doing the work, but with broken tools. ## Proven demand ProjectionLab is the clearest proof point. A solo founder, building nights and weekends, [reached $1M ARR in 4 years](https://projectionlab.com/blog/we-reached-1m-arr-with-zero-funding) with zero funding. 100,000+ households on the platform. The growth curve inflected sharply once the founder went full-time, roughly 3.5x in 19 months (Nov 2023: $23K MRR → Jun 2025: $83K MRR). This demonstrates strong product-market fit in the FIRE/prosumer segment. Monarch Money, meanwhile, proves the broader personal finance market is growing explosively, [$95M total funding](https://www.crunchbase.com/organization/monarch-money-inc), 20x user growth after Mint's shutdown. But it stays in the budgeting lane. | Company | Capital | Target | Validation Signal | | :------------ | :--------------------- | :----------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ProjectionLab | Bootstrapped | FIRE / prosumer planners | [\~$1M ARR](https://projectionlab.com/blog/we-reached-1m-arr-with-zero-funding) (Open Startup) | | Monarch Money | $95M Raised (Series B) | Post-Mint budgeters | [Top-tier VC Backing](https://www.pymnts.com/news/investment-tracker/2025/monarch-money-raises-75-million-to-grow-financial-wellness-platform/) (Series B Co-Led by FPV) | | YNAB | Bootstrapped | Budget-focused | [Category Pioneer (Founded 2004)](https://www.ynab.com/about-us) (Classic "Envelope" App) | ## UK structural advantage The UK offers a unique entry point: * **Open Banking maturity:** The UK pioneered Open Banking (2018) and now has [15.16M active users](https://www.openbanking.org.uk/news/open-banking-surges-to-15-million-uk-users-as-july-marks-record-adoption/) (\~33% of adults as of July 2025). Free API access, no per-connection fees like Plaid in the US * **Underserved market:** UK personal finance software market is [\~$50M](https://www.imarcgroup.com/uk-personal-finance-software-market) within a [\~$1.5B global market](https://www.fortunebusinessinsights.com/personal-finance-software-market-112683) that is overwhelmingly US-centric. Most competitors build for US users first and bolt on international support as an afterthought * **Regulatory tailwinds:** FCA's Open Finance roadmap favours data portability and consumer empowerment * **Tax complexity:** UK tax has enough nuance (ISAs, SIPPs, CGT allowances, dividend allowances, Scottish rates) to reward purpose-built modelling, yet competitors' UK tax support remains shallow * **Gateway to other underserved markets:** A UK-first approach builds the multi-currency, multi-jurisdiction architecture from day one. Open Banking is not UK-specific. The EU mandates it via PSD2, Australia has CDR (2020), Canada is implementing a federal framework, and Brazil/India have their own schemes. The natural expansion path is UK → other English-speaking markets (Canada, Australia) → EU, each following the same pattern: local tax complexity that US-built tools handle poorly, and Open Banking infrastructure ready to plug into ## Market size The global personal finance software market is [\~$1.5B](https://www.fortunebusinessinsights.com/personal-finance-software-market-112683) (2025), split roughly: [US \~$285M](https://www.researchandmarkets.com/reports/6172669/united-states-personal-finance-software-market), [UK \~$50M](https://www.imarcgroup.com/uk-personal-finance-software-market), rest of world \~$1.15B. The US is the largest single market but represents only \~19% of the global total. The majority sits in markets poorly served by US-centric tools. The more relevant adjacent market is financial planning software (advisor tools): [$3.7B growing to $16.9B by 2031](https://www.alliedmarketresearch.com/financial-planning-software-market-A16422) (16.6% CAGR). A prosumer tool that bridges consumer and advisor categories doesn't compete for share of the $1.5B consumer market. It expands into the gap between consumer and advisor. Even capturing a fraction of ProjectionLab's trajectory (100K households at \~$10/month average) validates a meaningful indie business. ## Future expansion: startup finance Startup founders have a uniquely blurred line between personal and business finance. Tracking personal burn rate alongside company burn rate, equity compensation, multiple income streams, and runway for both their company and their personal savings. Defer this beyond v1. The same modelling engine that handles "when can I retire?" handles "how long is my personal runway if my startup fails?" The architecture should support this concentric expansion. Validation: Pry Financials (10-person team, $4.2M raised) was [acquired by Brex for $90M](https://techcrunch.com/2022/04/19/brex-just-paid-90m-for-pry-financials-a-10-person-financial-planning-software-startup-and-heres-why/) for exactly this "founder spreadsheet replacement" use case. [Runway](https://tracxn.com/d/companies/runway/__vhBnElE1V7XdbRzVmmpiHoTvQnjiEeEjFcQvmRbIttw) and [Jirav](https://techcrunch.com/2023/07/11/jirav-a-startup-developing-financial-planning-software-for-businesses-raises-20m/) have each raised $30M+ for startup FP\&A. # Why Now ## Market timing * **Post-Mint vacuum:** Mint's shutdown in early 2024 displaced millions of users. Monarch captured many, but its budgeting focus leaves the prosumer segment underserved. The market is actively looking for alternatives * **Open Banking at critical mass:** The UK has 15M+ active Open Banking users, projected to reach 60% of adults by 2026. The infrastructure for automated data ingestion is mature just as a v2 would need it. Building v1 on manual entry now means Open Banking integration lands when adoption is at its peak * **Early innings for prosumer tools:** ProjectionLab only hit $1M ARR in mid-2025. 100K households out of millions of spreadsheet-based financial planners is less than 1% penetration. The category is proven but far from saturated * **Financial planning feels urgent:** Cost of living pressures and volatile interest rates have made active financial management feel necessary rather than optional. More people are tracking than ever, and the FIRE movement continues to grow (2.4M+ on r/financialindependence) ## Personal timing * **Agentic coding as a force multiplier:** AI-assisted development enables a solo developer to build at team scale, ramping up on unfamiliar stacks orders of magnitude faster than before * **Right intersection of skills:** Deep experience in startups and project management, combined with genuine personal interest in finance and a track record of building products * **Runway to commit:** Personal financial position allows full commitment to this, versus 6 years ago when the idea first emerged but the skillset and runway weren't there # Architecture ## Current prototype The live Asset Tracker is a statically exported Next.js application on Cloudflare Pages. Its domain commands run entirely in the browser, and each browser stores its own state in local storage. JSON and CSV import/export provide the only persistence boundary beyond that browser. There is no product backend, shared database, user identity, or object storage in the current version. That constraint keeps the first-user experiment cheap and private, but it cannot support shared households, cross-device continuity, or account recovery. ## Data flow and private-data boundaries The current prototype and the planned shared product have different security boundaries. Solid lines below are implemented flows. Dashed lines and orange nodes are planned. The labels describe data classes, not real financial records. ```mermaid flowchart TB User["Person using Asset Tracker
[External]"] ImportFiles["JSON or CSV import files
[External, private]"] ExportFiles["JSON or CSV exports
[External, private]"] Identity["Consumer identity provider
[External, planned, not selected]"] Bank["Open Banking provider
[External, later]"] subgraph device["Private-data boundary: one browser profile [current]"] Client["Next.js client and domain commands
[Implemented]"] LocalStore[("Browser local storage
[Implemented system of record]")] Client <-->|"financial state"| LocalStore end subgraph cloud["Private-data boundary: household-authorized service [planned]"] API["Cloudflare Worker REST API
Authentication, authorization,
validation, domain commands"] Postgres[("Neon PostgreSQL
Structured financial records
and audit history")] Objects[("Cloudflare R2
Optional statements, receipts,
encrypted export artifacts")] API <-->|"household-scoped records"| Postgres API -.->|"files, only when needed"| Objects end Pages["Cloudflare Pages
[Implemented, public app assets only]"] User -->|"uses"| Client Pages -->|"serves code and PWA assets"| Client ImportFiles -->|"manual import"| Client Client -->|"user-requested export"| ExportFiles Client -.->|"authenticated HTTPS"| API Identity -.->|"identity and session claims"| API Bank -.->|"authorized account import"| API API -.->|"user-requested export"| ExportFiles classDef current fill:#dcfce7,color:#14532d,stroke:#16a34a classDef planned fill:#fff7ed,color:#9a3412,stroke:#ea580c,stroke-dasharray:5 5 classDef external fill:#475569,color:#fff,stroke:#334155 class Client,LocalStore,Pages current class API,Postgres,Objects planned class User,ImportFiles,ExportFiles external class Identity,Bank planned ``` In the current version, Pages sends public application assets to the browser. The browser runs the domain commands and keeps all structured financial state inside that browser profile. A person can bring private JSON or CSV files into the browser and export a new private file. No financial record crosses a product API because that API does not exist yet. In the planned shared version, the browser sends authenticated requests to one Worker API. The Worker, not the browser or Pages, checks identity and household access. It stores structured records and audit history in PostgreSQL. R2 remains optional and stores files only, never the primary account or balance records. A future Open Banking provider may send authorized imports through the same API. User-requested JSON or CSV export remains an exit path from the private-data boundary. The identity provider and its recovery policy are still undecided. ## Target architecture The shared version will use the existing platform defaults while keeping each responsibility explicit: * **Cloudflare Pages** serves the statically exported, mobile-first Next.js application and its PWA assets. It does not store or authorize access to private financial records * **A dedicated Cloudflare Worker** exposes a versioned REST API, authenticates each request, enforces household and ownership permissions, and runs the financial domain commands * **PostgreSQL on Neon** is the system of record for people, households, ownership, accounts, balances, transfers, plans, and audit history. The Worker reaches it through a connection path suitable for the Workers runtime * **Cloudflare R2** is optional object storage for features that introduce files, such as uploaded statements, receipts, or encrypted export artifacts. It is not the primary store for structured financial state The existing asynchronous API interface and pure domain commands remain the seam between the browser and the backend. Moving persistence to PostgreSQL should preserve those domain rules without treating the browser's current JSON document as the server schema. ## Data model Multi-entity by design: * **Users** → own one or more **Entities** (self, partner, household, business) * **Entities** → own one or more **Accounts** (bank, investment, pension, liability) * **Accounts** → have a currency and a series of **Entries** (balance snapshots, transactions) * **Exchange rates** stored as a time-series for multi-currency reconciliation Optimised for the core query: "what was the value of X on date Y in currency Z?" ## Frontend Mobile-first responsive web app, not a native app. Optimised for the primary use case: quickly recording a balance or transaction on a phone. A Progressive Web App (PWA) supports home screen installation; offline writes remain a separate design decision below. ## API design The target is a versioned REST API owned by the Worker. Pages serves the client, while the Worker owns authorization, validation, writes, and household-scoped read models. The entity/account/entry abstraction maps naturally to both personal and business financial tracking, so a future startup-finance surface can reuse the domain model without sharing database access with the browser. ## Identity, privacy, and offline use * No third-party data sharing in v1 (manual entry means no Open Banking provider dependencies) * Users own their data, export to CSV/JSON as a first-class feature * Cloudflare Access remains infrastructure protection for previews and administrative surfaces; it is not the consumer identity system * The consumer identity provider, supported sign-in methods, session model, and account-recovery policy are not yet selected. They must be decided before private data moves to the shared backend * Provider encryption at rest and TLS are baseline controls. Application-level encryption, key recovery, retention, and deletion remain explicit design work before a multi-user alpha * PWA installation remains part of the frontend direction. Offline writes and synchronization are unresolved because household edits need defined conflict, ordering, and recovery semantics before they can be queued safely # Target Persona The target user expands in concentric rings, where each ring validates features needed by the next: 1. **The founder**, building for own pain points. Currently uses spreadsheets to track multi-currency assets, UK tax obligations, and long-term wealth trajectory. The app needs to be better than the spreadsheet for this one user before anything else matters 2. **Partner**, validates multi-entity modelling, shared household views, and the UX for someone who wants visibility without building their own spreadsheet 3. **Friends, family, colleagues**, invite-only. Diverse financial situations stress-test assumptions: different income structures, different countries, different levels of financial sophistication 4. **General market**, only after the core product is proven through real usage by real people with real money This deliberate strategy lets each ring generate genuine usage data and unfiltered feedback faster than any survey or market research. The product ships once it meets the next ring's needs, independent of the calendar. ## What PMF looks like This is not a daily-use product. A healthy user opens it a few times a month to log balances, check their trajectory, or run a scenario. Visit frequency is a misleading metric. **The real signal is data depth**, how much of their financial life a user has committed to the app: * Number of accounts tracked * Volume of balance entries over time * Complexity of setup: recurring transfers, inter-linked accounts, connections with other users' accounts, multi-entity configurations A user who has 15 accounts, 6 months of balance history, a joint mortgage linked to their partner's entity, and 3 standing orders modelled is unlikely to leave. That depth of committed data is both the PMF signal and the retention mechanism. **Per ring:** * **Ring 1:** The founder has deleted their spreadsheet * **Ring 2:** Partner actively logs their own data without being asked * **Ring 3:** Invited users return unprompted and add accounts beyond the first one # Go-to-Market ## Phase 1: Invite-only validation Build for self, then expand to partner and inner circle. The product must earn regular usage, not just sign-ups, before any public launch. No marketing spend, no landing page optimisation. Just a tool that's genuinely better than the spreadsheet it replaces. ## Phase 2: Community-driven growth Once the product is solid, go where the target users already are: * **FIRE communities**, r/financialindependence (2.4M subscribers), r/UKPersonalFinance, Bogleheads * **Hacker News**. ProjectionLab's first traction came from an HN post; the "Show HN" audience is exactly the power-user persona * **Podcasts and creators**. ChooseFI drove a major inflection for ProjectionLab; UK equivalents like Meaningful Money and The FIRE Starter exist * **Build in public**. Document the journey, share the architecture decisions, attract users who value transparency ## Phase 3: Content and SEO Blog content, social media, comparison pages. Only after the product is proven through real usage. Content should be genuinely useful (UK tax guides, financial planning frameworks) rather than pure marketing. # Risks ## Generalisability Building for yourself risks over-fitting to your own financial situation. A tool that perfectly models one person's multi-currency ISA/SIPP/GIA setup might be confusing to someone with a simpler portfolio. **Mitigation:** Each concentric ring of users stress-tests this. A partner has different priorities. Friends have different income structures. Colleagues in different countries expose jurisdiction assumptions. The architecture must keep simple cases simple and introduce complexity only when the user's finances require it. ## Solo execution Competing against funded teams (Monarch: $95M raised) and established bootstrappers (ProjectionLab: 4 years of momentum, growing team). **Mitigation:** ProjectionLab proved a solo founder can reach $1M ARR. Scope discipline matters more than headcount. The Cloudflare stack minimises ops overhead. The product also serves a different persona, which avoids head-to-head competition. ## Platform risk An earlier architecture draft selected Cloudflare D1 for the future database. That direction is historical and has been superseded by the platform's PostgreSQL and Neon defaults. The target still depends on Cloudflare Pages, Workers, and optionally R2, while Neon supplies the managed relational database. **Mitigation:** Keep private data behind a versioned HTTP API, keep the relational model and migrations compatible with PostgreSQL, and keep file objects exportable. Pages, the Worker runtime, the PostgreSQL host, and optional object storage then remain replaceable boundaries rather than one inseparable data platform. ## Incumbent ecosystem ProjectionLab has 100K households, an active Discord community, and 4 years of feature development. Their users are unlikely to switch. **Mitigation:** Not targeting their existing users. Targeting the people who tried ProjectionLab and bounced because it was too model-heavy, or who never found it because they weren't looking for a "financial planner". They were looking for a better spreadsheet. Different positioning (data-entry first vs model-first) attracts different personas. ## Lessons from Mint and other failures The personal finance app graveyard is instructive. [Mint](https://en.wikipedia.org/wiki/Intuit_Mint) (shut down 2024), [Tally](https://techcrunch.com/2024/08/06/debt-management-app-tally-abruptly-shuts-down/) ($172M raised, shut down 2024), Simple (acquired for $117M, shut down 2021), and Level Money (acquired by Capital One, shut down 2017) all share the same fatal pattern: 1. **Free consumer model** with no clear path to subscription revenue 2. **Referral/ad-based monetisation** that misaligned incentives. The highest-commission products were rarely best for users 3. **Expensive data aggregation**. Plaid/Yodlee costs [$0.60–0.90/user/month](https://www.getmonetizely.com/articles/plaid-vs-yodlee-how-much-will-financial-data-apis-cost-your-fintech) at scale, creating negative unit economics on every free user 4. **Never profitable**. Mint ran for 15 years without meaningful profitability The contrast is stark: YNAB and Monarch Money (both subscription-based) are thriving. The lesson is not "don't be free". It's "never monetise through referrals, and don't let free become a permanent identity." **How this app avoids each trap:** * **Data cost trap:** UK Open Banking is free at the API level, no per-connection fees like Plaid. And v1 is manual-only, so data aggregation cost is zero * **Referral revenue trap:** Subscription or nothing. Never recommend financial products for commission * **"Free forever" trap:** "Free until proven" is a temporary pre-PMF strategy. Early adopters get lifetime free access as a reward for providing the PMF signals that matter more than their subscription revenue. New users post-PMF pay subscriptions. Publishing that plan up front prevents a bait-and-switch * **Acquisition trap:** Maintaining control over product direction. Simple and Level Money were killed by big-bank acquirers who couldn't justify a non-revenue product internally # Defensibility No moat exists at v1, and the code is open source with no proprietary IP. This is true of every early-stage product. Some just delude themselves otherwise. **Pre-PMF:** Product vision and relentless execution are the only advantages. PMF itself, and the momentum that follows, are the moat. **Post-PMF, moats build naturally:** * **Data gravity**. Users accumulate years of financial history. Exporting is possible (and should be), but rebuilding context, categories, and entity relationships is painful enough to create retention * **Jurisdiction depth**. Deep, accurate UK tax modelling is tedious and time-consuming to replicate. Each additional jurisdiction compounds this advantage * **Multi-entity complexity**. Household configurations, ownership percentages, and inter-linked accounts become switching costs as users build out their financial picture * **Community and trust**. Financial data is intimate. Users who trust a product with their full financial picture don't switch lightly # Revenue Model ## Near-term: personal finance The core product is free. No artificial limits, no "you've reached 5 accounts" gates. The current phase prioritizes genuine usage and PMF. Monetisation follows proof. **Early adopter pricing:** Users from rings 1–3 (invite-only phase) get lifetime free access. Their value is in PMF signals, feedback, and early traction, worth far more than any subscription revenue. When paid tiers launch, they apply to new users only. This rewards early believers, avoids the bait-and-switch resentment that poisons trust, and is the right thing to do. Paid features will emerge from usage data, but the likely candidates are: * **Complex tax modelling**, automated UK tax calculations, allowance optimisation, scenario analysis for tax-efficient withdrawals * **Advanced forecasting**, Monte Carlo simulations, what-if scenarios, retirement projections * **Priority support and early access** to new features The pitch to paying users: stop spending hours maintaining fragile spreadsheets every budget cycle. This app keeps your financial model up to date so you can focus on higher-level analysis and decisions that actually move the needle. ## Long-term: startup finance The "whale" opportunity. Business financial planning commands higher willingness to pay than personal: * **Burn rate and runway tracking** for startups, the same modelling engine, different framing * **Equity tracking** for employees, vesting schedules, dilution scenarios, exercise planning. Sold to companies as a benefit, used by employees for personal financial planning * **Financial planning as a benefit**. Companies offer it alongside pension matching and health insurance This edges toward Carta and HR tooling territory without getting sucked into that scope. The same entity/account/entry architecture extends from personal to business use cases while the product keeps its original direction. ## Funding approach The immediate priority is building the alpha and validating with real usage. Funding decisions follow PMF signals. Subscription-funded products such as Monarch Money show one viable model, while Mint's closure after Intuit moved users to Credit Karma shows that corporate backing alone does not guarantee longevity. These examples inform the funding strategy without proving that either business model caused the outcome. Several paths are worth exploring once there's something to fund: * **Grants (non-dilutive):** * **[Techstart PoC Concept Grant](https://www.investni.com/support-for-business/innovation-research-and-development/techstart-ventures-proof-of-concept-grant-fund) (up to £15k, Concept Plus up to £30k):** Invest NI's strongest fit for this stage. Solo founders welcome, pre-revenue fine, no sector bias, appears to be 100% funded. Constraints: cannot be used for marketing; oriented toward market research and product development with clear milestones. Can cover part of salary if incorporated as a Ltd company with timesheets and demonstrable outcomes * **[Invest NI Business Innovation Grant](https://www.investni.com/support-for-business/innovation-support/business-innovation-grant) (£5k–£20k at 70%):** Requires 30% match funding and a demonstrable innovation. Rounds open periodically * **Incubators/accelerators:** * **[Founder Labs Accelerator](https://ormeaulabs.com/programs-and-support/founder-labs) (£25k in non-dilutive capital, over £500k in credits, and 52 weeks of office space):** Invest NI-backed programme run by Ormeau Labs with partners. Its published programme includes six months of support and international trips to San Francisco, New York, London, and Dublin. Verify current cohort dates and application terms before applying * **Fintech accelerators:** [FCA Open Finance Accelerator](https://fintech.garden/news/2025-10-14-fca-launches-open-finance-accelerator/) (relevant once Open Banking integration is built), [NatWest Fintech Programme](https://www.natwestgroup.com/news-and-insights/news-room/press-releases/ai-and-data/2025/dec/natwest-group-opens-applications-for-2026-fintech-programme.html), JP Morgan Fintech Forward (requires product in market) * **VC:** Early-stage or fintech-specialist investors who understand that this category rewards patience over blitzscaling. The right investor accelerates without distorting the product * **Bootstrapped:** ProjectionLab's $0-to-$1M-ARR trajectory proves this works. Lower growth rate, full control **Ecosystem note:** Belfast is [ranked #1 globally for fintech development investment](https://www.investni.com/invest-in-northern-ireland/fintech), with 7,000+ people employed across 74 firms. [Catalyst Belfast Fintech](https://wearecatalyst.org/) offers dedicated fintech co-working space in partnership with Danske Bank. The NI fintech ecosystem is a genuine asset worth plugging into regardless of funding path. No commitment to any path yet. The alpha comes first. ## Initiatives - [Digital Twins for Everyday Life](https://robbiepalmer.me/initiatives/digital-twins-for-everyday-life.md): Proposes a financial twin of people, households, ownership, accounts, currencies, transfers, and plans that can replace a fragile spreadsheet. ## Architecture Decision Records - [ADR 000: Use bitemporal financial records with calculation lineage](https://robbiepalmer.me/projects/personal-finance-app/adrs/000-financial-fact-and-calculation-provenance.md) — Proposed, 2026-09-24 - [ADR 001: Make the household the authorization boundary](https://robbiepalmer.me/projects/personal-finance-app/adrs/001-household-identity-and-authorization-boundary.md) — Proposed, 2026-09-24 - [ADR 002: Limit copies of financial content](https://robbiepalmer.me/projects/personal-finance-app/adrs/002-private-data-lifecycle-and-telemetry.md) — Proposed, 2026-09-24 - [ADR 003: Keep shared financial writes online](https://robbiepalmer.me/projects/personal-finance-app/adrs/003-online-only-shared-financial-writes.md) — Proposed, 2026-09-24 - [ADR 004: Use Frankfurter for reference exchange rates](https://robbiepalmer.me/projects/personal-finance-app/adrs/004-frankfurter-reference-exchange-rates.md) — Accepted, 2026-10-02 - [ADR 004: Use versioned official housing-price releases](https://robbiepalmer.me/projects/personal-finance-app/adrs/004-versioned-official-housing-price-data.md) — Proposed, 2026-10-02 - [ADR 005: Adapt SavingTool for annual salary estimates](https://robbiepalmer.me/projects/personal-finance-app/adrs/005-adapt-savingtool-for-annual-salary-estimates.md) — Accepted, 2026-10-03 --- Markdown index of this site: https://robbiepalmer.me/llms.txt