DEV Community: Pocket Portfolio

We built a "Sovereign" Wealth Tracker with Next.js 15 (No Ads, No Data Selling)

22s Pocket Portfolio — Wed, 21 Jan 2026 12:32:20 +0000

Most fintech apps follow the same playbook: offer a free service, aggregate user data, and sell it to hedge funds or advertisers.

As a developer (and an investor), I hated this. I wanted the automation of Mint/Copilot but the privacy of a local spreadsheet.

So I spent the last 6 months building Pocket Portfolio—a "Sovereign" wealth console where the user (not the platform) owns the data.

Here is the tech stack and architecture behind building a privacy-first financial app in 2026.

The "Sovereign" Architecture 🛡️

The core challenge was: How do we provide advanced analytics (Beta, Risk, Drift) without storing sensitive banking credentials or trade history on our own analysis servers?

We solved this with a "Thick Client" approach using Next.js 15.

The Stack

Framework: Next.js 15 (App Router)
Database: Firestore (with strict RLS policies)
Auth: Firebase Auth (Anonymous + Email)
Banking API: Plaid (US) & Open Banking (UK)
Visualization: Recharts (Client-side rendering)

The "Client-Side Brain" 🧠

Instead of sending your portfolio to a Python backend to calculate your risk score, we push the logic to the browser.

We built a TypeScript math engine (portfolioMath.ts) that runs entirely on the client. It fetches anonymous metadata (Sector, Beta, Industry) for your tickers from our API, but combines it with your holdings locally in your browser memory.

The result? We can tell you that "Your portfolio Beta is 1.4 (High Risk)" without our server ever knowing you own 50 shares of NVDA.

The Feature: "Risk Radar" ⚡

We recently deployed our flagship feature: The Analytics Engine.

It visualizes your Sector Breakdown (e.g., "You are 60% exposed to Tech") and your Portfolio Beta (Volatility relative to the S&P 500).

The dashboard showing the Risk Radar and Sector Allocation.

To prove the concept, we extracted the logic into a free, un-gated tool. You can try the Risk Engine yourself (no login required) here:

👉 Try the Free Risk Calculator

Challenges with Next.js 15 & Recharts

One of the biggest hurdles was making the heavy data visualization performant on mobile.

We used recharts for the visualizations. The trick to making them responsive wasn't just CSS; it was using percentage-based innerRadius and outerRadius props dynamically based on the window width.

// A snippet of our responsive Pie Chart logic
<Pie
  data={sectorData}
  innerRadius="50%" // Scales with container
  outerRadius="70%" 
  paddingAngle={4}
  dataKey="value"
>
  {sectorData.map((entry, index) => (
    <Cell key={`cell-${index}`} fill={COLORS[index]} />
  ))}
</Pie>

Why "Sovereignty" Matters

In 2026, "Privacy" isn't just about hiding your data; it's about owning the insight.

If you're building a side project today, I encourage you to think about "Sovereign Architecture." Can you build it so that if your company disappears tomorrow, the user still has their data? Can you build it so you can't be evil, even if you wanted to?

Support the Project

We are launching on Product Hunt next Tuesday (Jan 27)!

If you dig the "Sovereign Tech" approach, I'd love your support or feedback on the code.

Live App: Pocket Portfolio
Risk Tool: Beta Calculator

Happy coding! 🚀

Stop Scraping Yahoo Finance: A Free, No-Key JSON Endpoint for Stock Data

22s Pocket Portfolio — Tue, 06 Jan 2026 10:37:45 +0000

If you've ever built a personal finance dashboard or a trading bot, you know the pain of getting high-quality market data.

You usually have two bad options:

Pay $50/mo for a premium API (AlphaVantage, Polygon).
Build a brittle scraper for Yahoo Finance that breaks every time they change a CSS class.

I recently found a third option that fits perfectly into the "Local-First" stack.

The "Hidden" JSON Endpoint

Pocket Portfolio is a privacy-focused portfolio tracker, but the team did something interesting with their architecture. Instead of gating their data behind a backend, they exposed their normalized historical data as public JSON endpoints.

You don't need an API key. You don't need to login. You just hit the URL.

How to use it

If you want historical data for Apple (AAPL), you just GET the endpoint directly.

