I build
Six things shipped on my own time.
Designing a product and running one are different jobs. These are the second kind: I wrote the code, wired the backends, talked to the users, and read the logs. Each one says what stage it is actually at, and each one names what got cut.
Every claim below was read off the repo or the live site between 12 and 28 October 2026. Nothing here is a projection.
Where each one stands
Stage, not spin
- 2026Live, early accessRiznar landing page: see what every rep actually sold, with a Telegram order message turning into a GST bill
Riznar
Field sales intelligence for Indian commodity distributors: reps send Hinglish voice notes and text orders to a Telegram group, and Riznar turns them into priced invoices, an owner dashboard, a Monday digest and GST e-invoices.
The problem
An owner of a rice, atta or oil distribution business doesn't know what the reps sold today. Orders live as loose messages and get re-keyed by hand into invoices and GST filings.
What's actually built
- The whole loop is wired end to end: Telegram webhook, Whisper transcription, Claude extraction, a deterministic check against the product catalogue, Supabase, and the parsed order echoed back to the group so reps self-correct. Owners can send an accountant a read-only report link.
- The quantity grammar reps actually use. '47 kg 15 bori @1348' is fifteen packs at 1348, never 47 units. Brand misspellings collapse with Levenshtein matching. 107 assertions in two test files (95 on extraction and the money path, 12 on shop de-duplication) run on every push to main.
- GST e-invoicing through a GSP, with taxpayer credentials stored AES-256-GCM and test IRNs hard-blocked on live keys.
- Redesigned in October as Bahi: two inks and one marigold highlighter across the app, landing page, login and share links. The landing hero now plays the Telegram message turning into a bill. 402 commits on main between March and 8 October 2026.
What got cut
It started in March as a B2B deal-intelligence landing page with a waitlist. By May the field-sales problem was clearly the real one, and the deal-intelligence idea was cut entirely. The 45-case LLM eval of the extraction prompt is run by hand and is not part of CI, and at least one September prompt change (#130) shipped without a run. It's live with pricing on the page. No paying customer is on record, so that claim isn't made.
- Stack
- Vanilla HTML/JS with no build step, Node serverless on Vercel, Supabase, Claude, Whisper, Telegram Bot API, pdf-lib
- Evidence
- Measured
- 2026Live, invite-onlyUpranked client dashboard on the Volt design system: ratings, requests sent, and what the reviews say
The product's own demo mode with made-up data, run locally. The live app is behind a login.
Upranked
An invite-only review platform for local businesses. A business asks customers for a Google review by WhatsApp or email, watches each request move from sent to rated to clicked through, replies to Google reviews from the dashboard, and reads the patterns across its reviews on one overview.
The problem
A local business lives or dies on how it looks in Google search, and most have no loop to ask for reviews, no way to see which requests went anywhere, and no habit of replying. Nothing in the product is tied to a trade; it works for any place with a Google profile.
What's actually built
- WhatsApp review requests through Meta's Cloud API, with delivered, read and failed coming back from Meta's webhook. The webhook's HMAC signature is checked before the body is trusted, and a funnel (sent, delivered, read, opened, rated, clicked to Google) never rises between steps. 13 funnel tests and 6 signature tests.
- Replying to Google reviews from the dashboard through the Business Profile API. Google moderates replies, so each shows as live, waiting or rejected with the reason, and a rejected reply never looks published. Google's 4096-byte limit is counted in bytes, so Hindi and emoji don't slip past it.
- An insights panel on the overview: rating trend, recurring complaints, praise, and low ratings still waiting for a reply. Reviews are tagged in the browser with word lists and negation handling, replacing a Claude call that needed a key, a cron job and a migration. Quotes are copied from the review text, never written.
- Self-serve billing on Dodo Payments, priced in rupees: pick a plan, switch with proration, and a client can only ever act on their own record. Redesigned on the Volt design system on 5 October with no backend call changed.
What got cut
It removed its own review gating. The first version sent 4 and 5 star ratings to Google and kept low ones private. On 25 September and again on 10 October that was stripped out, because steering unhappy customers away from Google is gating: every customer is now offered Google, and a low rating gets an equal private-feedback button beside it. Google approved the Business Profile API on 5 October, after a wait that ran from August, so reviews import on their own now. Still invite-only with no public sign-up, and no revenue is claimed.
- Stack
- React 19, Vite, Supabase with Deno edge functions, Google Business Profile and Places APIs, Meta WhatsApp Cloud API, Dodo Payments, Resend
- Evidence
- Measured
- 2026LiveCaloday landing page: let people book you, not your morning walk, with a day timeline of protected, booked and open blocks
Caloday
A booking link that respects your routines. A host sets weekly availability plus recurring blocks like gym or deep work, and guests only ever see the slots left after both are removed, and after the times the host is busy in Google Calendar.
The problem
Sharing one scheduling link without exposing personal time. Existing tools treat every free hour as bookable.
What's actually built
- Slot availability computed as the availability window minus routine blocks minus confirmed bookings minus busy times from Google, with buffer time enforced by interval-overlap maths.
- Google Calendar in both directions with the narrowest permissions that work: busy times only, never event titles, cut to the hours the host offers, and cut off after 4 seconds so Google can't slow the booking page. Since 11 October each booking is also written to the host's calendar and removed on cancel, through a ledger that makes a repeat do nothing and never puts back an event the host deleted.
- Row-level security done properly: profiles publicly readable by slug, anyone can book, only the host can read or cancel, and the Google refresh token is readable by nobody but the server. Four test suites cover calendar events, the Google path, the database rules and the browser flows.
- A design language called Dusk Field: daylight is bookable, dusk is protected, and one pink afterglow marks the single key action. Host booking pages are fully brandable at no cost.
What got cut
There is no paid tier yet. Pro is a planned list on the Pricing page with a waitlist, and Google Calendar busy times were made free on purpose after reading Calendly's and Cal.com's free plans on 6 October. The repo's own comparison says where Caloday loses: one event type, no payments, fewer integrations. The Google connection was built and demoed in Google's Testing mode; the repo holds a checklist for Google's review, not a record that it passed.
- Stack
- React 18, Vite, Supabase with Deno edge functions, Google Calendar API, Resend
- Evidence
- Measured
- 2026LiveCandid's public map of Bengaluru in its locked state: median rents by area, individual rents blurred, and the headline 'Rent shouldn't be a secret.'
The public map as a first-time visitor sees it, locked: individual rents stay blurred until you add your own. The clip moves from Bengaluru to New York to London.
Candid
A rent map where nobody has to guess what the neighbors pay. Rents stay blurred until you add your own, then the map opens, with live maps for Bengaluru, the Bay Area, London, New York, Dublin and Berlin.
The problem
Asking prices are everywhere and what people actually pay is not, so someone about to sign a lease has no honest number to hold it against. Candid asks people to add what they pay, anonymously, and until enough do, the map runs on asking rents read from public listings.
What's actually built
- The lock is real, not a blur. The first version bundled the whole seed CSV into the page, so anyone could copy every rent from the source. It now ships a thin copy with stand-in prices, and the real figures sit in a table no client can read, handed out as a counted, capped page to someone who has added a rent, or as a small daily peek. Public city and neighborhood pages show a median only where 20 or more rents stand behind it.
- Safety read against the live project on 8 October: row level security on every table, each rent checked before anyone else can see it, public pins moved 100 to 199 m by a secret salt, and a Content-Security-Policy the build verifies every time. The review read policy and grant metadata only, never user data, and a secret scan of the whole git history found nothing. Ratings, open to members in Bengaluru since 5 November, follow the same rule: a member's answers are theirs alone, and combined ratings show only past groups of 10 for an area and 3 for a building.
- Four agents on scheduled GitHub Actions, each with a person in the loop. A Reddit scout reads renter threads and drafts replies to Slack for Charan to post by hand. An SEO agent reads Search Console and Bing and files a weekly digest issue. A LinkedIn drafter proposes posts and publishes only what is approved with a reaction, and a newsletter agent sends only on approval.
- 423 commits on main and 120 merged pull requests between 28 September and 5 November 2026. Vercel's build runs the whole suite, 1,234 tests in 105 files, before it builds, so a failing test stops the deploy. Eight promo videos are rendered with Remotion from the app's own components, and city and neighborhood pages are prerendered at build for groups of 20 or more rents.
What got cut
Most of the map is not members. Of 1,383 seed rents across nine cities, 1,379 are asking rents read from public listings, not what tenants pay, against 15 rents members had added by 28 October; yet the homepage still says 'what people really pay' and the city pages call listing rents 'reported'. The gate can be passed with an invented rent, and Candid's own 14 October draft says so; a way in for people who are only looking is proposed and not built, and so is a way to age out old rents. Bengaluru's months on seed rents are invented. The agents are quieter than they look: the LinkedIn drafter has never published a post, because every publish run since 18 October has failed on a missing Slack permission; the Reddit scout cannot read the Slack reactions it learns from; and the newsletter is still a dry run. GitHub Actions marks those runs green, so the failures show only in the agents' own logs.
- Stack
- Vite, React 19 and TypeScript, MapLibre GL on OpenFreeMap tiles, Supabase with row level security and Deno edge functions, Vercel, GitHub Actions, Remotion, Claude for the agents' drafts
- Evidence
- Measured
- 2026Live, preview URL
Reform
Public data on India's rural welfare schemes, explained in plain language and shown only where a number traces to a named government source.
The problem
Data on MGNREGA, PMAY-G and DAY-NRLM is spread across dashboards, Acts, CAG audits and press releases, with mislabelled units and state breakdowns that don't add up.
What's actually built
- Calls the Ministry of Rural Development dashboard's own JSON endpoint directly, the one its charts use, and found it's shared across schemes.
- Caught a unit error in the government's own data: four money KPIs arrive in lakh while the dashboard labels them crore. Verified against Uttar Pradesh's raw figure, 4.8x the national total, then divided by 100.
- An automated anomaly scan across six KPIs and ten states flags year-over-year swings of 40% or more, then hand-verifies the West Bengal findings against reported fund-suspension coverage.
What got cut
It deliberately withholds data it could not reconcile. PMAY-G's state breakdown and DAY-NRLM's rupee figures are excluded because they summed to impossible national totals, one year of one fund exceeding India's GDP. Headcount figures stayed because they landed within 0.02% of the all-India number. It's on a Vercel preview URL, not a domain, with no remote git yet.
- Stack
- Next.js 16, React 19, Tailwind v4, hand-built SVG India choropleth, no database
- Evidence
- Measured
- 2026Prototype
Apex
A real-time ranking game where players burn money per second as thrust to climb, and the score is seconds held above a line that solo spending cannot reach. To cross it you draft in a rival's wake or form a pact.
The problem
Pay-to-rank leaderboards sell a static position: no event to watch, no counterplay once outbid, and the deepest pocket holds first forever.
What's actually built
- The design rests on a measurable claim: the line at 110 km sits above the solo max-burn ceiling of 104.4 km. In headless 600-second runs the whale rival spends about $1,118 and holds the line for 1.3 seconds; towed craft hold up to 32.3.
- A tuning fix found by measurement, not feel: classifying every failed tow showed the wake was too short. Lengthening it moved a competent player from 0 to 32 seconds on the line while the whale stayed at zero.
- A 12-second forward trajectory integration drives both the predicted arcs and a collision alert with countdown.
What got cut
It's a prototype and the README says so. Continuous real-money burn resembles a penny auction, and it would need spend caps before taking a cent. Nobody has paid anything.
- Stack
- Vanilla JavaScript, Canvas 2D, a Node build script that inlines everything. No framework.
- Evidence
- Measured
None of these has a marketing number on it because none of them has earned one yet. What they have is working code, real users where stated, and a clear account of what isn't done. That is the same standard the design work on this site is held to.