In production

Shipped — real money, real users.

06 / built & deployed
The build

A Colombo IT distribution firm quoted everything by hand across Odoo and spreadsheets — slow, and wrong often enough to matter, because Sri Lanka's 2026 import-tax regime is a multi-layer cascade that behaves differently for distributor hardware, direct imports, and services. Axis CRM replaces that with a purpose-built system: a quote builder wired to a tax engine I reconciled, to the cent, against fourteen of the firm's own real bills of quantity. Pipeline, quoting, PDF generation, approvals, vendor purchase orders, and automated bank-rate fetching all run on one Supabase backend, deployed and in the client's hands.

What's live
  • Import-tax engine — SSCL + VAT universal, with CID / PAL / ICL gated to direct imports — reconciled to the cent across all 14 BOQ blocks, where it caught roughly a one-third overcharge the old cascade had been applying
  • Quote builder with dual LKR / USD, a live bank-rate bar (pg_cron three times daily), and BOQ file import that extracts line items for per-line pricing
  • 22 Postgres migrations, 13+ tables, row-level security pentested 36/36 green — blocks privilege escalation, anonymous data leaks, and forged audit rows
  • Six Deno Edge Functions (quote send, PO dispatch, notifications, invite) with owner / role authorization and idempotent email logging
  • Realtime Kanban pipeline, a deal drawer for meetings and next-steps, and a reporting dashboard with KPI charts and xlsx / PDF export
  • ~59 unit and property tests green — the tax math fuzzed across ~40,000 cases — under strict TypeScript
Exact to the cent The hard part wasn't the software; it was the tax law. The first engine confidently applied the wrong cascade. The fix came from treating the client's own bills of quantity as ground truth and reconciling against them line by line until every block matched to the cent — then gating the import-only layers behind an explicit per-line flag rather than a guess.
StackReact 19 · Vite · TypeScript · Supabase (Postgres · RLS · Realtime · Deno Edge · pg_cron) · Resend · Vercel · Cloudflare · react-pdf · exceljs · Sentry · Claude
Built for a Colombo IT distribution firm · private client deployment
The build

Trading-card sellers run "claim sales" in WhatsApp groups: post a card, first to reply mine wins it. It works, but the seller's side is brutal — tracking claims, backups, multi-quantity lots, totals, and per-buyer invoices by hand. ClaimFlow automates all of it without changing the buyer experience at all. A linked-device bridge reads claims straight from the group and reacts to confirm them, a realtime catalog shows live claimed / available state, and an AI scanner turns a pile of card photos into priced, listed lots.

What's live
  • AI card scanner — Claude Haiku 4.5 vision reads each card, cross-references the collector number against pokémontcg.io, and translates Japanese cards to English; drop a stack of photos and it builds priced lots automatically
  • WhatsApp device bridge (whatsapp-web.js) that reads claims from the real group and confirms them with reactions — buyers never change how they buy
  • Realtime catalog with live claimed / available badges, buyer-total lookup, and a password-protected admin dashboard
  • First-come-by-timestamp resolution, backups, multi-quantity stock decrement, and a sale close that posts a tagged group summary plus individual DM invoices
  • Security-definer RPCs gated by a hashed admin key, server-side rate limiting on the AI endpoint, deployed to Netlify and Cloudflare Pages on a custom domain
Automate the seller, not the buyer The discipline was leaving the buyer experience completely untouched. The temptation is to build a slick new interface and force everyone onto it; here the entire value was that buyers keep claiming in the same group, the same way, while every painful part of the seller's job disappears behind the scenes.
StackSupabase (Postgres · RPCs · Edge Functions · Storage · Realtime) · Claude Haiku 4.5 (vision) · pokémontcg.io · whatsapp-web.js · Netlify · Cloudflare Pages · vanilla JS
Live product — ClaimFlow by HoloCandy Co. · in a customer's hands
The upgrade