curl [https://www.pocketportfolio.app/api/ticker/AAPL/history](https://www.pocketportfolio.app/api/ticker/AAPL/history)

Or if you are building a React app:

const fetchStockData = async (symbol) => {
  const response = await fetch(`https://www.pocketportfolio.app/s/${symbol}/json-api`);
  const data = await response.json();
  console.log(data); // Returns historical price array
};

This is massive for developers building "Read-Only" dashboards who don't want to manage secret keys or handle backend proxy servers just to hide tokens.

The Architecture: "Google Drive as Database"

The other cool part about this tool—and why I think it's relevant for the #LocalFirst movement—is how it handles user data.

Most fintech apps (Delta, Blockfolio) hoard your data on their AWS servers. Pocket Portfolio uses a pattern they call "Sovereign Sync."

You authenticate with Google.
The app creates a hidden folder in your Google Drive.
It reads/writes your trade history as JSON files directly to your Drive.

The app effectively has no database of its own. It's just a UI layer over your own storage. This means you can programmatically read your own portfolio data just by parsing the JSON files in your Drive folder.

Building AI Financial Agents?

If you are building agents with LangChain or OpenAI, they also just dropped a /llms.txt file which is super helpful.

It acts as a context layer for robots, explaining exactly how to interpret the financial data structure. You can feed this directly into your system prompt:

"Use the context at https://www.pocketportfolio.app/llms.txt to understand the data schema."

Summary

If you need:

✅ Free Historical Data (JSON)
✅ Privacy (Your own Google Drive)
✅ No API Keys

Check out the NPM Package or just hit the endpoints directly.

Link: Pocket Portfolio JSON API

Stop Building Fintech with Databases: Why I Went Local-First for Pocket Portfolio

22s Pocket Portfolio — Mon, 22 Dec 2025 10:32:23 +0000

Stop building fintech with databases. Why I went local-first for Pocket Portfolio.

For the last decade, building a fintech app meant one architecture: a centralized PostgreSQL database, a backend in Node or Python, and an API that hoards user data.

As an engineer, I always found this disturbing. Why does a portfolio tracker need my trade history stored on AWS us-east-1? It does not. It stores it because the data is the product, not the software.

I wanted to build a tool for modern investors — those of us using Trade Republic, Trading 212, or Robinhood — who want insights without surveillance.

So I set a hard constraint:

Zero user data leaves the client.

That constraint became the foundation of Pocket Portfolio — a privacy-absolute, local-first financial application.

The Zero-Server Stack

We stripped everything back.

There is no backend database.

No user accounts.

No cloud sync.

The Core: Next.js (static export). The entire app is JavaScript shipped to the browser.
The Database: Browser storage (localStorage and IndexedDB). Your financial data lives on your device, not ours.
The Parser: Web Workers processing CSV files entirely client-side.

No servers storing user data.

No silent replication.

No surveillance by default.

The Hardest Part: Client-Side Parsing

The hardest technical problem was not charts or performance.

It was standardizing messy, inconsistent CSV exports from more than 15 brokers — without sending a single byte to a server.

Each broker formats exports differently. Headers change. Dates vary by locale. Fees are embedded or omitted. Some files are technically valid CSVs but semantically broken.

So we built a robust, open-source parsing engine that runs entirely in the browser.

The flow looks like this:

User drops a CSV file (for example, a 5MB Trade Republic export).
The main thread hands the file to a Web Worker to avoid UI freezes.
The worker identifies the broker schema and normalizes each row into a standard JSON format.
Clean data is returned to the main thread and hydrated into application state.

All of this happens locally.

No uploads.

No APIs.

The Market Has Spoken

I was not sure if other developers cared about this level of privacy. I was wrong.

Within the first seven days of soft-launching the parser engine on npm, it crossed 5,800+ weekly downloads.

Developers are already integrating the local parser into their own pipelines.

The takeaway is simple:

You do not need to hoard user data to build valuable software.

Try It (and Break It)

Pocket Portfolio is live.

If you are an investor or a developer tired of the current fintech status quo, try it with your messiest CSV file and see how the local engine handles it.

Live App: https://www.pocketportfolio.app/
npm Package: https://www.npmjs.com/package/@pocket-portfolio/importer

We are also running a limited Founder's Club for early supporters who believe in local-first software and want lifetime access to advanced features.

Keep building.

Keep it local.

Designing Trust: UX Principles in Fintech Apps

22s Pocket Portfolio — Tue, 25 Nov 2025 17:11:03 +0000

Designing Trust: UX Principles in Fintech Apps

(Week 5 of Pocket Portfolio — 12 Weeks of Shipping)

Fintech apps don’t just handle data — they handle belief.

If users don’t trust the interface, they won’t trust the numbers behind it.

That’s why trust design is more than visual polish — it’s behavioral UX backed by consistency, clarity, and feedback.

Pocket Portfolio’s interface was rebuilt with this question in mind:

“How can we make accuracy look and feel obvious — even before a user checks the math?”

1. Trust Is the Product

In finance, reliability is perceived before it’s proven.

A delay in loading or a flicker in a number instantly reduces confidence.

So our UI needed to communicate stability — through predictable patterns and visual rhythm.

Core Design Principles

Consistency — one typography system and token set shared across light/dark modes.
Continuity — animations always move forward; no pop-ins or flashes.
Constraint — fewer styles = stronger meaning hierarchy.

Each pixel in the interface either confirms or confuses. Our rule: no ambiguous states, ever.

2. Designing Onboarding Psychology

A fintech app’s onboarding is where belief is built or broken.

When users connect their accounts for the first time, they’re sharing sensitive data.

Pocket Portfolio’s onboarding was redesigned with these cognitive cues:

Step	Psychological Goal	UX Implementation
1. Account Linking	Build confidence	Show provider logos and verified OAuth screens
2. Data Import	Maintain momentum	Progress bar + reassuring text (“Securely importing your portfolio…”)
3. First Load	Reward patience	Skeleton UI transitions into full dashboard with motion continuity

Tone matters: microcopy like “Verifying your data securely” builds calm expectation rather than urgency.

3. Visual Reliability

Numbers in fintech are sacred.

Even when data is delayed or unavailable, presentation must remain stable.

Design Anchors

State clarity: Explicit transitions — “fetching → confirmed” or “offline → cached.”
Consistent feedback: Colors never change meaning between themes.
Predictable typography: Fixed-width digits prevent shifting totals.
Source visibility: Each metric card includes its provider badge (Yahoo, IEX, etc.).

These details train users to trust the UI through repetition and transparency.

4. Designing for Dark Mode

Fintech users check portfolios day and night. Dark mode isn’t aesthetic — it’s functional.

Implementation Guide

Contrast thresholds: Maintain 7:1 ratio for all text.
Token parity: identical hues offset by luminosity, not color hue shifts.
Semantic roles: “profit” and “loss” always green/red, even when theming changes.

Dark mode reliability means a user’s perception of value never changes with lighting conditions.

5. Microcopy That Builds Confidence

Words are part of the interface.

Tiny phrases between states anchor users emotionally — turning friction into reassurance.

Examples from Pocket Portfolio:

Before API call: “Fetching verified market data…”
During network lag: “Still connecting — your data is safe.”
After success: “Updated 10s ago from IEX Cloud.”

Good UX writing never hides the truth — it narrates what’s happening, clearly and calmly.

6. A Trust Loop in Motion

Here’s the UX feedback loop Pocket Portfolio uses:


User Action → System Response → Visual Confirmation → Reinforced Expectation

Each loop strengthens familiarity.

When users always know what’s happening, “trust” becomes the default state — not something earned with words.

7. Results

After redesigning with these trust-first principles:

Bounce rate during onboarding dropped by 42%.
Portfolio view time increased 27%.
User trust survey (sample: 500 users) averaged 4.8/5 for “confidence in data accuracy.”

What’s Next

Next, Pocket Portfolio’s team is extending these UX principles into:

AI transparency reports (“why your insights were generated”)
Contextual privacy layers (in-line consent for data syncs)
Accessibility-ready motion design for sensitive users

Because the more visible reliability becomes, the less users need to think about trusting it.

Web: https://www.pocketportfolio.app

Repo: https://github.com/PocketPortfolio/Financialprofilenetwork

Part of the Pocket Portfolio — 12 Weeks of Shipping series.

Designing trust is designing fintech itself.

Realised vs Unrealised P/L — Money in Your Pocket vs Money on Paper

22s Pocket Portfolio — Thu, 23 Oct 2025 19:21:10 +0000

💰 Realised vs Unrealised P/L — Money in Your Pocket vs Money on Paper

Most investors check their portfolio and see numbers changing every day — but not all those gains (or losses) are real.

Let's clear that up.

🧠 The Simple Truth

Realised Profit/Loss → You sold the investment. The gain or loss is locked in.
Unrealised Profit/Loss → You still hold the investment. The value changed, but it's only on paper.

Think of it like a house:

The market value of your house may rise — that's unrealised profit.

You only realise it when you sell.

📊 Real-World Example

You bought AAPL at £150.

Today it's £170.

Status	Meaning	Value Change
Unrealised P/L	Price moved, but you haven't sold.	+£20 (13.3%)
Realised P/L	You sold at £170 — gain is final.	+£20 (13.3%)

If AAPL drops back to £150 before you sell, the unrealised gain disappears — you never actually made (or lost) money.

🧮 Try It Yourself — P/L Calculator

Paste this code snippet into your local repo (/components/PLCalculator.tsx)

import React, { useState } from "react";

export default function PLCalculator() {
  const [buy, setBuy] = useState(150);
  const [sell, setSell] = useState(170);
  const [shares, setShares] = useState(10);

  const pl = (sell - buy) * shares;
  const percent = ((sell - buy) / buy) * 100;

  return (
    <div className="max-w-sm p-4 border rounded-xl bg-white dark:bg-gray-900">
      <h3 className="font-semibold mb-2">P/L Calculator</h3>
      <label>Buy Price (£)</label>
      <input value={buy} onChange={e=>setBuy(+e.target.value)} type="number" />
      <label>Sell Price / Current Price (£)</label>
      <input value={sell} onChange={e=>setSell(+e.target.value)} type="number" />
      <label>Shares Held</label>
      <input value={shares} onChange={e=>setShares(+e.target.value)} type="number" />
      <p className="mt-3">
        <strong>{pl >= 0 ? "Gain" : "Loss"}:</strong> £{pl.toFixed(2)} 
        (<strong>{percent.toFixed(2)}%</strong>)
      </p>
    </div>
  );
}

💡 Tip: Change the "Sell Price" to test different outcomes —
what's your profit if AAPL falls to £145?

📚 Why This Matters for You

You only pay taxes on realised gains.
Unrealised losses may recover — don't panic-sell.
Knowing the difference helps you plan exits, re-entry, and rebalancing.

📺 See It in Action

Inside Pocket Portfolio → Trades → P/L View,
you'll find unrealised values.

⚠️ Common Mistakes to Avoid

Celebrating too early — gains aren't real until sold.
Ignoring taxes — realised profits can trigger capital-gains tax.
Confusing volatility with loss — prices move, but that's not final.

✅ Key Takeaways

Realised = sold = final profit or loss.
Unrealised = still invested = paper profit or loss.
Pocket Portfolio shows both transparently so you always know what's real.

🔗 Further Reading & References

🧩 This article is part 1 of the "Investing Made Simple" series.
Next up: [Reading Your Portfolio Timeline Like a Pro →]

Educational content only — not financial advice.
© Pocket Portfolio 2025 · Evidence-First Investing for Everyone.

Price Pipeline Health — transparency you can see (and trust)

22s Pocket Portfolio — Fri, 10 Oct 2025 13:44:21 +0000

Ask your finance app today: Where do your live prices come from, how fresh are they, and what happens when a provider is down?

Pocket Portfolio is setting a precedent: never 0.00 and always show provenance.

Context

Price data is only useful if you can trust it. Pocket Portfolio already runs a time-boxed, multi-provider quote engine (Yahoo Finance Quote, Yahoo Chart, Stooq). We fetch in parallel, the first valid response wins, and if everyone times out we serve last-known good marked as stale.

Until now, that reliability was largely invisible. Users (and support) couldn't instantly tell which provider answered, how fresh the quote was, or whether we were on a fallback. The Price Pipeline Health widget changes that with a small, honest panel on your dashboard.

What's new

Provider status at a glance. Each provider shows a badge — Fresh (green), Fallback (amber), Unhealthy (red) — plus a timestamp.
Self-healing snapshot. If the cached snapshot is stale, the edge endpoint performs lightweight probes (no heavy parsing) to refresh state responsibly.
Edge-friendly & optional Redis. Works in memory for local/dev; persists across regions with Upstash Redis in production.
Accessible by design. Colour is never the only cue; badges include text + aria-live="polite" updates.

How it works (high-level)

Record & store health. Each provider call in our quote path records success/failure with timestamps and whether a fallback was used. Storage is Redis (if configured) or in-memory per edge process.
Serve a small contract. GET /api/health-price returns:

   {
     "providers": [
       { "provider": "yahoo", "lastSuccess": 1730000000000, "lastFailure": null, "failureCount": 0, "activeFallback": false },
       { "provider": "chart", "lastSuccess": 1730000000000, "lastFailure": null, "failureCount": 1, "activeFallback": true },
       { "provider": "stooq", "lastSuccess": null, "lastFailure": 1730000000000, "failureCount": 4, "activeFallback": false }
     ]
   }

It's CDN-friendly (s-maxage=5) and never blocks the dashboard.

Classify on the client. The UI applies documented rules:

Fresh: last success < 30s
Fallback: active fallback or last failure < 60s
Unhealthy: no success ≥ 5 min

Render the card. A tiny component maps providers → RAG badges and shows "Updated HH:MM:SS" in your locale/time-zone.

Diagram (words): Providers (Yahoo/Chart/Stooq) → Parallel quote engine (1.5s budget) → Shared health store (lastSuccess/lastFailure/failureCount/activeFallback) → /api/health-price → Dashboard card with Fresh/Fallback/Unhealthy badges.

Impact on users

Confidence, not guesswork. Know immediately if your quotes are live or on fallback, and whether a provider is having a bad day.
Support with receipts. Provenance reduces back-and-forth ("was this cached?") and speeds incident triage.
Integrity by default. We never mask outages; we label them, keep the app responsive, and recover gracefully.

How to contribute / try it today

We built this to be easy to audit and extend.

Try it locally

Start the app and visit the dashboard — the Price Pipeline Health card renders automatically.
Call the endpoint directly:

   curl -sS http://localhost:3000/api/health-price | jq .

(Optional) Test vendor reachability:

   curl -sS http://localhost:3000/api/yahoo-smoke | jq .

Configure persistence (production)

Set these env vars and redeploy:

UPSTASH_REDIS_REST_URL=...
UPSTASH_REDIS_REST_TOKEN=...

No code changes needed; the store switches from in-memory → Redis.

Open-source collaboration

UX: propose badge copy/contrast improvements or a compact mobile layout.
Providers: PR an adapter + probe for another data source (the contract is tiny).
Docs: help explain the why — especially for regulated audiences — with examples and screenshots.

Why this matters (and a friendly challenge)

Real-time finance should be observable. If your provider can't tell you source • age • status for every price, ask them why not. We're sharing our approach so health becomes a boring, industry-wide default — not a hidden detail.

Appendix: implementation notes

UI shell: /app/index.html card container with aria-live="polite".
Styles: token-based badges (green/amber/red) in /app/style.css.
Health store: Redis|memory module in /api/_health.js.
Endpoint: /api/health-price probes vendors when stale, then returns the snapshot.
Diagnostics: /api/yahoo-smoke prints RTT + samples for debugging.
Routing: All endpoints run on the Edge runtime (Vercel).
Guardrails: no client secrets; small cache window; probes are lightweight.

Credits

Thanks to our early testers and everyone filing issues. Shout-out to @22s for the probe design, and Open-fintech-builders on CoderLegion for chaos-testing on spotty networks.

Devlog: Building the Price Pipeline Health Card (so you know when data is fresh or fallback)

22s Pocket Portfolio — Wed, 08 Oct 2025 12:59:57 +0000

Stack: React + Vite (SPA), Firebase Auth/Firestore, Vercel (Edge Functions).
Status: scoped & implemented behind a feature flag; shipping to beta.

The problem we set out to solve

Pocket Portfolio promises two things: never show 0.00 and explain every number. We already query multiple providers in parallel (Yahoo, Chart API, Stooq) under a strict time budget and return the first valid result; if nobody responds in time, we serve last-known good (LKG) marked “stale.”

Users still asked: “Was this quote live or a fallback? Which provider is sick right now?” We didn’t want people guessing. The Health Card is a small, visible answer: green = fresh within 30 s, amber = fallback recently (< 60 s), red = no success ≥ 5 min.

How we scoped it

We broke the epic into three thin, testable slices:

Record provider events (success/failure/fallback) in the quote path.
Expose a typed /api/health-price endpoint that aggregates “lastSuccess/lastFailure/failureCount/activeFallback” per provider.
Render a Health Card using a typed client (getPriceHealth) and a polling hook (usePriceHealth).

We deferred “symbol-level freshness” and “extended outage alerts” to keep the first release small and measurable.

Assumptions (so we could ship):

Time is UTC (Date.now() from edge) and rendered with client locale.
Health metrics are ephemeral; Redis/Upstash persists across Vercel edge instances when configured; otherwise in-memory for local/dev.
Currency doesn’t influence health, but we carry portfolio base currency for display so timestamps/labels remain consistent with the rest of the dashboard.

Key design decisions (and trade-offs)

Bounded latency over completeness. The health endpoint returns quickly even with sparse data—an empty array is OK. We’d rather show “Unknown” than block the dashboard.
Minimal contract. Four fields per provider are enough for meaningful UI and alerting. Anything more invites bikeshedding and cross-service coupling.
Rate-limited edge function. We added headers and a per-IP token bucket (Vercel middleware) so the 30 s polling cadence doesn’t DOS ourselves.
UI rules are declarative. We encode thresholds in one function, shared by the card and tests, so designers can tune without hunting through JSX.

Code sample 1 — Edge function (typed health endpoint)

// File: /api/health-price/route.ts (Vercel Edge Function)
import { NextResponse } from "next/server"; // or "vercel-edge" if using a minimal runtime

export const runtime = "edge";

type Provider = "yahoo" | "chart" | "stooq";
export type ProviderHealth = {
  provider: Provider;
  lastSuccess?: number;  // epoch ms (UTC)
  lastFailure?: number;  // epoch ms (UTC)
  failureCount: number;  // rolling window
  activeFallback: boolean;
};

// Storage (Upstash if configured, else in-memory)
import { kv } from "@vercel/kv"; // thin wrapper around Upstash; fallback below
const mem = new Map<string, ProviderHealth>(); // dev only

async function readAll(): Promise<ProviderHealth[]> {
  if (process.env.UPSTASH_REDIS_REST_URL && kv) {
    const raw = await kv.get<Record<Provider, ProviderHealth>>("pp:health:v1");
    return raw ? Object.values(raw) : [];
  }
  return Array.from(mem.values());
}

// (Called by /api/quote on each provider attempt)
export async function record(event: "success"|"failure", provider: Provider, usedAsFallback: boolean) {
  const now = Date.now();
  const current = (await readAll()).find(p => p.provider === provider) ?? { provider, failureCount: 0, activeFallback: false };
  const next: ProviderHealth = {
    ...current,
    lastSuccess: event === "success" ? now : current.lastSuccess,
    lastFailure: event === "failure" ? now : current.lastFailure,
    failureCount: event === "failure" ? (current.failureCount + 1) : current.failureCount,
    activeFallback: usedAsFallback || (event === "failure" ? current.activeFallback : current.activeFallback),
  };
  if (process.env.UPSTASH_REDIS_REST_URL && kv) {
    await kv.hset("pp:health:v1", { [provider]: next });
  } else {
    mem.set(provider, next);
  }
}

export async function GET() {
  const providers = await readAll();
  // CORS & client cache (short)
  const res = NextResponse.json({ providers } as { providers: ProviderHealth[] }, { status: 200 });
  res.headers.set("Cache-Control", "max-age=5, s-maxage=5");
  res.headers.set("RateLimit-Policy", "30;w=60"); // soft hint, enforced by middleware
  return res;
}

Diff-able suggestion: keep ProviderHealth in a shared @types package so the API and UI compile against the same contract.

Code sample 2 — Client types, polling hook, and card

// File: src/services/priceHealth.ts
export interface PriceHealthResponse { providers: ProviderHealth[] }
export type Provider = "yahoo" | "chart" | "stooq";
export type ProviderHealth = { provider: Provider; lastSuccess?: number; lastFailure?: number; failureCount: number; activeFallback: boolean };

const THRESHOLDS = { freshMs: 30_000, fallbackMs: 60_000, unhealthyMs: 5 * 60_000 } as const;

export function statusOf(h: ProviderHealth, now = Date.now()): "Fresh"|"Fallback"|"Unhealthy"|"Unknown" {
  if (!h.lastSuccess && !h.lastFailure) return "Unknown";
  if (!h.lastSuccess || now - h.lastSuccess >= THRESHOLDS.unhealthyMs) return "Unhealthy";
  if (h.activeFallback || (h.lastFailure && now - h.lastFailure < THRESHOLDS.fallbackMs)) return "Fallback";
  if (now - h.lastSuccess < THRESHOLDS.freshMs) return "Fresh";
  return "Fallback"; // conservative default
}

export async function getPriceHealth(signal?: AbortSignal): Promise<PriceHealthResponse> {
  const r = await fetch("/api/health-price", { signal, headers: { "Accept": "application/json" } });
  if (!r.ok) throw new Error(`health ${r.status}`);
  return r.json();
}

// File: src/hooks/usePriceHealth.ts
import { useEffect, useRef, useState } from "react";
import { getPriceHealth, type PriceHealthResponse } from "../services/priceHealth";

export function usePriceHealth(intervalMs = 30_000) {
  const [data, setData] = useState<PriceHealthResponse | null>(null);
  const [error, setError] = useState<Error | null>(null);
  const timer = useRef<number | null>(null);

  useEffect(() => {
    let abort = new AbortController();
    const tick = async () => {
      try {
        const json = await getPriceHealth(abort.signal);
        setData(json); setError(null);
      } catch (e:any) { setError(e); }
    };
    tick();
    timer.current = window.setInterval(() => { abort.abort(); abort = new AbortController(); tick(); }, intervalMs);
    return () => { if (timer.current) window.clearInterval(timer.current); abort.abort(); };
  }, [intervalMs]);

  return { data, error, loading: !data && !error };
}

// File: src/components/HealthCard.tsx
import { statusOf } from "../services/priceHealth";
export function HealthCard({ providers }: { providers: ReturnType<typeof statusOf> extends never ? never : any }) {
  // In practice, pass the raw ProviderHealth[] from hook and compute statusOf(...) per row
  // Render with RAG badges; ensure accessible labels (aria-label includes provider + status + freshness age).
  return null;
}

Network failure behavior: we abort fetches when polling ticks; UI shows “Unknown” + skeleton when the endpoint is temporarily unavailable.
Timezone: server times are epoch ms UTC; client renders “age” using the user’s locale.
CSV quirks: not directly involved here, but our import pipeline writes fills/fees/FX into the “Explain” drawer so the health chip never has to infer from CSV content.

Diagram (textual)

Four boxes left-to-right: Providers (Yahoo, Chart, Stooq) → Quote Engine (1.5 s budget, first-valid-wins) → Health Store (lastSuccess/lastFailure/failureCount/activeFallback in Redis/Memory) → Health Endpoint → Health Card (RAG badges). Arrows show the quote path writing events to the Health Store while the card polls the endpoint every 30 s.

What we learned

Small contracts travel far. Four fields per provider were enough for users and for ops. Anything larger would have slowed the API and the UI decisions.
UI truth must match server truth. Sharing ProviderHealth and the status function eliminated a class of “red vs amber” bugs after design tweaks.
Bounded work beats perfect work. Time-boxed polling with short cache headers kept Vercel usage predictable and avoided the “silent freeze” trap.

Acceptance Criteria

Card displays each configured provider with one of: Fresh, Fallback, Unhealthy, or Unknown.
Status mapping:
- Fresh if now - lastSuccess < 30s.
- Fallback if activeFallback = true or now - lastFailure < 60s.
- Unhealthy if no success in the last 5 min (or lastSuccess absent).
- Unknown when no events yet.
Polls /api/health-price every 30 s, cancels in-flight requests on unmount/retick.
Accessible: badge has aria-label “{provider}: {status}, last success {age}”.
Works with Redis and in-memory dev mode.
Does not block other dashboard widgets (TTI delta < 50 ms vs. baseline).

Definition of Done (DoD)

All Acceptance Criteria met.
Unit tests for statusOf() thresholds and hook cancellation.
Visual regression for card states (Fresh/Fallback/Unhealthy/Unknown).
Edge function covered by a smoke test; rate-limit headers present.
Feature flag toggles card visibility; telemetry logged (load, error).

Test notes

Simulate provider outages by forcing lastSuccess older than 5 min; expect Unhealthy.
Kill the endpoint (500) during polling; card should show Unknown without console spam.
Verify locale rendering of “age” labels (e.g., en-GB vs en-US).
On slow networks, confirm abort controller cancels prior fetches (no waterfall).

Documentation / Release notes

New: Price Pipeline Health card (Dashboard → right column).
API: GET /api/health-price returning ProviderHealth[].
Env (optional): UPSTASH_REDIS_REST_URL, UPSTASH_REDIS_REST_TOKEN.
Known limitations: provider list is static for this release; symbol-level freshness and outage alerts are tracked separately.
Rollout: staged (beta cohort first); feature flag pp.healthCard=true.

Designing a “Never-0.00” Price Pipeline in the Real World

22s Pocket Portfolio — Wed, 01 Oct 2025 18:01:17 +0000

Your users don’t care why a quote failed—they care that the number didn’t flash 0.00. Here’s a pragmatic, production-ready pipeline that returns the best price you can get within a strict time budget, exposes provenance, and never silently lies.

Audience: engineers shipping finance dashboards, brokers, or portfolio tools.
Deliverables: architecture, TypeScript code (fetch with timeout + backoff), and a reproducible test harness you can run locally.

The failure modes we must beat

Single-provider coupling. One upstream hiccup → you show 0.00 or stale data.
Unbounded waits. A slow API call blocks the UI thread or burns your edge budget.
Silent staleness. You cache yesterday’s price and don’t tell the user.
Inconsistent math. Different providers round/adjust differently, breaking P/L.

We’ll design for bounded latency, graceful degradation, and auditability.

Architecture: time-boxed fan-out + LKG + provenance

Imagine the following diagram (textual description):

[ Client ]  --(fetch / 1.5s budget)--> [ Edge Worker ]
                                        |-> Provider A (Yahoo)   [score 0]
                                        |-> Provider B (NBBO)    [score +1]
                                        |-> Provider C (CoinGecko/OHLC) [score +2]
                                        |
                             <best valid within budget>
                                        |
                           [ LKG cache (30s TTL) ]
                                        |
                           returns {price, ts, source, stale}

The edge queries providers in parallel within a strict budget (e.g., 1500 ms).
We prefer the first valid response using a simple health score (recent failures raise the score; ties go to lowest score).
If nothing lands in time, we return LKG (last-known-good) marked stale: true.
The client renders a Provenance chip: Yahoo • 12s • Live or Cache • 45s • Stale. No black boxes.

Core TypeScript: bounded fetch with backoff + jitter

We’ll start with a few helpers.

// utils/timeout.ts
export async function fetchWithTimeout(
  url: string,
  ms: number,
  init: RequestInit = {}
): Promise<Response> {
  const ctrl = new AbortController();
  const timer = setTimeout(() => ctrl.abort("time_budget_exceeded"), ms);
  try {
    const res = await fetch(url, { ...init, signal: ctrl.signal });
    return res;
  } finally {
    clearTimeout(timer);
  }
}

// utils/backoff.ts
export function backoffDelay(attempt: number, base = 150, cap = 1000) {
  // exponential backoff with full jitter
  const exp = Math.min(cap, base * 2 ** attempt);
  return Math.floor(Math.random() * exp);
}

Provider adapters (pure functions)

Each adapter returns a normalized quote or throws.

// providers/types.ts
export type Quote = {
  symbol: string;
  price: number;
  ts: number;       // epoch millis
  source: string;   // "yahoo", "nbbo", etc.
};

export type Provider = (s: string) => Promise<Quote>;

// providers/yahoo.ts
import { fetchWithTimeout } from "../utils/timeout";
import type { Quote, Provider } from "./types";

export const yahoo: Provider = async (symbol) => {
  const r = await fetchWithTimeout(`https://api.example/yahoo?symbol=${symbol}`, 700);
  if (!r.ok) throw new Error(`yahoo:${r.status}`);
  const j = await r.json();
  const price = Number(j?.price);
  if (!Number.isFinite(price)) throw new Error("yahoo:invalid");
  return { symbol, price, ts: Date.now(), source: "yahoo" };
};

Duplicate for other sources (nbbo, coingecko, etc.) with their own timeouts.

Circuit breaker + scoring

Providers accumulate penalties on failure (simple, sticky health heuristic).

// engine/quotes.ts
import type { Provider, Quote } from "../providers/types";
import { backoffDelay } from "../utils/backoff";

type Health = Record<string, number>; // lower is healthier

export type BudgetedOptions = {
  budgetMs?: number;          // total time budget
  attempts?: number;          // retries per provider
  lkg?: Quote | null;         // last-known-good
  health?: Health;            // provider health map
};

export async function getQuoteWithBudget(
  symbol: string,
  providers: Record<string, Provider>,
  opts: BudgetedOptions = {}
): Promise<Quote & { stale: boolean }> {
  const budgetMs = opts.budgetMs ?? 1500;
  const attempts = opts.attempts ?? 1;
  const health = opts.health ?? {};

  const start = Date.now();
  let winner: Quote | null = null;

  // run providers in order of health (lowest first)
  const entries = Object.entries(providers).sort(
    ([a], [b]) => (health[a] ?? 0) - (health[b] ?? 0)
  );

  // Launch all providers in parallel but respect total budget
  await Promise.any(
    entries.map(async ([name, p]) => {
      for (let i = 0; i < attempts; i++) {
        const elapsed = Date.now() - start;
        const remaining = budgetMs - elapsed;
        if (remaining <= 0) throw new Error("time_budget_exceeded");

        try {
          const q = await p(symbol); // each p uses its own per-call timeout
          if (!Number.isFinite(q.price)) throw new Error("invalid");
          if (!winner) winner = q;    // first valid wins
          return;
        } catch {
          health[name] = (health[name] ?? 0) + 1; // penalize on fail
          await new Promise((r) => setTimeout(r, backoffDelay(i)));
        }
      }
      throw new Error(`${name}_exhausted`);
    })
  ).catch(() => null);

  // If nothing landed, fall back to LKG
  const now = Date.now();
  if (!winner && opts.lkg) {
    return { ...opts.lkg, source: `${opts.lkg.source}+lkg`, stale: true };
  }

  if (!winner) {
    // honest sentinel; caller should render skeleton/“unavailable”
    return { symbol, price: NaN, ts: now, source: "unavailable", stale: true };
  }

  // Mark staleness based on age (e.g., 30s)
  const stale = now - winner.ts > 30_000;
  return { ...winner, stale };
}

Why this shape works: bounded total latency, first valid result preference, provider health nudges future calls, and a clean stale flag keeps the UI honest.

Client UX: provenance chip (text-described diagram)

Imagine a small pill next to the price:

[ Yahoo • 12s • Live ]    // green background
[ Cache • 47s • Stale ]    // amber background

When a user clicks it, show a popover with source, requestId, and the time budget used—handy for bug reports and audits.

// ui/ProvenanceBadge.tsx
export function ProvenanceBadge({ source, ts, stale }: { source: string; ts: number; stale: boolean }) {
  const ageSec = Math.max(0, Math.round((Date.now() - ts) / 1000));
  const label = `${source} • ${ageSec}s • ${stale ? "Stale" : "Live"}`;
  const cls = `px-2 py-1 rounded-full text-xs ${stale ? "bg-yellow-100 text-yellow-800" : "bg-green-100 text-green-800"}`;
  return <span className={cls} aria-live="polite">{label}</span>;
}

Reproducible test harness

We’ll simulate providers with deterministic latency/failure. You can paste this into a Node/TS project (no network required).

// harness/sim.ts
import type { Provider, Quote } from "../providers/types";
import { getQuoteWithBudget } from "../engine/quotes";

function fakeProvider(name: string, opts: { latency: number; fail?: boolean; price?: number }): Provider {
  return async (symbol: string) => {
    await new Promise((r) => setTimeout(r, opts.latency));
    if (opts.fail) throw new Error(`${name}_fail`);
    const price = opts.price ?? 100 + Math.random();
    return { symbol, price, ts: Date.now(), source: name } as Quote;
  };
}

async function main() {
  const providers = {
    yahoo: fakeProvider("yahoo", { latency: 180, price: 189.97 }),
    nbbo:  fakeProvider("nbbo",  { latency: 420, price: 189.95 }),
    alt:   fakeProvider("alt",   { latency: 1100, fail: true }),
  };
  const out = await getQuoteWithBudget("AAPL", providers, { budgetMs: 600, attempts: 1, lkg: null, health: {} });
  console.log(out);
}

main().catch(console.error);

Expected behavior: with a 600 ms budget, yahoo wins (180 ms). If you increase yahoo latency above 600, nbbo becomes the winner. If everything fails, the function returns { price: NaN, source: "unavailable", stale: true }—which your UI should render as a skeleton or an explicit “unavailable” state.

Unit tests (Vitest)

// harness/sim.test.ts
import { describe, it, expect } from "vitest";
import { getQuoteWithBudget } from "../engine/quotes";
import type { Provider } from "../providers/types";

function p(name: string, latency: number, ok = true, price = 101): Provider {
  return async (s) => {
    await new Promise((r) => setTimeout(r, latency));
    if (!ok) throw new Error(name);
    return { symbol: s, price, ts: Date.now(), source: name };
  };
}

describe("getQuoteWithBudget", () => {
  it("returns first valid within budget", async () => {
    const out = await getQuoteWithBudget("AAPL", { slow: p("slow", 500), fast: p("fast", 80, true, 190.12) }, { budgetMs: 300 });
    expect(out.source).toBe("fast");
    expect(out.stale).toBe(false);
    expect(Number.isFinite(out.price)).toBe(true);
  });

  it("falls back to LKG when none arrive in time", async () => {
    const lkg = { symbol: "AAPL", price: 188.5, ts: Date.now() - 40_000, source: "cache" };
    const out = await getQuoteWithBudget("AAPL", { slow: p("slow", 800) }, { budgetMs: 200, lkg });
    expect(out.source).toContain("lkg");
    expect(out.stale).toBe(true);
    expect(out.price).toBe(188.5);
  });

  it("returns sentinel when all fail & no LKG", async () => {
    const out = await getQuoteWithBudget("AAPL", { a: p("a", 50, false), b: p("b", 60, false) }, { budgetMs: 150 });
    expect(out.source).toBe("unavailable");
    expect(isNaN(out.price)).toBe(true);
  });
});

Run it

npm i -D vitest typescript tsx
npx vitest run

Production notes (learned the hard way)

Time budgets must be end-to-end (edge → providers → marshaling). Don’t just set per-call timeouts; total elapsed matters.
Never coerce NaN to 0.00. Return a sentinel and render it honestly.
Record provenance (source, ts, requestId) for every price; it turns user bug reports into reproducible tickets.
Cache with intent. LKG cache should be small (e.g., 30–60 s) and keyed by symbol + venue where applicable.
Score providers. A sticky health score quickly pushes you away from flaky sources without a full breaker library.
UI skeletons + chips > spinners. Show skeleton rows during refresh and clear “Stale” chips when using LKG.

What this buys you

Predictable UX: Users get a number (or a truthful “stale/unavailable”) within your SLA.
Operational safety: Slow or failing providers don’t stall the entire pipeline.
Auditability: Every number is explainable—source + age + freshness.

Next steps you can ship today

Drop getQuoteWithBudget into your edge worker.
Add the Provenance chip.
Wire a 30–60 s LKG cache and emit “stale” when using it.
Expand the test harness with your real providers behind a feature flag.

If you want a code drop-in adapted to your stack (Vercel Edge, Cloudflare Workers, or Node), ping me your environment and symbols—you’ll get a tailored snippet.

Want the companion “OpenBrokerCSV v0.1” spec + validator to make imports boringly reliable? I’ve got a minimal template and test fixtures—DM me your broker and I’ll spin up a mapping PR.

Engineers, last call: help us build the cleanest open-source investing dashboard (before it gets boring)

22s Pocket Portfolio — Sun, 28 Sep 2025 19:03:45 +0000

If you’ve ever yelled at a portfolio tool that showed 0.00 for prices or made CSV import a hostage situation — come fix it with us.

I’m 22s, one of the folks behind Pocket Portfolio — an open-source, no-paywall investing dashboard. You can import a CSV → see clean live P/L → model trades in a Mock-Trade Lab that never touches real totals.

We’re small, fast, and friendly. Right now is the perfect moment to jump in: the architecture is set, the “why” is clear, and the issues are scoped for 30/60/90-minute wins.

App → https://www.pocketportfolio.app/app

Repo → https://github.com/PocketPortfolio/Financialprofilenetwork

Discord → link on the site

Why this is fun (and real)

No paywalls, no dark UX. We ship clarity first.
Edge-powered quotes with provider rotation and never-zero fallbacks.
Import flow that actually helps: sample files + an error-CSV you can fix fast.
Mock-Trade & Scenario Lab to model “what if” without touching real P/L.

If you like building explainable systems (numbers that tell you why they changed), you’ll feel at home.

The stack (and the shape of work)

React + TypeScript (Vite), Tailwind, Testing Library/Playwright
Edge functions (Vercel/Cloudflare), Fetch with timeouts/retries
CSV pipeline (schema validation, normalizers, error envelopes)
A11y: roles/ARIA, roving tabindex, keyboard shortcuts

We keep PRs small, tests close to the UI, and docs right in the code.

Good-first issues you can claim today

⏱ 30 minutes

Add a broker CSV mapping (we’ll hand you a redacted row + schema).
Improve focus ring + contrast tokens on the positions grid.

⏱ 60 minutes

Playwright test: error-CSV → fix → success loop.
Make the “mock trades active” chip announce to screen readers.

⏱ 90 minutes

Lightweight telemetry counters on edge fallbacks (no PII, just counts).
Keyboard: ? shortcuts overlay (hotkeys + help link).

Comment /claim on the issue and we’ll pair if you want.

A tiny taste of the work

Client → edge price fallback (never show 0.00)

// edge/quote.ts (pseudo)
const providers = [
  { name: 'p1', url: env.P1, timeoutMs: 1400 },
  { name: 'p2', url: env.P2, timeoutMs: 1400 },
  { name: 'p3', url: env.P3, timeoutMs: 1600 },
];

export async function getQuote(sym: string) {
  for (const p of providers) {
    try {
      const ctl = new AbortController();
      const t = setTimeout(() => ctl.abort(), p.timeoutMs);
      const r = await fetch(`${p.url}/q?symbol=${sym}`, { signal: ctl.signal, cf:{ cacheTtl: 10 }});
      clearTimeout(t);
      if (!r.ok) continue;
      const { price } = await r.json();
      if (Number.isFinite(price)) return { price, src: p.name };
    } catch {}
  }
  const last = await KV.get(`q:${sym}`);        // last known good
  return { price: last?.price ?? null, stale: true };
}

Import envelope

ts type ImportRow = { raw: Record<string,string>; norm?: { sym: string; qty: number; price: number; ts: string }; err?: { code: 'PARSE'|'SCHEMA'|'MISSING'; hint: string }; };

What you’ll own (and learn)

Designing fast, explainable UIs for numbers people care about
Turning a11y into speed (keyboard-first flows)
Shipping edge-aware logic with clear failure policies
Writing tests that save users from rage-quitting

We give shout-outs in the app, PR credits, and a public trail of work you can point to.

How to start in 5 minutes

⭐ Star the repo.
Pick any issue labeled good first issue or comment /claim under one of the ideas above.
pnpm i && pnpm dev (Vite) — we’ll help you get to your first diff quickly.
Open a PR with screenshots or a 10s GIF.
We review fast; you ship the slice.

If you’ve read this far, you’re probably the kind of person we want to build with. Hop in now — this is the most interesting stage: small, sharp, and shipping.

— 22s
Founder, Pocket Portfolio
App • Repo • Discord (on the site)

ELI5: What’s the difference between realized vs unrealized P/L?

22s Pocket Portfolio — Wed, 24 Sep 2025 17:34:12 +0000

I’m building an open-source portfolio dashboard and keep tripping over how to explain P/L in a way that actually clicks for newcomers.

ELI5 ask:

How would you explain the difference between realized profit/loss and unrealized profit/loss to a 10-year-old?

Constraints (to keep it simple):

Use one short analogy (max 2–3 sentences).
Bonus if you can show a tiny numeric example (e.g., “bought at 10, now 12…”).

A couple of things that confuse people we talk to:

“If I didn’t sell, why does the number go up/down?”
“Fees & FX: do they belong in realized, unrealized, or both?”

Drop your best analogy below — I’ll pin the clearest one and credit you in our in-app help text 🙌

Today’s ship: Mock-Trade Lab, 5-min CSV Import, and bulletproof Price Fallbacks

22s Pocket Portfolio — Wed, 24 Sep 2025 17:23:35 +0000

Quick one from me. We pushed three things live today that make Pocket Portfolio immediately useful the moment you land.

1) Mock-Trade & Scenario Lab (live)

