Skip to main content

Proof stories (map to this domain)

Personal boards you already shipped. Tell them as the design you would have teams copy.

Temelio — two systems of record​

Strongest personal board. Spring + React, money, sync, stakeholders. Maps to VRM.

Constraint​

Foundations keep grants in Temelio and money in an accounting system. Business asked for “it just syncs.” Design question: which system wins for which field, and what the screen shows when they disagree.

Domain analog: agent books vs lender view.

Draw four boxes​

  1. UI (Next / React) — payment status, last synced at, errors a person can act on.
  2. Application API (Kotlin / Spring Boot) — product contract.
  3. Sync / mapping layer — Temelio model in, vendor model out.
  4. Accounting vendor — source of truth for posted accounting.

Add queue + worker and Datadog / Sentry on the worker if they want depth.

Decisions (tech lead and EM)​

  • One-way first. Not fake two-way on day one.
  • Idempotency on payment id.
  • Conflicts: UI shows a break; the client does not pick a winner.
  • Tenancy and secrets.
  • Workshops so CS/sales don’t sell a lie — that’s operational excellence.

Fill in: which accounting product; one conflict rule; webhooks vs poll.

Close​

“I would start a vertical the same way: what we owe the user, where golden source is, what the API is, what we test when it breaks, how the UI tells the truth, and how the team is allowed to ship. Then we implement it.”

Thirty seconds: “We designed an accounting integration as a mapping layer between two ledgers, with idempotent writes, explicit conflict behavior, a UI that showed sync state, and we taught the company how to sell that honestly.”

Phia — scaling the ingestion pipeline​

Use for scale, traffic, queues. Honest: consumer app, marketplace ingest, launch spike. Maps to ingest.

Constraint​

Naive: user opens item → live-hit every marketplace → wait. Dies on rate limits and thundering herd.

Draw five boxes​

  1. Clients (iOS, extension).
  2. Application API — read, not scrape.
  3. Ingestion pipeline / workers.
  4. Store + cache; coalesce jobs on item identity.
  5. Marketplace sources with rate limits.

Mechanisms (only ones you shipped)​

Decouple read from ingest; queue + workers; dedupe; backoff; normalize once; backfill vs realtime; watch queue lag and p95 “time until we have a price.”

Fill in: queue tech; item identity; crawl vs API; one incident.

EM add​

When co-founders wanted more sources for launch, the constraint was ingest capacity, not a missing button. That’s resource allocation. You would say no to the fifth source until the queue SLO held.

Domain close​

“Phia was many users, flaky sources, UI must feel instant. This domain is fewer users, stricter correctness. Same shape: expensive work off the request path, don’t hammer the source of truth, normalize at the boundary, show what is actually known. The agent feed is the marketplace API.”

Thirty seconds: “We took listing ingest off the request path, queued and coalesced work per item, and scaled workers behind rate limits so the app could read from our store when traffic jumped.”

If they ask you to pick one and go deep​

Temelio / VRM-shaped if they care about consistency, security, stakeholders.
Phia ingest / DDP-shaped if they care about pipelines and backpressure.
Voting if they give you a greenfield prompt — use snapshot + entitlements even if you never built voting.