Second Brain (in Research, below) proved the thesis on a Drive-and-Obsidian prototype. Agentic CMS is what it became when I rebuilt it as a real product. Same idea — your AI's working memory, not a passive archive — but now on a proper database: 829 session summaries parsed and bucketed, full-text searchable, with a live key-gated control panel that captures ideas and surfaces context from anywhere. It's the grounding layer behind every other build on this page.

What's operating
  • 829 AI-session summaries across 18 buckets, full-text searchable — the reference layer behind every project here
  • Rebuilt from the Drive / Obsidian prototype onto Supabase Postgres with a real schema, row-level security, and full-text search
  • A live, key-gated control-panel Edge Function — quick-capture to an inbox and context lookup from any device
  • Productized and sold at $199, delivered over a local payment rail
Prototype → product Second Brain worked, but it was only as alive as my own discipline around a folder of files. Productizing it meant moving to storage an agent is a first-class citizen in, giving it a real schema and search, and putting a control panel on top — so the working memory is something you use, not something you maintain.
StackSupabase (Postgres · RLS · full-text search · Edge Functions) · key-gated control panel · Claude · local payment rail
Live product · $199 — the productized successor to Second Brain
The build

The way to win a small-business pitch is to show, not tell — so for a repair-shop prospect I built and shipped a complete demo site in a day. The interesting part was the research: the brief assumed a retail / gadget angle, but reading the prospect's own public footprint — listings, reviews, socials — made clear they were a repair-and-servicing business, not a retailer. So I rebuilt the site around that truth, filled it with real verified details, and deployed it to a custom subdomain on a throwaway edge worker, ready to hand over at the meeting.

What shipped
  • Research-corrected positioning (retail → repair) drawn from the prospect's own listings, reviews, and socials — instinct verified against the evidence
  • A mobile-first single-file site with WhatsApp-primary calls to action and a config object, so no placeholder ever renders as a fake fact
  • AI-generated hero (Higgsfield) and a one-command deploy to a custom subdomain on a Cloudflare Worker with automatic DNS and certificate
  • Drafted, critiqued, rebuilt, and QA'd in a single day — a cold prospect turned into a tangible pitch overnight
Research beats the brief The temptation was to build exactly what was asked for. Reading the prospect's real public footprint changed the whole premise — they were a repair shop, not a retailer — and the demo only landed because it reflected who they actually are.
StackCloudflare Worker (static assets) · Higgsfield AI (hero) · single-file HTML / CSS · WhatsApp CTAs · Wrangler
Built for a prospect pitch · deployed in a day on a throwaway subdomain
The build

Running several builds, a day job, and a business at once outgrew what any single AI chat could hold. So I built an operating system for it: a standing board of advisors that convenes on a cadence to pressure-test decisions, and a personal assistant that captures ideas, triages an inbox, and plans the day across thirteen work and life streams. Both read from one security-locked database and surface through a live, key-gated control panel. Scheduled cloud agents fire a daily standup and a weekly briefing on their own — correctly, across a 9.5-hour gap between the host clock and where I actually live.

What's operating
  • A five-seat advisory board (chair, strategist, capital allocator, operator, physician) that convenes weekly and on demand, with a deliberate brutal-candor mandate
  • A personal-assistant agent — capture, triage, daily planning — across 13 streams, where board commitments outrank day-to-day tasks
  • One Supabase backend (RLS-locked tables) feeding a live key-gated control-panel Edge Function
  • Scheduled cloud agents: a 07:00 standup, a Monday week-ahead briefing, and a Sunday board meeting — cron written in host time to land at the right Colombo wall-clock
An OS, not an assistant The unlock was treating this as infrastructure, not conversation. A shared database, scheduled agents, and a live panel turned a pile of good intentions into a system that runs whether or not I open it. The hardest bug was time itself — the host clock and my real timezone are 9.5 hours apart.
StackSupabase (Postgres · RLS · Edge Functions) · scheduled cloud agents (cron) · Claude Code skills · key-gated control-panel function
Internal · runs daily
The build