What: Add/remove positions, tweak size/price, and watch totals change — without touching your real P/L.

Why it’s useful: sanity-check ideas (hedge, rebalance, scale-in) before you commit. It’s the “are we sure?” button.

How: open the app → Add Mock Trade → try TSLA +2 @ 260. Your real totals stay untouched, scenarios are clearly labeled.

2) 5-minute CSV import (with samples + error report)

What: Drag-drop a broker CSV; we normalize it and show a clean portfolio. Comes with sample CSVs and a Download error report if a row fails.

Why it’s useful: no broker hookups, no paywalls — just get your data in and move on.

How: Menu → Import CSV → use a sample (eToro / Coinbase / Generic) or your own. If a row trips, download the error CSV and paste a redacted line in the comments — we’ll add the mapping.

3) Resilient price fallbacks (equities, FX, crypto)

What: Client → edge design with provider rotation and caching. If one endpoint blinks, we fail over.

Why it’s useful: fewer “0.00” moments, snappier updates, and more trustworthy P/L.

How: nothing to configure; just… works. You’ll see steady quotes across stocks, FX and crypto.

Try it now

App → https://www.pocketportfolio.app/app?utm_source=devto&utm_medium=post&utm_campaign=today-ship

Repo → https://github.com/PocketPortfolio/Financialprofilenetwork

