Three projects, in roughly the order they mattered to me. Each one started as a notebook page.
The existing app was a .NET WebView wrapper — every screen a web page in a mobile costume. Login broke. Checkout failed. The Play Store rating was near 1.8. It was averaging 3.4 orders a day. I rebuilt it alone in 8 weeks. By the end: 58 orders/day, 17×.
The turning point wasn't a single bug. It was reading review after review describing the same frustrations I was seeing myself. At some point I stopped asking "How do we patch this?" and started asking "Why are we making users suffer through this experience?"
Rebuilding became easier to justify than fixing.
The first sketches weren't beautiful. They were boxes, arrows, and notes in a notebook.
One note that survived: "Use only 4–5 buttons in navigation."
I spent more time deciding what to remove than what to add.
Provider wasn't chosen because it was trendy. It was chosen because it was understandable. Bloc could have worked. Riverpod could have worked. But I wasn't trying to win an architecture competition. I was trying to ship a better app.
Caching mattered because users shouldn't wait for data they already downloaded five minutes ago. Performance improvements often come from avoiding work, not doing work faster.
Two things. I underestimated drastically underestimated timelines. And I delayed testing.
When you're rebuilding quickly, shipping features feels like progress. Later, every change becomes harder because you don't have enough confidence in existing behavior.
Speed without verification eventually becomes slow.
The biggest jump didn't come from one feature. It came from reducing friction at the two places users were dropping off: authentication and the view → cart moment.
OTP-first login. Faster product pages. Cached carts. Fewer fields. Each change small. Compounded, they moved orders from 3.4 to 58 a day.
On the platform side, I'm migrating the legacy web stack to Next.js (SSR/SSG) and designing a company-wide microservices architecture — Orders, Cart, Payments, Inventory, User — with event-driven communication. A GraphQL Federation BFF unifies these for web, mobile, and admin. The component library is built on MUI Base and Emotion with strict TypeScript and WCAG 2.1 AA baked in. First release cycle retired 30+ one-off components and cut page load by ~40%; the BFF alone cut JS payload by ~35%.
B2B fintech. I joined as a Frontend Developer, ended up shaping API contracts, the design system, and a reconciliation pipeline that cut a finance team's manual work by 4–5×.
ⓘ A UTR is the Unique Transaction Reference on a bank transfer. Matching UTRs from bank statements to invoices is what tells a finance team which invoice was actually paid.
Previously: someone downloaded a bank statement, opened it next to the invoices spreadsheet, and matched rows by hand. For a busy week, hours.
I built a TypeScript pipeline that ingested bank statements via REST, normalized the fields, and matched them against open invoices — first by exact UTR, then by amount + date proximity for the messy 5%.
Reconciliation time: hours → under 5 minutes.
Self-service invoice filtering/export (CSV/ZIP) reduced manual vendor requests by 60%. The reimbursement system parsed bulk uploads with OCR and supported multi-currency, accelerating submissions 5–10×.
The lesson from OCR: never trust a number you didn't double-check. The UI made it trivially easy to correct a misread cell inline.
The codebase had drifted — duplicated buttons across screens, inconsistent tables, no shared tokens. I modernized 20+ components, drove design system adoption, and mentored engineers on the patterns.
The hardest component to standardize was the data table — every team needed it slightly differently. The trick was giving it composition, not configuration.
The backend team was still designing the payment reconciliation APIs. Instead of waiting for a finished spec, I joined their design sessions and shaped the contract around what the UI actually needed. We documented it in the component library so the next person wouldn't have to guess.
Finding the gap between what's being built and what actually needs to connect — that's the work I enjoy most.
In college, before practical exams, our entire class had this strange ritual. We'd prepare dozens of possible programs in advance and store them on a tool called DontPad. If someone got a specific question, they could open the matching link and copy the code.
The problem was that DontPad only supported plain text. No images. No formatting. And anyone with the link could edit everything. One accidental change could ruin the entire document.
So I built ShareBoard — a collaborative board where people could add code, images, notes, and formatted content. The creator could switch between edit and read-only modes, protecting the board from unwanted changes during the exam.
What I remember most isn't the code. It's watching people actually use it. For the first time, something I built solved a real problem for real people. That's when software stopped feeling like assignments and started feeling like something I wanted to keep doing.
The name came from the difference between the old tool and what I wanted to build. A pad lets you write. A board lets you pin anything — text, images, notes, ideas. So I called it ShareBoard.
~ $ ls morgue/flowforge/ youtube-ext/ web-time-machine/reader-only-highlights/ nudge-app/ ...~ $ wc -l morgue/*/idea.md142 total~ $ echo 'most stay dead. some come back.'most stay dead. some come back.