Every card below is a system we built, secured, or shipped, described in the language of what we can prove rather than what we can pitch. Client names, domains, and commercial terms appear nowhere on this page; the evidence behind each claim is available under NDA. Two of these run in production today, one is our own AI product, and one is an interactive prototype with a build plan, and we label each honestly.
How to read this page
We anonymize client work on purpose. Where a card says “live,” it means we verified it the way a client would, not by taking a screenshot of a dashboard. The kind of trace behind every “live” badge looks like this (domain redacted):
# reproducible verification, not a screenshot of a vibe
GET /api/health 200 {"status":"healthy"}
GET /api/auth/me 401 {"error":"UNAUTHORIZED"} # auth boundary enforced live
POST /api/auth/dev-login 404 # dev endpoint disabled in prodEvery finding count, migration, and probe on this page is a fact from a real repository, verifiable under NDA. For how we produce that evidence, see our methodology; for a redacted example of the deliverable, see the sample assessment report.
Subscription investment-analytics platform (client)
Problem — A consumer fintech product needed to graduate from prototype to a secure, revenue-capable, production-grade platform: real payments, AI features users can trust, and infrastructure that stays up and stays safe.
What we built — A full production SaaS: value-investing analytics (screening, DCF and valuation, SEC-filing tracking, portfolio management), a bilingual RTL/LTR app, an AI analyst plus AI-generated research insights, and an end-to-end subscription billing engine.
What was risky — The money path and the AI. A payment gateway with no native recurring or HMAC support can double-charge on a replayed webhook; stored secrets and card tokens can leak; and an LLM feature with no cost ceiling or output contract can burn budget and return content a user cannot trust.
What we fixed — A written threat model plus a security audit that surfaced 36 ranked findings, then a remediation pass that closed every one at the code level. Idempotent charges keyed on a unique transaction id so a replayed webhook cannot double-activate; card tokens stripped from the payments ledger; webhooks verified server-to-server instead of trusting the POST body. AES-256-GCM envelope encryption for secrets at rest that fails closed in production if no key is set. Role- and tier-based auth, a CORS allow-list, CSRF protection, and per-endpoint rate limiting. On the AI: task-aware model routing on AWS Bedrock, bilingual output contracts (an English and Hebrew pair, never a bare string), and a per-user daily LLM budget guard.
Stack — Next.js 16 / React 19 / TypeScript, Hono API, PostgreSQL (Prisma, 64 models, 17 migrations), Redis, AWS Cognito, AWS Bedrock, Docker → AWS ECR → EC2, 8 GitHub Actions pipelines.
Production status — Live in production. Self-hosted on AWS with automated daily database backups, health and APM probes, and production smoke tests. Active user and revenue figures are the client’s to disclose, so we do not.
What this proves — The full ladder on one client system: assess (threat model plus audit), productionize (payments, secrets, LLM cost and quality), and run it (backups, monitoring, migration discipline). This maps to Build and Run and to the readiness assessment.
Field-first procurement and profitability platform (client, construction)
Problem — A multi-project construction and renovation contractor was running procurement, inventory, budgets, and subcontractor costs on paper and spreadsheets with no real-time view of per-project profitability. An early prototype existed but was roughly 30 percent built and, critically, had no authentication, publicly reachable routes, unprotected data mutations, and credentials in source. Not shippable.
What we built — We took that prototype to a live, multi-tenant SaaS: an auth boundary (Firebase plus a signed session cookie) that strips forged identity headers, role-based access control on every mutation across six roles, strict tenant isolation on a safely migrated schema, a production OCR document-intake pipeline (supplier invoices and delivery notes captured via inbound email), and a mobile-first PWA with offline support for field use.
What was risky — The starting state was the danger. Unauthenticated public routes and unprotected mutations mean any visitor could read or write another tenant’s data. And a NOT NULL multi-tenant migration on live data can lock or corrupt a running system if done carelessly.
What we fixed — Closed six P0 cross-tenant vulnerabilities found in a security audit and locked them in with 17 tenant-isolation regression tests. Shipped a middleware that assumes the client is hostile: it strips any client-supplied identity headers on every request and re-sets them only on the verified path, and production throws at boot if the session secret is unset so a misconfigured deploy never serves unauthenticated traffic. Ran the NOT NULL tenancy migration behind a feature flag with a backfill and a database-branch rollback as a one-click panic button — reversible, not cowboy. Retry and timeout on every external SDK call, post-deploy smoke tests, and CI running a real Postgres with the isolation suite.
Stack — Next.js 16 / React 19 (TypeScript), Prisma + PostgreSQL (Neon), Firebase Auth, AWS S3, Google Cloud Vision (OCR), Tailwind v4, deployed on Vercel; a full Terraform and ECS IaC path also authored.
Production status — Live in production on Vercel. Verified live: an enforced auth boundary, security headers (HSTS with preload, frame-deny, a strict CSP), and a dev endpoint correctly disabled in production. User scale is the client’s to disclose.
What this proves — The prototype-to-production arc documented end to end: insecure and half-finished in, hardened multi-tenant product out. This maps to Prototype to Production Hardening.
faben — our own AI product
Problem — Generic “top 10 nearby” lists do not help a person actually decide where to go, and a raw LLM demo is not safe to run in production: no cost control, no evaluation, no privacy posture, no defense against prompt injection or leaked model errors.
What we built — faben, a live iOS and Android travel-decision app. Its core is Wandi, a conversational decision engine (extract intent, eliminate options, rank directions, emit a search directive) backed by a provider-abstracted LLM layer (Anthropic or AWS Bedrock behind one Messages shape), an evidence-first research and RAG pipeline, semantic search over pgvector, and the part most demos skip: a full AI evaluation and release-certification platform.
What was risky — Everything that makes an LLM feature unsafe in production. Unbounded model spend; a decision agent that can be steered by injected instructions (OWASP LLM01 Prompt Injection); model or auth errors leaking internals (LLM02 Sensitive Information Disclosure); and safety-critical outputs, such as dietary and kosher classification, that must never be wrong-but-confident.
What we designed against — Server-owned models (clients cannot override the model), per-user and global LLM spend and token budget reservation, and a production usage cost ledger. JWT auth whose error messages are sanitized so token-library internals never leak to callers, while a request id keeps failures correlatable in logs. Fail-closed Sign in with Apple (off in production until revoke-on-delete is implemented), spoof-resistant rate limiting keyed on a non-spoofable IP source, and explicit AI-consent middleware gating third-party AI data sharing. And an engineered assurance layer of roughly 20 eval suites: live benchmark, model comparison, drift and judge-calibration gates, replay tests, a quality-regression gate, and release certification where a FAIL gate is never waived and waivers bind to an evidence fingerprint and auto-expire. This is the shape of an OWASP LLM Top 10 and NIST AI RMF posture when it is engineered rather than asserted.
Stack — TypeScript, Hono, Zod and OpenAPI, Drizzle, PostgreSQL (Neon 17), pgvector, Anthropic plus AWS Bedrock, SwiftUI and Mapbox on iOS, Android, a Python data pipeline, Vercel and GitHub Actions CI (15 workflows).
Production status — Backend and marketing site live in production; iOS in TestFlight beta ahead of a deliberate quiet public launch. Real production telemetry flowing; 1,435 backend tests green at the launch snapshot. We do not publish user or revenue numbers — the launch is intentionally quiet.
What this proves — We run our own AI product with the same assurance rigor we sell: evaluate and red-team the AI, harden it to production, and operate it safely, evidenced in code rather than slides. It is also where our assessment method lives before we bring it to a client. This maps to the readiness assessment and to Build and Run.
Multi-tenant building-management SaaS (client, prototype)
Problem — An operator needed to replace an entrenched incumbent platform with a custom, custom-branded, multi-tenant system, and needed to see and trust the product before committing to a full build.
What we built — A high-fidelity, RTL, mobile-first clickable product demo covering the full operator surface: dashboard, buildings and units, dues collections and dunning, maintenance ticketing (kanban and mobile), and multi-channel resident communications, delivered with a complete production architecture and delivery plan.
What was risky — Two things, honestly. A demo built fast can hide the hard production concerns behind mock data; and the real system’s stakes are tenancy (one building must never see another’s data), money movement (dues collection and standing orders), and messaging compliance.
What we designed against — Tenancy scoped as a security boundary from the start: dual-layer isolation (an application-level filter plus Postgres row-level security) with per-customer subdomains and wildcard TLS, not an app-level filter bolted on later. Payment flows designed idempotent and reconciled: verified webhooks, tokenized recurring charges, and a daily reconciliation cron against the gateway’s report API. Official-API-only messaging, with no ToS-violating WhatsApp gateways. And adversarial Codex review paired into every build lane, which caught and fixed HIGH-severity bugs before merge. To be clear: the running demo carries no auth, tenancy, or payments by design; the hardening above is scoped in the plan, not yet production code.
Stack — Next.js 16, React 19, TypeScript, Tailwind v4, Vercel. Planned backend: PostgreSQL and Prisma with row-level security, S3, a verified and idempotent payments integration, and the Meta WhatsApp Cloud API.
Production status — Interactive prototype plus a signed-ready build plan. No live users; not deployed as a production product. We label it that way on purpose.
What this proves — We convert a spec into a convincing, production-shaped product fast, and we scope the hard parts (multi-tenancy, payments, compliance) before a line of production code ships. This maps to Prototype to Production Hardening.
Under NDA
We anonymize on purpose. Client names, domains, and commercial terms appear nowhere on this page. faben is our own product, so we name it; everything else is deliberately unnamed. Client names are shared only with written permission, and every claim here — every finding count, every migration, every live probe — is verifiable under NDA.
If you want to see the evidence for your own review, start with the sample assessment report, read how we work, then request the underlying traces under NDA.