Local repair shops — phone, computer, print — are consistently invisible on Google despite strong real-world demand. Mendwell pitches a simple proposition: a professionally built, mobile-fast website with local-SEO foundations, delivered in five days for $79/month. The model is AI-accelerated end-to-end — copy generation, design iteration, and client communication all run through a Claude-powered content pipeline, keeping the unit economics viable at that price.

What's built
  • Cloudflare Worker-hosted sites — self-contained single-file deployment, no external dependencies
  • AI content pipeline: Gemini 2.5 Flash for copy, a structured prompt framework for consistent brand voice across verticals
  • A custom MCP server (Node.js / TypeScript) integrating Google Drive, Sheets, and YouTube for content scheduling and logging
  • Cold-outreach system with jurisdiction-aware email templates, segmented by vertical and market
  • Rapid-response loop: a May-2026 Google local-algorithm shift turned into updated site copy and outreach within 48 hours
Commercial angle The AI tooling isn't the product — it's what makes the economics work. The client gets a real website with real local SEO; the AI is the internal leverage that keeps the price accessible and the delivery time short.
StackCloudflare Workers · Node.js · TypeScript · Google Drive / Sheets / YouTube APIs · Gemini 2.5 Flash · Claude API · custom MCP server
Investigations

Research — the thinking in practice.

05 / research projects
Investigation

Kronos forecasts crypto price as a calibrated probability distribution and uses that distribution to discipline how capital is sized. Out-of-sample testing on a 74-day, 1,800-candle XRP window was unflattering: no directional edge (~48.6% hit rate) and a loss to a naïve volatility baseline — so I cut both uses. The one property that held was calibration (~79% of prices landed inside the 80% band), so the engine now leans on that single verified strength: it sizes off how wide the distribution is, and steps aside ahead of scheduled macro events.

Architecture
  • Forecasting core: TimesFM-2.5 (200M-param, Google Research) run zero-shot with a native quantile head — no fine-tuning pipeline
  • Calibrated quantile envelope as the primary output — validated at ~79% coverage on the 80% band over a 74-day holdout
  • Risk gate: band-width percentile drives a position-size multiplier, with regime-breakout detection and fail-safe handling of stale signals
  • Forward-looking macro layer: a FOMC / CPI / PPI calendar auto-cuts size ahead of scheduled catalysts
  • Automated out-of-sample evaluator grades each forecast at horizon end — coverage, MAE, directional call, worst breach
Calibration over prediction The validation killed the parts that sounded smartest — calling direction, forecasting volatility — and left exactly one thing the model does reliably: quote a well-calibrated range. So the engine no longer pretends to know where price is going; it sizes off how wide the distribution is.
StackPython · PyTorch · TimesFM-2.5 (Google Research) · Hyperliquid SDK · OKX / Binance / Bybit data · SQLite · systemd · Claude
Investigation

Most people's personal data is scattered across fifty-plus brokers that scrape, package, and sell it; manual removal is hours per broker and the records reappear. Privacy Posture applies an AI agent — with human approval gates — to map the PII footprint, draft jurisdiction-correct removal requests, track each through to confirmation, and re-check for reappearance on a schedule. Effectively a small SOC where the analyst is an LLM and the legal-basis library is a template set.

What's operating
  • 49 brokers mapped across 3 priority tiers, with an active opt-out queue
  • 6-template legal framework covering CCPA, GDPR, PDPA, generic, follow-up, and reappearance scenarios
  • SLA logic per framework (CCPA 45d, GDPR 30d, PDPA 21d) with 14- and 90-day reappearance windows
  • Identity-verification minimisation logic that refuses brokers' overreaching ID-upload demands
  • Time-to-draft per opt-out: ~30 seconds, vs. ~10 minutes manual
Lesson worth featuring The original ledger sat in Google Drive, but that connector is effectively read-only for binary files — which breaks the autonomy claim. When building agent-native workflows, choose storage where the agent is a first-class citizen, or you re-introduce the manual steps you were trying to remove.
StackClaude (analyst agent, human-in-the-loop) · MCP (Notion · Gmail) · structured case-management workspace · templated legal-basis library · scheduled OSINT & breach monitoring
Investigation

