I moved from frontend (React.js / Electron.js) to backend (NestJS) — and I won't lie, the first few months humbled me.
I'd written backend code before. Express, REST, GraphQL. But it was a small project. No real users. No real consequences.
This time was different.
Real users. Real production environment. Real data, with all its messy edge cases.
Staging existed. CI/CD was solid. None of that prepares you for what happens when actual humans hit your API in ways you never tested for.
I learned fast:
→ "It works on staging" means nothing once real traffic hits
→ Edge cases aren't edge cases — they're Tuesday
→ Error handling isn't optional, it's the job
→ GraphQL resolvers can quietly become N+1 nightmares
→ The cost of a bug in prod is not the same as the cost of a bug in a small project
I broke things. I fixed things. I got paged for things I didn't think were possible.
That experience changed how I work with clients.
I don't just ship features. I think about what breaks at scale, what edge cases get missed in happy-path testing, and what decisions today become technical debt tomorrow.
If you're building something that needs to actually work in production — not just in staging — that's exactly the kind of engineer I am.
A client shouldn’t have to learn Webflow just to publish their next case study.
On a recent build, I spent a lot of time on the CMS: setting up reusable blocks and the logic that lets the team update content without rebuilding pages.
The tricky part is deciding how much control to give them. Too little, and every update becomes a request. Too much, and they’re suddenly responsible for the layout.
I want them to open the CMS, know what to do, and get on with their day. There’s a fair amount of work behind making that feel simple.
Summary: A suite of 20+ developer utilities that run entirely in
the browser. No uploads, no server, no data leaving your machine.
What I did: Built the full stack — Next.js frontend, Web Workers
for heavy processing (formatting tens of thousands of lines of JSON,
PDF manipulation, hashing) so the UI never blocks. Every tool works
offline after first load.
The no-upload promise is the strongest part. I'd make the offline state visible in the UI, so someone working with sensitive JSON or PDFs can see that the file stays on their machine before they drop it in.
Architected and deployed a full production B2B SaaS platform for restaurants, bars, and hospitality businesses with active daily operations and paying subscribers.
Key Engineering & Product Highlights:
• Integrated AI Operations Assistant: In-app conversational assistant powered by Google Gemini API, allowing restaurant managers to query sales velocity, stock anomalies, and daily operational metrics in real-time.
• Granular Inventory Engine: Real-time ingredient tracking down to the gram/milliliter linked directly to recipe consumption upon checkout.
• Real-Time Kitchen Sync: Bi-directional WebSocket events keeping order queues synchronized across multiple kitchen stations with zero page reloads.
• Multi-Branch & Multi-Tenant: Robust tenant data isolation, custom role-based permissions (Cashier, Waiter, Kitchen, Admin), and multi-location management.