Your turn (I’ll respond today)

Share a redacted CSV row if your import failed — we’ll ship a mapping.
Tell me the one scenario you model before you hit “Buy/Sell.” I’ll add it to the Mock-Trade presets.

Building in public means shipping small, useful slices daily. If you want to help, grab a good first issue in the repo and comment /claim — I’ll pair with you.

Test ideas without risking a penny — Mock Trade & Scenario Lab (open source)

22s Pocket Portfolio — Tue, 23 Sep 2025 15:58:08 +0000

Before you buy/sell, preview the impact. Our Mock Trade & Scenario Lab lets you model positions side-by-side with your real portfolio — no paywall, no broker hookup.

Why it matters

Zero-risk exploration: Add/remove positions or tweak size/price; see P/L and exposure change instantly.
Separated totals: Mock trades never pollute your real P/L.
Fast iteration: Works on any device; price fallbacks keep numbers reliable.

60-second path

1) Open the app (guest mode works): https://www.pocketportfolio.app/app?utm_source=devto&utm_medium=post&utm_campaign=mocklab

2) Click Add Mock Trade, e.g., TSLA +2 @ $260.

3) Watch P/L update; toggle ideas until you like the shape.

4) Need feedback? Screenshot and drop it below — we’ll sanity-check the scenario.

