Most trackers in this category store your position. This one refuses to.

The constraint

Portfolio accounting has a property that makes the obvious design wrong: every number a user cares about is a consequence of something else.

Your position in a stock is a consequence of your trades. Your average cost is a consequence of those trades and their fees. Your cash balance is a consequence of deposits, withdrawals, dividends and the cash legs of every trade. Your realised gain is a consequence of the order the sells happened in.

Store any of those, and you have created a second source of truth that can drift from the first. Drift in a portfolio tracker is not cosmetic. A user who corrects a trade they entered wrong three months ago, and whose average cost does not move to match, now has a tax report that is quietly false.

The decision

Only facts are stored. Everything else is computed on read.

There are two kinds of fact — capital events (deposit, withdrawal, dividend) and trade events (a signed quantity, plus fees and taxes). The log is append-only: a mistake is corrected by recording a new event, never by editing or deleting an old one. Positions, cash, weighted average cost, realised and unrealised P&L and total equity are all derived by replaying that log.

The invariants are stated up front and enforced in tests rather than left implicit:

• You cannot sell more than you hold.
• Cash must reconcile exactly.
• No number appears anywhere in the UI without a traceable origin in the event log.

Two things fall out of this design almost for free, which is usually the sign it was the right one:

• Time travel. “What did my portfolio look like last March?” is not a feature requiring stored snapshots; it is the same computation with the event stream filtered by date.
• Inferred reinvestment. How much fresh money you put in, versus how much came from trading gains, is answerable from the log alone. Nothing has to be tagged at entry time — which matters, because users do not reliably tag anything.

What it cost

Recompute latency. Every page view replays the ledger. That is the bill for the guarantee, and it is paid with caching — which then creates the actual hard problem, because a cache over derived data has to be invalidated by everything that could change the derivation.

Rather than track which keys depend on which inputs, every cache key carries two version counters: one for the user, one for the market.

portfolio_summary_u{userId}_v{userVersion}_m{marketVersion}

Writing an event increments that user’s version. A price update increments the global market version. Either one invalidates every dependent entry — summary, tax report, chart data, asset list, sentiment — atomically, with a single increment and no key enumeration. Stale entries are never deleted; they simply become unreachable and expire on their own.

The property that makes it safe is that it is impossible to forget to invalidate something. Adding a new derived value means adding a new cache key in the same namespace, and it inherits correct invalidation by construction. Key-by-key busting has the opposite property: every new derived value is a new opportunity to miss one.

The rest of the product

• A market data pipeline that ingests and normalises exchange prices on a schedule, with retry and freshness handling, feeding both the portfolio valuations and a public price-history record.
• Capital gains reporting for the local regime, including loss carry-forward, exportable at year end.
• Bilingual English and French with translated URL slugs, hreflang alternates and a generated bilingual sitemap — the marketing and public market pages are server-rendered for crawlability while the application itself is a single-page app behind authentication.
• Authentication with optional TOTP two-factor, enforced email verification, and per-model ownership policies.
• A zero-signup demo seeded with plausible history against real prices, so the product can be evaluated without handing over a trade ledger. It deletes itself after 48 hours.

Nissab-Zakat answers that question in 11 languages and roughly 150 currencies, for free, with no account. It is a public-interest reference rather than a business — which is precisely what made the interesting design decision available.

The constraint

A site like this has two audiences, and only one of them was ever designed for.

The first is a person with a browser. The second is a machine: a search crawler, an LLM answering a question about zakat, or an agent that needs today’s threshold as a number it can compute with. For that second audience the usual answer is “scrape the HTML and hope” — brittle for them, and lossy for us, because a scraped page carries none of the provenance that makes a religious finance figure trustworthy.

Since there was no commercial reason to hoard the data, we could design for the machine audience directly.

The decision

Treat machine consumers as a first-class surface with its own contract, and make that surface discoverable rather than documented in a PDF nobody finds.

Concretely, the site ships:

• An MCP server. Stateless JSON-RPC 2.0 over Streamable HTTP, negotiating several protocol revisions, exposing a tool that returns the current thresholds in any ISO-4217 currency. An agent can ask for today’s nisab in Malaysian ringgit and get a typed answer with its provenance, rather than a paragraph of HTML.
• /.well-known/api-catalog — an RFC 9727 linkset, so a machine can find the API without being told where it is.
• /.well-known/mcp.json — a server card, so an MCP client can discover and connect on its own.
• Link headers on responses advertising the sitemap, the catalogue and llms.txt, for consumers that never read the HTML body at all.
• llms.txt and llms-full.txt, and a robots.txt that names the major AI crawlers explicitly and declares content signals rather than leaving intent ambiguous.
• A public JSON API and an embeddable widget, so a mosque or charity site can show the live threshold without rebuilding any of this.

What sits underneath

None of that is worth anything if the numbers are wrong or stale, so the data path is deliberately conservative:

