01 / OrderDeskOrders & inventory
One item left.
Two customers.
What happens?
The business problem
Two people can ask for the same stock. A payment can time out. A repeated click should not become a second order.
OrderDesk connects stock reservations, payment states, and an order timeline so those decisions stay consistent.
Browser simulation Synthetic orders · no payments
DESK LAMP / AVAILABLE1unit
▦
REQUEST AReady to request
REQUEST BReady to request
One unit available. Two example customers.
See the decision log
- One unit available. Two example customers.
DESIGN CHOICEReserve stock and record the order together in one transaction.
FAILURE PATHA durable payment key makes a timeout retry repeat-safe.
BOUNDARY / NEXT STEPLocal, single-process app. Payments and fulfillment are simulated. Multi-instance concurrency and a real payment provider remain future work.
Implementation & evidence +
Full-stack implementation
ASP.NET Core 10, React/TypeScript, EF Core, and SQLite. A per-process command gate and a database constraint protect stock. Owner/operator roles control order actions.
Recorded local verification
5 xUnit tests and 1 browser test passed in the existing application verification. Coverage includes concurrent reservations, idempotency, restart-persistent payment retry, and shipment rules.
02 / TeamFlowTeam coordination
Who owns
the next step?
The business problem
When a task changes, the next person needs the same picture of the work. Keeping a board current matters as much as creating one.
TeamFlow connects task status, comments, and permissions in a shared workspace that updates across sessions.
Browser simulation Two illustrated views
EEditor’s viewCan update
To doDoingDone
LAUNCH CHECKLISTReview the handoff notesTo do
⇅ Shared state
VViewer’s viewRead only
SAME TASKReview the handoff notesTo do
Both illustrated views show the same task. Try moving it.
These two cards mirror state on this page. The real application’s SignalR updates were checked in two local browser sessions.
DESIGN CHOICEPush change notifications through SignalR; refresh the shared board data.
FAILURE PATHCheck permissions and task versions before accepting a change.
BOUNDARY / NEXT STEPLocal, single-process app with synthetic accounts. Production identity, invitations, and multi-instance hosting remain future work.
Implementation & evidence +
Full-stack implementation
ASP.NET Core 10, React/TypeScript, React Query, SignalR, EF Core, and SQLite. Membership checks protect board operations and SignalR group joins.
Recorded local verification
3 xUnit and 2 browser tests passed in the existing application verification, including synchronization between editor and viewer sessions, drag-and-drop, comments, and persistence.
03 / DocuLensDocument workflows
Find the answer.
See the source.
The business problem
A useful answer needs a trail back to the document. An unreadable file needs a visible failure, not an invented response.
DocuLens extracts document text, searches an owner’s library, and links verbatim previews to their source.
Browser walkthrough Synthetic document · no AI calls
≡Operations handoffSample text / 3 source lines
TXT - The launch checklist is owned by the operations lead.
- Support responds to new requests within two business days.
- The delivery team records handoff notes before closing a request.
Try:
EXTRACTIVE RESULTSearch a word to find a verbatim excerpt from the text above.
Search runs only against these three lines. No file upload, generated answer, or connection to the local application.
DESIGN CHOICEStore source text and offsets so every extractive preview stays traceable.
FAILURE PATHPersist processing states, expose failures, and bound retry attempts.
BOUNDARY / NEXT STEPKeyword search and cited excerpts, not generative AI. OCR, larger-library indexing, and production upload hardening remain future work.
Implementation & evidence +
Full-stack implementation
ASP.NET Core 10, React/TypeScript, PdfPig, DOCX XML parsing, and SQLite. A durable queue requeues interrupted processing; search and downloads stay owner-scoped.
Recorded local verification
5 xUnit tests and 1 browser test passed in the existing application verification. Checks cover real parsing, source grounding, owner isolation, bounded retries, and persistence.
04 / ClipForge
Turn a long video into shorter clips.
A local pipeline for transcription, moment selection, vertical reframing, and captions.
Inside the build +
The workflow
- Ingest a video file or URL.
- Transcribe and rank candidate moments.
- Reframe to 9:16 and animate captions.
- Export MP4, SRT, XML, or EDL.
The decisions
Connect the media stages into one usable local workflow. Optional model integrations strengthen ranking, while a heuristic fallback keeps the core pipeline usable without them.
Brand presets, thumbnails, audio enhancement, optional B-roll, voice-over, and YouTube scheduling extend the pipeline.
Build notes
My role: independent builder, working with Codex.
An end-to-end development sample produced a 1080 × 1920 clip with burned-in captions. External publishing integrations depend on configuration.
05 / JobClaw
Connect the steps of a job search.
A workspace for discovered roles, matching, resume preparation, and application tracking.
Inside the build +
The workflow
Collect roles, match them against a profile, and prepare tailored resumes. The workspace tracks applications, resume generation, and plan usage.
The architecture
FastAPI serves Jinja templates. Background schedules coordinate collection and generation; Claude integrations support matching and tailoring. SQLite supports local runs, with PostgreSQL configured for hosted use.
Private repository · access required in a new tabVerified locally
Seven existing product tests passed, covering routes, dashboard rendering, authentication fixtures, and source controls. The screenshot comes from the running app.
Live collection, Claude calls, resume generation, and production deployment were outside this verification.
06 / Webull AI Trading Bot
Make a research decision inspectable.
Trade ideas pass through independent risk checks and leave an offline report. No live performance claim.
Open synthetic sample report ↗(opens in a new tab)Inside the trading system +
Research before execution
Paper and replay modes use synthetic data by default. Opening-range breakout backtests accept minute-bar CSV data or an optional Databento historical feed with a download cost cap.
Strategy research includes multiple seeds, slippage stress tests, and simulated market regimes.
Independent risk checks
The risk engine checks confidence, sizing, eligible symbols, trading windows, and configured loss limits. An optional LLM can produce ideas; a deterministic fallback is also implemented.
The Webull adapter has order previews and a separately enabled execution path.
What this sample verifies
Three offline inputs were rejected by the actual risk engine and passed to its HTML report renderer. These component checks cover low confidence, invalid quantity, and missing data.
They are not an end-to-end trading test or evidence of live performance or profitability.
How I approach the work
Make it understandable.
Then make it dependable.
- 01
Understand the workflow
Who needs to do what, and what tells them it’s done?
- 02
Find the bottleneck
Look for a repeated step, an unclear handoff, or a decision that can go wrong.
- 03
Build a small solution
Connect a usable interface to the rules and data that make the flow work.
- 04
Test the rough edges
Check the normal path, then retries, permissions, competing updates, and restarts.
Behind the work
Madhav Kadiyala.
From a useful idea
to a working system.
I’m interested in the space between “we keep doing this manually” and a tool people can actually use.
I build full-stack applications and workflow automation with Codex, connecting interfaces, application logic, and data. These independent projects show the workflows I’ve implemented and the checks recorded in their local verification.
I want to keep growing through work where understanding the process matters as much as writing the software.