Ship a small version first, then harden it.
A focused first version meets reality early. What traffic, use and failure reveal becomes the specification for the durable version.
- 01Scope
- 02Release
- 03Harden
01 · How I work
Two rules I keep returning to.
Small loops. Observable behaviour. Clear limits.Reproduce the failure before changing the system.
A failing system exposes assumptions. I observe the real conditions, isolate the smallest cause and reproduce it before I change anything.
- 01Observe
- 02Isolate
- 03Reproduce
Diagnostic sequenceShip small → Failure observed → Reproduce → Harden → Verify.
Ship smallFailure observedReproduceHardenVerify
Three independent tracesFailure → reproduced → verified fix
TrackSystemFailure observedReproducedVerified
01Release pathClean install failedFresh install reproducedPackage path verified
02Data volumeRun interruptedInterrupted run replayedCheckpoint resumed
03External actionDuplicate triggerDuplicate trigger reproducedClaim then verify
02 · Experience
Engineering roles, with the boundaries clear.
Public affiliations and private implementation are labelled once.Current role
Stealth Startup
Founder & Engineer
I am building a multi-agent AI platform for an overlooked corner of US public-sector procurement.
- Multi-agent AI
- US public-sector procurement
- Product engineering
- System design
The company operates in stealth. My role and problem area are public; product mechanics, customers, users, results and source code remain private.
Open technical record+
An overlooked procurement problem space
The current build focuses on an overlooked corner of US public-sector procurement.
Founder & Engineer
I own the product and engineering work for the stealth startup.
Public scope, private mechanics
The company is in stealth, so product mechanics, customers, users, results and source code are not published here.
Experience
CaboCab
CTO and Technical Lead (Founding Team)
I led technical direction for a Node.js and MySQL mobility platform across trip recovery, cross-platform messaging, routing, monitoring and support escalation.
- Node.js / MySQL platform
- Private chat SDK
- Docker / OSRM
- Operations
My former founding-team role is public. The incident details below are my account of private company work, with team outcomes kept separate from my own decisions.
Open technical record+
Trips through connectivity loss
I added a local write queue and reconnection sync so trip data could recover after the network returned.
One messaging layer across four surfaces
I built the private chat SDK across a FastAPI and PostgreSQL backend plus web, iOS and Android surfaces. UUID identities and idempotency keys bounded retries, and I traced an idle WebSocket leak that left driver and customer connections open after an admin link closed.
Road distance instead of a straight line
A reported 5 to 10 percent route discrepancy led me to self-host OSRM in Docker and map GPS traces back to the road network.
Costs, outages and driver feedback
I traced a Maps call anomaly reported at roughly ₹12,000 a day, extended monitoring across ten services, and built escalation through WhatsApp, email and a final Twilio call. A separate WhatsApp feedback flow sent driver photos directly to S3 for support teams across six districts.
Selected work
Three inspectable systems: a public release, a testnet assessment and a bounded public-fork contribution.
01vulntriageA Python CLI that enriches pip-audit findings with NVD, CISA KEV and EPSS signals, then uses a chosen LLM backend to produce a ranked first-pass fix list.Public package · v0.15.2Published open source
Engineering problem
Raw severity can leave a developer with a long flat list and no useful first move. The tool needed to add threat context and likely-reachability reasoning without presenting an LLM heuristic as a proven call graph.
Work owned
- Built and published the Python package on top of pip-audit.
- Integrated NVD, CISA KEV and EPSS, with authoritative NVD scores overriding model output.
- Added API, subscription-CLI and local Ollama providers behind one ranking boundary.
- Documented clean-install failures, yanked the broken releases and published the corrected v0.15.2 package.
02Binance testnet botAn assessment build for Binance Futures Testnet with Decimal validation, recorded testnet orders and a SQLite dashboard.Public assessment buildAssessment · testnet only
Engineering problem
A trading workflow needs precise input validation and observable failure handling before its order lifecycle can be trusted even in a test environment.
Work owned
- Implemented Decimal-based validation around testnet orders.
- Recorded real Binance Futures Testnet orders instead of stopping at a mocked interface.
- Built the SQLite dashboard and four direct test modules.
03HaqA voice-first welfare-benefits guide for construction workers across four Indian states, designed for low-literacy use and multilingual access.Private build · Aug 2026Private welfare guide
Engineering problem
Workers need understandable guidance on changing welfare rules without an app pretending to make a legal eligibility decision or connect to a government system.
Work owned
- Built the deterministic eligibility, work-history and guidance flows for four state contexts.
- Implemented eight-language access with static and runtime speech support.
- Added the cited-answer and explanation boundaries without allowing AI output to decide a worker's eligibility.
Built against the clock
Five verified hackathon and buildathon projects. Event limits, observed repository windows, active-build state and later hardening stay distinct.
01
SHIPPEDprivate hackathon submission
Atlas AI Financial Assistant Hackathon
Atlas
A Telegram-native financial research assistant with durable memory, guarded document intake and evidence-bound answers.
The public demo is reachable; the Telegram profile is public.The source stays private. The 9-10 August release work added a D1 migration runner and a bounded Groq continuity fallback. No GitHub Actions CI workflow is committed.Full record Hosted demonstration Telegram bot
02
3 HOURSevent build limit
Google for Developers PromptWars
Thuna
A bilingual crisis-support prototype that runs deterministic safety triage before a later Gemini-assisted branch.
Placed 19th in PromptWars.Three hours was the event limit. The public 25-commit history includes later hardening and an August documentation refresh; it is not production healthcare software.Full record Source repository Hosted demonstration
03
≤1 DAYinitial afternoon buildathon slice
World's Largest Hermes Buildathon by GrowthX®
Switchboard
A Telegram operations agent that gates real actions with allowlists, durable claims and explicit verification.
The initial buildathon slice was completed in one afternoon.The current 53-commit public repository includes substantial later work: action gates, traces, tests and verification automation. It is not claimed as one afternoon's output.Full record Source repository
04
7 DAYSevent build limit
BlockseBlock Hackathon · Track 2
Civic Hero
A deployed mobile-first civic-reporting prototype with assisted triage, a live feed and community verification.
Completed and deployed as a hackathon demonstration.Seven days was the event limit, not the repository window. The source remains private; the live demonstration is public and the audited repository has no automated test suite.Full record Live demonstration
05
7 DAYSevent build limit
Band of Agents Hackathon · Track 3
ClaimBand
A four-agent insurance-claim prototype with validated shared state and an inspectable approve, deny or escalate trail.
Completed as a traceable hackathon prototype with four agents.Seven days was the event limit. The public history contains 13 submission-period commits plus a later documentation refresh; no accuracy or regulatory-fitness claim is made.Full record Source repository
Timing and evidence
Each large label states a verified event limit, an observed repository window or an active-build state; the qualifier says which. Public evidence is linked directly. Private source stays private, and post-event work is not folded into the initial build claim.
Client deliveries
Two client briefs, with the scope, constraints and evidence kept intact.
Freelance web developer
Morsel
Led the Next.js implementation of Morsel’s live site, including its responsive component system, motion, custom brand graphics and deployment.
Open delivery record+
Brief
The client supplied one HTML reference. I translated it into a ground-up Next.js component system, then carried the site through responsive motion, custom brand assets and deployment.
Work owned
- Led the ground-up Next.js and responsive component implementation.
- Built the motion and custom SVG/logo tooling used by the delivered site.
- Prepared and completed the live deployment.
- Submitted the deployed site for Google Search Console indexing.
Constraint
I led 44 of the private repository’s 57 commits and continued iterating with the client owner. No client testimonial or business-impact metric is public.
Evidence
The live site can be inspected. The delivery history supports a Nivish-led build with continued client collaboration, not a solo claim.
Freelance developer
Scraper
Reworked a bulk-image workflow with constant-time lookups, retries and checkpoints so interrupted work could resume.
Open delivery record+
Brief
The original run reportedly failed around row 60,000. Linear lookups and no durable progress record meant a restart could repeat hours of work.
Work owned
- Replaced repeated linear lookups with set-based constant-time checks.
- Added per-row checkpoints, resume behaviour and retry rounds.
- Built multi-worker Chromium flows and a Next.js operator interface with Server-Sent Events progress.
Constraint
The public code targets datasets from 10,000 to 200,000+ rows, but the delivered volume and client outcome remain self-reported.
Evidence
The repository is public and shows the worker, retry and operator paths. It has no committed automated test suite.
Current experiment
One public work in progress, kept separate from completed client, assessment and hackathon records.
Open-source work in progress
Strava workflow
A Telegram training bot that turns Strava activities into split, pace, heart-rate and trend views with SQLite-backed OAuth state.
- Python
- Telegram
- Strava API
Tools, attached to work
The stack matters when it explains a decision, not when it fills a logo wall.
Frontend proof - this portfolio
- ReactInterface architecture and state
- Next.jsRouting, rendering and contact endpoint
- Three.jsDemand-rendered WebGL hero
- GSAPSection-local scroll choreography
- MotionTouch-safe interface feedback
Backend and reliability
- Node.jsCaboCab platform · Switchboard
- MySQLCaboCab platform
- DockerCaboCab OSRM · Civic Hero
- Pythonvulntriage · Scraper
- FastAPICaboCab private chat SDK · Strava OAuth · Binance dashboard
- PostgreSQLCaboCab private chat SDK
Full‑stack and data
- TypeScriptHaq · Switchboard · Thuna · Civic Hero
- Next.jsHaq · Thuna · Atlas · Scraper
- SQLiteStrava workflow · Binance Futures Testnet bot
- ConvexSwitchboard
- UUID identitiesCaboCab private chat SDK
APIs and automation
- NVD, CISA KEV and EPSSvulntriage
- TelegramSwitchboard · Atlas · Strava training bot
- Strava APIStrava workflow
- Binance Futures TestnetBinance Futures Testnet bot
- GeminiThuna · Civic Hero
- OpenAI APIHaq · Boring Job
- SarvamHaq
About the engineer
The person, the work history and the learning behind the interface.
Nagercoil, Tamil Nadu
I build multi-agent AI platforms and real-time systems, then test them against the conditions that break them.
I am currently building a multi-agent AI platform for an overlooked corner of US public-sector procurement.
I work across the whole path from system design and backend behaviour to the interface people use to operate it.
B.E. Computer Science and Engineering
Loyola Institute of Technology and Science, Thovalai
CGPA 8.18/10self-reported
Coursework, kept in proportion
Open roles
Five ways I’m open to work. The best fit has clear ownership, hard constraints and a system worth making dependable.
- BackendAPIs, realtime systems, data workflows and recovery paths.Send context
- Full‑stackBackend behaviour through the interface people use to operate it.Send context
- Technical leadHands-on architecture, delivery and engineering direction.Send context
- Founding engineerEarly product systems with broad technical ownership.Send context
- FreelanceBounded builds, difficult integrations and recovery work.Send context
10 / Start a conversation
Have a difficult build?Let’s make it work.
Send the system, constraints, ownership and what success must look like. I will reply by email.
nivishv2004@gmail.comLinkedInGitHub