Atamatax is tax software and a fulfillment workflow for Americans living abroad. A free diagnostic maps the situation — FBAR, Form 8938, PFIC funds and Form 8621, Streamlined catch-up — to the forms it triggers and the route out; a portfolio scan screens every holding with its reasoning shown; then the case moves into a scoped, fixed-price package: self-serve preparation, an export for the user’s own accountant, a document-based concierge preparation, or a Streamlined catch-up scope. Every case is checked by a person before release; where a professional review is engaged, it is recorded and stamped with the reviewer’s name and licence.
01 / 06
Problem
Context
A US citizen remains taxable in the United States wherever they live. Their obligations are fragmented: FATCA, FBAR, the PFIC rules on non-US funds, Form 8621 per fund, and catch-up procedures for those who never filed. These obligations hide inside ordinary products — a UCITS ETF bought through a Swiss broker, a pension fund, a savings account.
The existing market is binary: a specialised accountant at several thousand dollars, or nothing. Atamatax sits between the two — an engine that reads the situation and explains it, then a workflow that prepares the case, with an operational and professional layer where the route requires it.
Problem
An expat’s question is not “what is my tax” but “which forms does my situation trigger, and by which route do I get out of it”. Answering means crossing heterogeneous facts — status, country of residence, filing history, accounts, positions — with rules that each have thresholds, exceptions and zones of uncertainty.
The product difficulty is making that uncertainty honest: saying “likely PFIC, medium confidence, here is the assumption”, rather than a verdict the software cannot guarantee — and saying clearly, at every step, what was computed by software and what was reviewed by a person.
02 / 06
Constraints
- Liability boundary: the software prepares and makes the work verifiable, it never replaces a licensed professional — every package states where its responsibility ends.
- Intrinsic uncertainty: PFIC status can depend on facts the user does not have (election history, the issuer’s annual information) — the engine carries confidence and assumptions, not verdicts.
- Rules that change: a past result must stay reproducible after a rule changes — versioned rules, traced conclusions.
- Sensitive documents: encrypted uploads into the case workspace, never email attachments; card details never touch the application.
What is difficult
Making the uncertain honest. A fund may be “likely PFIC” with medium confidence because the domicile is known but the issuer’s annual facts are not. The product has to say that without discouraging, and never let it read as a legal determination.
Keeping the boundary between software and professional responsibility visible at every step: in the package comparison, in the report, in the case’s review status. A self-serve package says “no human review — software checks only”; a Streamlined scope says the reviewer’s identity and role are confirmed before engagement.
03 / 06
System
The product as a system
- Trigger
- Tax Situation Engine
- Recommendation
- Package
Product strategy
The product starts from what happened, not from a form: “I am behind”, “my bank asked for my US tax details”, “I have foreign investments”, “I own part of a foreign company”, “I am considering giving up citizenship”. Nine entry points lead to the same engine, and a tax professional has their own entry with a sample case and workpaper.
The result is visible before payment: the diagnostic, the scope and the on-screen summary are free, with a sample report readable before entering anything — the engine’s real output on a worked example, figures mapped to IRS forms and lines, assumptions shown. It removes the main objection to tax software: “what if it does not apply to me”.
User journey
Seven steps from “am I compliant?” to the final package. The free diagnostic creates the case and maps the facts to forms; the case workspace lists the documents needed and receives uploads over an encrypted connection, never as email attachments; the analysis screens holdings and checks thresholds; a written scope and a fixed price are proposed — no hourly billing, atypical cases get a fixed quote.
Payment goes through Stripe and the case moves to preparation only after confirmation. Forms are prepared from confirmed data, every assumption logged; anything missing is asked for in the workspace and by email. Every case is checked by a person before release — completeness, unresolved assumptions, engine warnings — and the final package is downloaded from the secure workspace, with filing instructions.
Screens


