I've co-founded two products and led frontend for multi-tenant SaaS web & mobile apps in production. 8+ years of React and TypeScript, and a habit of owning the whole problem architecture, UI, customer calls, whatever the thing actually needs.
I co-founded a SaaS company and ran it from idea to production. Product, design, infrastructure, and a small distributed team. I made the call to pivot when the marketplace wouldn't hold, and the call to shut down when efforts never turned into revenue. That's where the founder mindset came from. It was what the job required.
Today I lead frontend architecture (with experience contributing to backend development) for SaaS products in React and TypeScript. Same approach, different role. Find the thing that actually matters, own it end to end, ship it before it's perfect, then make it good.
A working thing in front of a user beats an elegant thing on a branch. I've never regretted shipping early. Polishing something nobody wanted burns time.
If it needs a Figma file, a customer call, a CI pipeline or a conversation with your sales team, that's part of the task. I don't hand a problem back because part of it wasn't frontend.
Speed versus purity is a decision, not an accident. I'll tell you which one I picked and what it cost. Every case study below names the trade-off I made.
I pivoted one company and shut down another. Evidence beats attachment, including my own.
No spec is not a blocker. It usually means the interesting part hasn't been figured out yet.
If something's broken and nobody's picked it up, assume I have.
A few breakdowns of how I approach building, and the trade-offs that come with it.
When I joined Orbify, there was no dedicated frontend architecture and no one owning frontend decisions. The codebase had grown fast into a large, inconsistent surface built on outdated patterns, the kind that gets progressively harder to build on the longer it's left alone.
I led a team through a full refactor, replacing outdated patterns with a modern React architecture based on bulletproof-react. The key decision was speed of delivery versus technical purity. Instead of a full monorepo, I adapted bulletproof-react so multiple apps could share a common component set and core logic, like auth and API clients, without taking on monorepo overhead. It was a deliberate trade-off suited to a startup that needed to keep shipping while we rebuilt underneath it.
The application got faster, but the bigger win was maintainability. In a startup shipping quickly, a codebase the whole team can move through confidently matters more than any single clever pattern.
GreenCell, an EV technology company, needed a mobile app that could reliably control and monitor Habu, their mobile EV charger, in real time. No single connection method was good enough on its own. Bluetooth offers near-instant control but only works at close range, while cellular reaches anywhere but with more delay. The app had to feel instant regardless of which one was actually available.
I built the app in React Native with a connection-quality-aware architecture. BLE first, since it let us poll and control Habu with almost no delay, and an automatic fallback to 3G when Bluetooth was unavailable or too weak, accepting slightly more latency in exchange for the charger staying reachable from anywhere.
The app stayed responsive whether you were standing next to your charger or controlling it remotely, switching connections automatically without the user ever having to think about it.
Solidstudio was a software agency where I worked as a Senior Mobile and Web Engineer, building a whitelabel product that customers could license and customize into their own branded apps. The challenge was architectural. Each customer app lived in its own forked repository, with deep customizations and independent production releases. We needed a way to maintain those customer forks while continuously shipping improvements from the shared product core without creating unmanageable merge conflicts.
I focused on designing an architecture and development workflow around a fork-based whitelabel model. The goal was to clearly define what belonged to the shared core versus customer-specific customization, making it possible to propagate updates from the main product into multiple customer forks. I also maintained customer admin panels using React and Ant Design, allowing each client to manage their app-specific configuration without requiring code changes.
The architecture enabled us to operate a true whitelabel product at scale. Customers could maintain deeply customized apps while still benefiting from ongoing improvements to the shared product. Instead of every customer becoming a separate codebase that drifted over time, updates could be systematically integrated across multiple live applications.
Coming out of Orapa.co, we needed a product sales teams would actually want to use, not just another feature nobody asked for, and we needed to find that out fast without spending months building the wrong thing.
We first tested an interactive AI sales training chatbot combining text-to-speech, speech-to-text, and natural language intent analysis, built on GPT-3 years before ChatGPT popularized LLMs, when the APIs, tooling, and best practices we take for granted today barely existed. We then simplified into Intro.so. A standalone Electron desktop app and a Chrome extension that injected insights about the people you were meeting directly into Google Calendar, right before your Google Meet call. Under the hood it was a TypeScript codebase with a Node/Express backend, sourcing data by scraping LinkedIn with Puppeteer and combining it with third-party data providers.
The Chrome extension became the strongest signal across everything we built. Hundreds of customers used it, real proof that people wanted meeting insights surfaced automatically. But we never built out the layer needed to turn that adoption into a fully monetizable product, so revenue never followed and we eventually wound the company down. The company ultimately didn't become a sustainable business, but the experience fundamentally shaped how I build products today. Validate quickly, measure honestly, and optimize for solving real customer problems rather than falling in love with an idea.
Even with money, you can't move fast without a network, especially in tech. Orapa.co set out to fix that. A marketplace where you could pay for a warm introduction to people worth knowing.
We built it quickly and deliberately kept scope tight. Just enough to get real supply and demand in front of each other and learn whether the model held up, rather than over-engineering a product nobody had validated yet.
We validated product-market interest fast and just as fast ran into the problem that kills most two-sided marketplaces. We couldn't fill the supply side quickly enough for the model to work. Rather than keep pouring time into a marketplace that wasn't holding together, we made the call to pivot.
I use it to compress the distance between an idea and something a customer can click.
Open to founding engineer roles, senior engineering leadership, and contract work with teams that ship.