Roadmap¶

What's queued up, by how soon rather than by theme. This is a snapshot, not a contract — things move between horizons as priorities shift.

How to read this page

Now — in flight, or the very next thing to pick up.
Next — on deck and scoped: clear enough to start once Now clears.
Later — real work we intend to do, but not soon. Grouped by the four strategic pillars so you can see what each serves.
The vision track — the bigger builds that turn Maud from filing into readiness. Mostly unscoped; this is where the Vision becomes product.
Open questions & investigations — decisions and spikes, not committed work.

Some items carry a 🔗 link to a GitHub issue — those are scoped tightly and ready to pick up. The rest live here only.

The four pillars (they map straight onto the Vision):

Readiness — turning stored data into proactive value: reminders, the maintenance calendar, the readiness report, the conversational organiser.
Preparedness intelligence — the learning engine: Triage smarts, suppression, and eventually cross-household learning of what good preparation looks like.
Distribution — the payoff and the commercial spine: packs, partnerships, pricing, go-live.
Foundations — the excellent, trustworthy base everything else stands on: security, auth, infrastructure, cost, quality.

Where else to look

What's already live and the full shipped list: status.md at the repo root.
What shipped when: maud/CHANGELOG.md — dated entries per merged PR.
The strategic backstory: phase_1_slices.md and the Vision page.

Shipped items no longer live on this page — they're recorded in status.md and maud/CHANGELOG.md. This page is for what's still ahead.

Now¶