A research-aide toolkit for solo bug-bounty work, first deployed on HackerOne. The architecture is intentionally split: standard scanners (nuclei, subfinder, httpx) handle execution, while a multi-agent Claude layer — planner, researcher, report-drafter — handles scope parsing, scanner orchestration, and turning collected output plus observations into platform-formatted draft reports for human review.

What's working
  • Multi-agent Claude stack (planner + researcher + report-drafter) orchestrating scanners into platform-formatted drafts
  • Pulls and parses HackerOne scope; validates assets are in-scope before any scanning begins
  • A recon → scan → triage pipeline end-to-end, with findings and drafts flowing through MCP into Notion, Drive, and Gmail
  • Human stays the decision-maker at every consequential step — the tool reduces slow surface area, not judgement
Why it's here Scope Sentinel is the working version of a thesis I bring into commercial conversations: that AI's real leverage is helping one disciplined operator scale the rigour of their own work. The same architecture applies far beyond security research.
StackPython · TypeScript · Claude (multi-agent: planner · researcher · report-drafter) · MCP → Notion · Drive · Gmail · nuclei · subfinder · httpx
Investigation

Before I pull an unfamiliar repo onto my machine, I want a fast read on two separate questions: is this code likely to harm my system, and is the project actually maintained. You paste a public repo URL and it pulls GitHub metadata, scans the source for risky patterns, checks known vulnerabilities against OSV, and runs a semantic check on whether the repo fits what I said I wanted it for. It returns a single-page dossier that deliberately splits a Risk Score from a maintenance Hygiene Score.

What's operating
  • Pulls GitHub metadata: stars, forks, last-commit date, account age, and a bus-factor read for single-maintainer risk
  • Safety scanner flags risky source patterns (eval, obfuscation, suspicious exec/network calls) into a Risk Score
  • Vulnerability lookup against the OSV.dev CVE database
  • Maintenance Posture check (SECURITY.md, CODEOWNERS, Dependabot, tests) scored as a 0–100 Hygiene Score
  • Claude semantic match plus automatic logging to a Google Sheet; installable as a PWA with an offline shell
Two scores, not one The most useful decision was refusing to collapse everything into a single trust number. "Is this code dangerous" and "is this project maintained" are genuinely different questions, and a blended score hides the one you actually need in the moment.
StackSingle-page JS · Tailwind · PWA (service worker + manifest) · GitHub REST API · OSV.dev · Claude API · Google Apps Script · Netlify
Live tool: demo on Netlify · personal utility, repo private
Investigation

Every new AI chat, I re-explained who I am and what we'd decided — and the moment it ended, that was gone. The thesis: a second brain shouldn't be a passive archive but the AI's working memory, structured so an agent can read it on demand and write back. So I built a Drive-based vault organised by entity type, with consistent metadata, an operating manual that tells Claude how to navigate it, and session rituals so nothing useful disappears between conversations.

What's operating
  • Ingested my complete AI chat export — 242 conversations — bucketed into 19 topic areas
  • Synthesised into cross-linked wiki pages with structured metadata and [[wikilinks]] between entities
  • A CLAUDE.md operating manual loaded at the start of every session — identity, rules, routing table, protocols
  • A command-center dashboard tracking open loops and action items across every project, refreshed each session
Memory, not archive The shift that made it work was treating the vault as the AI's working memory rather than my filing cabinet — organised for an agent to use, not just for me to search. It's only as alive as the discipline around it, which is why the rituals matter more than the file count.
StackGoogle Drive · Markdown · YAML frontmatter · Obsidian · Claude Code · MCP · Python · rclone
The prototype · later rebuilt and productized as Agentic CMS (above, in Shipped)
Get in touch

Let's talk about
what you're building.

ryan@gruponugara.com
LinkedIn Colombo, Sri Lanka +94 — Available on request