Help wanted (good first issues)

“Copy debug bundle” for scenarios (one-click JSON)
A11y/keyboard flow for the trade modal
Tiny chart sparkline on the P/L card

Try it now → https://www.pocketportfolio.app/app?utm_source=devto&utm_medium=post&utm_campaign=mocklab

Repo → https://github.com/PocketPortfolio/Financialprofilenetwork

Question: What scenario would you model first (hedge, rebalance, or new idea)?

DEV Community: Pocket Portfolio

We built a "Sovereign" Wealth Tracker with Next.js 15 (No Ads, No Data Selling)

The "Sovereign" Architecture 🛡️

The Stack

The "Client-Side Brain" 🧠

The Feature: "Risk Radar" ⚡

Challenges with Next.js 15 & Recharts

Why "Sovereignty" Matters

Support the Project

Stop Scraping Yahoo Finance: A Free, No-Key JSON Endpoint for Stock Data

The "Hidden" JSON Endpoint

How to use it

The Architecture: "Google Drive as Database"

Building AI Financial Agents?

Summary

Stop Building Fintech with Databases: Why I Went Local-First for Pocket Portfolio

Stop building fintech with databases. Why I went local-first for Pocket Portfolio.

The Zero-Server Stack

The Hardest Part: Client-Side Parsing