Nothing mid-flight right now — the auth arc (#142–#144) and the readiness dashboard + renewals work (#173–#175) all shipped. The top of Next is the next thing to pick up.

Next¶

Polish the first-scan experience. — Preparedness intelligence. Same logic, same AI, but the experience should reflect that the first scan is project-like ("here are 50 documents we found, let's sort them all in one sweep") rather than notification-like ("you have 3 new findings"). Bulk-accept and bulk-dismiss should be more prominent. Every dismissal should aggressively seed the learned-suppression rules — the first scan is where the system learns most about what you don't care about.
"Did you mean?" picker when accepting Gmail findings. — Preparedness intelligence. When the AI says "this looks like a document about 16 High St" and you've already registered "16 High Street", show that as a "did you mean?" option instead of creating a duplicate property. Adds an "aliases" field on each property/vehicle so the system remembers old names you've merged in.
Propose properties and vehicles you haven't registered yet, from Gmail. — Preparedness intelligence. When the scan finds documents mentioning a property at "Chatel, France" but you haven't registered it, a friendly banner on the Triage page: "We saw documents that look like they're for a Chatel property — add it and we'll file these correctly?" One click adds it and re-runs the AI on the affected findings, moving them out of the "unclear" bucket. Works for any registered-thing kind.
Dashboard alert overlays (per-area "needs attention"). — Readiness. The redesigned area tiles reserve a coral alert state — border + disc tint go coral, the completion % turns coral, and a small flag row appears (e.g. ⚠ "MOT due in 3 weeks", "3 documents unfiled", "missing a critical document"). The tile markup already supports this; what's missing is the rule for when an area is in alert. Candidate signals: MOT expired/expiring within N weeks and road-tax status (both stored from the DVLA/DVSA lookup); documents sitting unfiled against an entity; a critical checklist item still missing. The renewals engine (🔗 #173) now provides a ready-made rule — an area owning a coral-band renewal is a natural alert trigger — so what's left is wiring it to the tiles and deciding the other signals' thresholds.

Later¶

Real work, not soon. Grouped by the pillar each item serves.

Readiness¶

"Get documents in" panel should graduate. Right now that big accent panel dominates the dashboard regardless of how set up you are. It's onboarding scaffolding, not steady-state UI — it should collapse to a small reminder once you've connected Gmail, configured an email-in address, or filed at least three documents. The persistent + Add button in the nav is the home for ingestion from then on. (Partly superseded by the dashboard redesign — the empty-state hero now carries the welcome + Connect-email CTA; this bullet stays for the graduation nuance.)

Preparedness intelligence¶

These are independent ideas from the original Triage spike — each small-to-medium and shippable on its own.

Show drafts more quietly than final versions. A signed contract matters more than the draft sent five days earlier; today they look the same. Drafts should sit in a muted "watching" state and auto-replace when the final arrives.
Quotes and other "is it noise?" docs make sense if they belong to a project. A standalone plumbing quote is forgettable; the same quote inside a "kitchen renovation 2026" project is valuable. Project membership should be a reason to keep something.
Let a document belong to more than one topic. An email about a property matter from work might be relevant under both Property and Family-IDs. Today docs have one primary topic; support secondary topics as a soft tag.
One contract beats twelve bills. When you have a year of monthly electricity bills, the tariff/contract is the journal-grade record. Individual monthly bills should roll up quietly — perhaps a single "energy spend, year by year" summary — rather than 12 separate Documents. Needs a product call.
Be careful with silent dismissal. If the AI is confident something is a superseded draft, it hides it. But "this is a draft and I haven't found the final" is different — surface it with a question ("Did you sign this elsewhere?") rather than bury it.
Make dismissed items findable with reasoning visible. Anything the AI hid should be findable later, with its reasoning shown, plus a one-click "actually, keep this" rescue. Today they vanish silently, which is unsettling.
Better document search. Today search does a plain word-match across title, provider, and document type. Fine under a few hundred documents; slow and dumb above that. SQLite full-text-search adds relevance ranking, stemming, and phrase matching. About half a day — worth doing before the first household with 500+ documents, or as part of the Postgres move.
Deeper search and filter polish. Beyond the tag filtering that shipped: date ranges, person filters, smarter multi-tag combinations. Speculative — captured for when someone asks.
Make the DVLA lookup forgiving of weird input. If someone pastes a registration plate that includes a smart-quote or other non-standard character, the lookup crashes. Should reject it cleanly with a friendly message. About half an hour — defer until it happens to a real user.

Distribution¶

The commercial spine. Most of these need positioning, legal, or finance decisions before code can start.

Pricing tiers shaped around what each tier costs us. The per-user variable cost is mostly Claude API calls: ~$0.50–$1 for a first-time Gmail scan, ~$0.05–$0.15 per ongoing weekly scan once learned suppression kicks in. Proposed shape: Free = upload + email-in only, no Gmail Triage; One-off (£X once) = first-time Triage + 30 days of follow-up scans, then auto-downgrade; Ongoing (£Y/year) = continuous weekly scans + remembered junk. The "Ongoing" price only works because suppression compresses classifier costs over time.
Pick a payment processor. Stripe is the default; GoCardless for direct-debit subscriptions. Deferred until paid tiers are real.
Legal entity and trading arrangement. Who owns the product? Who holds the user data contractually? Drives privacy policy, T&Cs, payment flow, GDPR posture, ICO registration.
A separate marketing/sales website. Currently the only site outside the app is these developer docs. Needs a landing page, value prop, tier pricing, trust signals on security and privacy, signup CTA.
Go-live readiness checklist. A tracking page for the prerequisites scattered across docs and memory: Google's CASA security audit (gates Gmail past 100 users), commercial hosting (separate from the personal Fly account), payment integration, legal/privacy/T&Cs/data-protection agreements, email deliverability, ~~branch protection on main~~ (done 2026-08-08), on-call/observability, backup + disaster recovery.

Foundations¶

Tighten cross-household isolation on Person and house/vehicle records. These tables use Django's default access pattern, so a future PR that forgets a household filter would silently leak data across households. No live problem — every current query filters explicitly — but switching to the safer default is a tedious mechanical pass through ~20 production sites + ~170 tests. Not urgent; valuable defence-in-depth.
Move the rest of the heavy work onto the durable task queue. PR #82 set up the queue; #89 and the ongoing-Gmail-scan PR moved the webhook and scans onto it. Remaining: parallelise classifier calls within a single scan (~5× concurrency turns a 15-minute scan into ~3 minutes) and split out a separate worker machine when Postgres lands.
Switch the classifier from Claude Sonnet to Claude Haiku. Validated against ground-truth labels: Haiku matches Sonnet on precision and recall at ~3× lower cost per document. Production still uses Sonnet; switching is mostly config. Also bake in a retry for transient API errors, so a connection blip ⅔ through a big first scan doesn't cost 30% of the run.
Production prompt library. Version-controlled .md files for every prompt we send to Claude. Mostly subsumed by the taxonomy work, but the actual prompt strings still need a coherent home in the repo.
Visual data model diagram. The data model is described in text only. A Mermaid diagram makes changes far easier to review.
Data-protection impact assessment (DPIA) outline. Needed before any cross-household aggregate learning can switch on. Worth sketching early so consent architecture is built with it in mind. Gates the Preparedness intelligence engine below.
Wireframes / UI sketches for the key flows. Onboarding, the seeded dashboard, document confirmation, the readiness report. A Figma or Excalidraw job — text descriptions of UI flows have limits.

The vision track¶

The bigger bets that turn Maud from a filing cabinet that files itself into a household readiness advisor. These are mostly unscoped — direction, not tickets — and each is explained in the Vision. They're the answer to "how does the product become genuinely more useful, and harder to walk away from by being better."

The readiness report. — Readiness. Onboarding as diagnosis, not interrogation: after the scan, produce a verdict ("Vehicles strong; Property thin — missing EPC + gas safety; a passport expires in 7 months") instead of a pile. Generalise the existing property completeness-schedule engine (apps/profiles/schedules/house.py) across every life area. This is the single artifact that unifies onboarding, guidance, retention and the pack engine.
The conversational organiser ("Hey Maud"). — Readiness. Turn the static context document into a short, adaptive, scan-grounded conversation per life area — ground in what we found → establish the type → map the obligations that type implies → diagnose → act → keep live. The reusable pattern behind the readiness report; Maud's voice becomes the product.
The proactive layer: reminders + a household maintenance calendar. — Readiness. The view side has landed: the renewals engine + /renewals/ calendar (🔗 #173) computes what's due from document expiry/recurrence dates and DVLA MOT/tax facts, with dismiss/snooze/undo curation (🔗 #175) and the dashboard/house-page surfaces (🔗 #174). What remains is delivery — 🔗 #176, the digest email that makes it a promise rather than a view — deliberately deferred until the computed dates have proven trustworthy in real use. Strictly inside the life-admin frame, no spend optimisation.
Email-as-record. — Readiness. Lots of important things have no attachment — they are the email (ski pass, gym membership, licence keys, booking refs). Make the email body itself a first-class filed, structured record: snapshot it, extract the facts, file it, and put its expiry into the proactive layer. Distinctive and on-frame — a generalist shows you the email; Maud turns it into a durable record.
Preparedness intelligence engine. — Preparedness intelligence. Beyond junk-suppression: learn, across households, what good preparation looks like for each situation, and continuously move each household toward sale-ready / claim-ready / executor-ready. The only compounding tech edge — and a helpful one (better product, not a harder exit). Gated on the DPIA above; personal-by-default.
The pack engine. — Distribution. Sale / probate / mortgage / claim packs, assembled from the readiness data at the moment of need. Framed as retention and payoff, not acquisition (people don't prepare in advance) — and as the integration hook for the distribution routes below. The June 2026 homebuying reforms sharpen the sale pack specifically: the statutory "sales pack" at listing is the floor (thin, and destined to be commoditised compliance tooling), and Maud's pack is the floor plus the lived-in dossier — service history, tradespeople, how-things-work — that only an accumulated journal can produce. See the Vision's homebuying-reforms section for the full argument.
Sales-pack import (the buyer side). — Distribution. The reforms mean every transaction in England & Wales will produce a structured digital pack that the buyer receives. Importing it into Maud pre-populates the new household's journal at the just-moved-in moment — the statutory artefact as an onboarding seed. Unscoped; watch the emerging logbook / property-data standards and shape both this import and the pack engine's export against them.
Institutional distribution. — Distribution. Deliver the same readiness product three ways: embedded with adjacent professionals (conveyancers, brokers, insurers, will-writers); white-labelled by larger players; and — upside, not the plan — as a civic/public service. Where a durable moat actually forms: UK relationships, not UK knowledge, are the part that can't be copied quickly. Clean data export (see Vision) is a precondition, not a risk. The homebuying reforms hand this a forcing function: estate agents acquire an obligation they're structurally unequipped for — extracting condition documents, leasehold costs and certificates from sellers at listing — which is a document-collection-from-households problem, i.e. ours. "We make your sellers sales-pack-ready" is a concrete, dated pitch (code of practice late 2026, legislation later this Parliament).

Open questions and investigations¶

Decisions and spikes — not committed work.

Should users be able to add their own document types and categories? Under what guardrails — prevent fragmentation while letting a household add "school uniform receipts" if they want? More concrete now the taxonomy file has landed.
Does the property wizard work on the free tier? Open product question — decide before launching tiers.
How does Vercel + Neon compare to Fly.io on cost at projected Phase 1 load? Useful before locking in hosting longer-term.
Model the Claude API cost per active user per month at realistic scan + classification volumes. Feeds the pricing-tiers item.
Streaming-findings UX experiment. Today the scan runs in the background and findings appear at the end. Alternative: stream findings as the AI finishes each one. Affects perceived speed and back-end architecture — worth prototyping.
Do we need OCR fallback? Claude vision handles most things, but the spike sample will tell us whether there's a long tail needing Google Document AI or AWS Textract.
Respond to the MHCLG home buying and selling consultation. A working UK product with a live readiness engine is exactly who they want to hear from — and a response gets us on the radar of the department and the industry groups shaping the sales-pack contents. Time-boxed; check the consultation deadline.
Gap-map the consulted sales-pack contents onto the house schedule. Mostly overlap already (title, EPC, gas safety, FENSA, leasehold docs); the gaps become new schedule slots and the "needed to sell" tier becomes "statutory sales pack" when the shape firms up.
Track the property-logbook standards ecosystem (Residential Logbook Association, property-data trust framework). Cheap to watch, and the pack engine's output format should be theirs, not ours.

Housekeeping note: for manual testing we create sandbox-<name> users and reset with the wipe_household command between runs — captured here so the practice isn't lost.

Editing this page¶

This page lives at maud/docs-site/docs/roadmap.md. Edit it like any other docs page — PR + deploy lands it on docs.heymaud.com. The Cloudflare Access gate keeps it behind your email allowlist.

Keep it fresh: when something ships, delete it here and record it in status.md + maud/CHANGELOG.md — don't leave struck-through items on the page. When a Later or vision-track item matures into something you'd hand to a contributor, open a GitHub issue (plain-English: what / why / example / what we'd build, technical notes at the bottom), link it back here, and move it up to Next or Now.