• Contracts and adapters. Metals pricing, FX and geo-to-currency each sit behind an interface with a swappable implementation and typed DTOs. Providers in this space change terms and go dark; none of them are allowed to leak into the domain.
• Cached with an explicit refresh path, on a schedule — FX twice daily, metals daily.
• Freshness is monitored, not assumed. A daily check alerts when data is older than it should be, and the service raises rather than silently rendering a zero. A zakat threshold that is quietly wrong is worse than one that is honestly unavailable.
• Bounded retention. Price history is pruned on a rolling window rather than growing without limit.

SEO and localisation as engineering

The other half of the work is being findable by the human audience, which for a reference site means being genuinely multilingual rather than machine-translated:

• 11 locales, with Accept-Language q-weight negotiation and a Vary header so caching stays correct per language.
• Programmatic landing pages for the common currency queries, in every locale, each with structured data rather than a thin templated page.
• Server-rendered throughout — Livewire and Blade, no JavaScript framework. For a page whose job is to show one number quickly on a slow connection, that is the right trade.
• Cache headers with stale-while-revalidate, a dependency-free inline SVG trend chart, and a service worker with an offline page.

What it cost

The agent-native surface is genuinely more work than a REST endpoint and a link to it: several well-known documents to keep correct, a protocol to track as it revises, and a test suite that has to cover discovery and version negotiation rather than just responses. The specifications are also young enough that some of this will need revisiting.

It is also, so far, a bet. The audience of agents that discover a service this way is real but early. We took it because the marginal cost on a project with no commercial pressure was low, and because the alternative — being scraped badly — was the default outcome anyway.

That is the product in a sentence. The engineering interest is almost entirely in what happens when a ticket changes status.

The constraint

A status change can fan out to email and WhatsApp. Both cost money, both are metered per plan, and both are delivered by a queue worker that can be retried at any time — after a timeout, after a deploy, after a crash mid-send.

That combination produces three failure modes that all matter commercially:

• Double-send. The customer gets the same “your repair is ready” message twice. Cheap to cause, expensive in trust.
• Phantom quota burn. A send is counted against the shop’s allowance but never actually goes out, or goes out twice and is counted once.
• Lost delivery on rollback. The job is dispatched, the surrounding transaction then rolls back, and the worker picks up a job referring to a status that no longer exists.

The naive version — dispatch a job from a model observer and decrement a counter inside the job — fails all three.

The decision

Delivery is modelled as a row, not an action.

When a ticket status changes, a NotificationDelivery record is created inside the same database transaction as the status change itself, with a unique constraint on the pair of (ticket status, channel). Creating the row is the claim to send. Two concurrent attempts race for the same unique key; the loser catches the constraint violation, re-reads the winning row, and does nothing.

The quota is reserved at the same moment, against the same transaction — before anything is dispatched. If the reservation fails because the shop is out of allowance, the whole thing rolls back together and no delivery row exists to be retried.

Only then is the send job queued, and it is queued afterCommit. A rollback therefore cannot leave a job pointing at a status that was never persisted.

Failures are then split into two kinds, explicitly, as distinct exception types:

• Transient — a timeout, a 5xx from the provider, a rate limit. Worth retrying; the delivery row stays pending and the reserved quota stays reserved.
• Terminal — an invalid phone number, a template rejected by the provider, a hard 4xx. Not worth retrying; the row is marked failed and the reservation is released.

Collapsing these two into a generic “it failed, retry it” is how you get a queue that spends all night retrying a phone number that will never be valid, while the shop’s allowance stays locked up.

What it cost

This is more machinery than “send an email when the status changes”, and it is worth being honest about the bill:

• An extra table and a unique index on the hot path of the most common write in the product.
• A reconciliation command. Rows can still get stuck — a worker dies between reserving and sending, and no exception is ever thrown to classify. A scheduled job sweeps for deliveries left pending beyond a threshold and re-queues or fails them. Idempotency is what makes that safe to run.
• Harder tests. The interesting cases are concurrent ones, so the suite includes tests that hammer the quota manager from parallel processes rather than asserting on a single happy path.

The payoff is that the difficult questions have boring answers. Can a customer get two messages? No, the unique constraint prevents it. Can a shop be billed for a message that never sent? No, terminal failures release the reservation. What happens if we deploy mid-send? The job is retried and finds the work already claimed.

The rest of the surface

The notification pipeline is the part worth writing about, but the product is a full SaaS and the supporting work is most of the code:

• Tenancy as a trait plus policies, with owner, staff, customer and platform-admin roles, and per-staff ability flags rather than coarse role checks.
• Quota and metering across tickets, workflows, clients, staff and each message channel, with monthly allowances, hard caps, and purchasable extra credits.
• Subscription lifecycle driven by webhook listeners — payment success and failure, refunds, entitlement sync on login — with in-app banners when a payment fails rather than a silent downgrade.
• Customer-facing surface hardening: rate-limited public routes, signed URLs for photos, optional PIN gates on tracking pages, and a dedicated test group for public endpoint protection.
• Trilingual, including right-to-left Arabic — around a thousand translation keys per locale across the app, plus locale-prefixed marketing routes.
• An audit log that captures tenant and user context, changed values, IP and user agent, surfaced in-app rather than left in a table nobody reads.