04 / 06
Architecture
From input to fulfillment — every stage, its layer, what happens there.
- Entry by situationClient
“I have never filed”, “my bank asked for a W-9”, “I hold foreign funds” — nine entry points, one free diagnostic, no account.
- Normalised tax factsDomain
US status, residence country, filing history, income, accounts, holdings by ISIN — never by ticker alone.
- Deterministic rulesDomain
FBAR and Form 8938 thresholds, fund domicile and PFIC status, catch-up procedures — versioned, every conclusion cites a published rule.
- Obligation graphDomain
Forms triggered per year, with confidence and assumptions; low-confidence classifications are flagged for human validation.
- Route and priceDomain
Self-serve, accountant export, concierge or Streamlined — a written scope, a fixed price, atypical cases as a fixed quote.
- Stripe checkoutIntegrations
Card details go straight to Stripe; the case moves to preparation only after payment is confirmed.
- Case workspaceOperations
Personalised document checklist, encrypted uploads, per-document review status, follow-ups for missing information.
- Review before releaseOperations
An operational check by a person on every case; a professional review recorded separately when one is engaged.
- Final packageClient
Returns by year, PFIC statements, FBAR instructions, filing instructions — what the software computed is stated, so the user or their CPA can verify it.
System architecture
The core is a tax situation engine: normalised facts go in, an obligation graph and a route come out. Every classification names its source, its confidence level and what remains to be confirmed — QEF election history, whether the issuer’s annual information is available. Rules live in the engine, versioned, with a trace: a scan’s output is reproducible and explainable.
Around the engine, an operational workflow: the case, its documents, its review states and its follow-ups. Anything that needs a judgment call — the non-willfulness certified for Streamlined, an unusual treaty position — is routed to review instead of being guessed; a low-confidence classification is marked for human validation, never silently accepted.
Next.js, TypeScript, Postgres, Stripe, Vercel. Card details go straight to Stripe; stored return data is scoped to the account.
Hard engineering decisions
- Identify a fund by ISIN, not by ticker: the same ticker exists on several exchanges with different domiciles, and the legal domicile — read from the fund record — decides PFIC status. The engine assumes no election on a holding until it is confirmed.
- Make the result a trace, not a boolean: the output cites the published rule, the confidence and the assumption — the condition for changing a rule without breaking past results, and for a CPA to verify what the software computed.
- Separate software checks from human review explicitly: nothing is stamped “reviewed” unless a review actually happened; the professional review, when engaged, is recorded separately with the reviewer’s name and licence.
- Hold a fixed package scope in a domain where every situation adds an exception: each package states which forms and lines it prepares, how many Forms 8621, and what stays with the user or the professional — official pre-filled PDFs where integrated, worksheets mapped line by line elsewhere.
Domain model
- Case
- Created by the diagnostic; carries the facts, the route, payments, documents and reviews.
- Holding
- Identified by ISIN; legal domicile read from the fund record; PFIC classification with a confidence level; no election assumed.
- Obligation
- One form per year and per threshold — FBAR, 8938, 8621, 1040 and schedules — with its source rule.
- Package
- Explicit scope: forms and lines prepared, number of Forms 8621, what stays with the user or the professional.
- Document
- Personalised checklist item, review status, replacement of a rejected file.
- Review
- Operational (every case) or professional (when engaged) — reviewer identity and scope recorded.
05 / 06
Business result
A market that was binary — a specialised accountant at several thousand dollars, or nothing — now has four published fixed-price routes, from a $199 accountant export to a Streamlined catch-up scope, fed by a free diagnostic that is also the acquisition channel.
Current status
In production, payments live. Per-tax-year pricing published on atamatax.com (September 2026): self-serve $299 to $799, accountant export $199, concierge from $999, Streamlined catch-up $1,590 to $2,990 and above.
Business and operating model
The result is free; you pay to prepare. Four routes cover four situations: prepare and file yourself (the software computes, the user checks and files — e-file and sign-off by an EA or CPA excluded), an export for the accountant who signs the return, a concierge preparation from the documents sent in, and three fixed Streamlined catch-up scopes where preparation and filing responsibility, and the adviser’s role, are confirmed before engagement. The software prepares and makes the work verifiable; it does not replace a licensed professional, and every package states where its responsibility ends.
What shipped
- Tax Situation Engine: US status, residence country, filing history, accounts and holdings map to the forms and the route back
- PFIC Scan: foreign ETFs, funds and local products screened per holding, with the reasoning and the assumptions shown
- Catch-up routing into fixed Streamlined scopes; paid diagnostic, filing packages and an accountant hand-off, all priced before checkout
- Search-driven acquisition: country pages, treaty pages, broker and financial-product trigger pages, free tools
Acquisition architecture
Atamatax is a product found through search: pages per country of residence, per tax treaty, per broker and per triggering financial product, situation guides, free tools (check a ticker or ISIN in seconds), and a package comparison. Every page answers one precise question and leads to the diagnostic.
The free diagnostic is both the acquisition tool and the first step of the product: there is no contact form between the search and the result.
06 / 06
Lessons
- 01Model identity at the level the rule reads it: a fund is an ISIN with a legal domicile, not a ticker — the wrong key makes every downstream conclusion wrong.
- 02A result is a trace, not a boolean: citing the rule, the confidence and the assumption lets a rule change without breaking past cases, and lets a CPA verify the software.
- 03Put the free result before the payment: the diagnostic is both the acquisition tool and the first step of the product, which removes the “what if it does not apply to me” objection.
- 04Say who checked what: software checks and human review are two distinct states, and nothing is marked “reviewed” unless a review happened.
What I owned
- Regulatory research and the obligation model
- Product and journey — entry by situation, result before payment
- Tax situation engine and PFIC scan
- Data model, case workspace and document workflow
- Stripe payments and fixed-price packages
- Search-driven acquisition architecture
Capabilities proven here
The matching service
- SaaS developer — A complete SaaS product — auth, roles, data, payments, admin, deployment — built for its first real customer.
- Custom web application — Internal tools, client portals, eligibility engines, back offices — the software that replaces the spreadsheet and the emails.
- SaaS v1 development — The first version that survives its first customer — what it must contain, and what can wait.
Related reading
- Prototype or v1: the difference that decides your launchA prototype impresses in a demo. A v1 survives the first real customer. Confusing them is expensive.Building products5 minRead →
- When should a SaaS use AI? And when it absolutely should notI have built three decision engines in production — tax, air passenger law, scoring — and none of them uses a language model to decide. Here is the rule I apply, the cases where AI belongs, and why RAG is often the wrong answer.AI product engineering8 minRead →
- Next.js architecture for a production SaaS: the decisions I make on every productWhat separates a Next.js project that holds from one that gets rewritten after a year comes down to about ten decisions. Here are mine, as applied on Atamatax, Horvera, Wabiro, SponsorsMetrics — and on this site.Next.js & full-stack9 minRead →
Notes de terrain issues de ce système
Next system
Horvera