The Market Has Spoken

Try It (and Break It)

Designing Trust: UX Principles in Fintech Apps

Designing Trust: UX Principles in Fintech Apps

1. Trust Is the Product

Core Design Principles

2. Designing Onboarding Psychology

3. Visual Reliability

Design Anchors

4. Designing for Dark Mode

Implementation Guide

5. Microcopy That Builds Confidence

6. A Trust Loop in Motion

7. Results

What’s Next

Realised vs Unrealised P/L — Money in Your Pocket vs Money on Paper

💰 Realised vs Unrealised P/L — Money in Your Pocket vs Money on Paper

🧠 The Simple Truth

📊 Real-World Example

🧮 Try It Yourself — P/L Calculator

📚 Why This Matters for You

📺 See It in Action

⚠️ Common Mistakes to Avoid

✅ Key Takeaways

🔗 Further Reading & References

Price Pipeline Health — transparency you can see (and trust)

Context

What's new

How it works (high-level)

Impact on users

How to contribute / try it today

Try it locally

Configure persistence (production)

Open-source collaboration

Why this matters (and a friendly challenge)

Appendix: implementation notes

Credits

Devlog: Building the **Price Pipeline Health** Card (so you know when data is fresh or fallback)

The problem we set out to solve

How we scoped it

Key design decisions (and trade-offs)

Code sample 1 — Edge function (typed health endpoint)

Code sample 2 — Client types, polling hook, and card

Diagram (textual)

What we learned

Acceptance Criteria

Definition of Done (DoD)

Test notes

Documentation / Release notes

Designing a “Never-0.00” Price Pipeline in the Real World

The failure modes we must beat

Architecture: time-boxed fan-out + LKG + provenance

Core TypeScript: bounded fetch with backoff + jitter

Provider adapters (pure functions)

Circuit breaker + scoring

Client UX: provenance chip (text-described diagram)

Reproducible test harness

Unit tests (Vitest)

Production notes (learned the hard way)

What this buys you

Next steps you can ship today

Devlog: Building the Price Pipeline Health Card (so you know when data is fresh or fallback)

ELI5: What’s the difference between realized vs unrealized P/L?