The Lost

The Challenge

Small businesses drowning in manual admin: chasing invoices, copying data between tools, following up on unpaid quotes. The existing tools were either too complex, too expensive, or not designed for how SMBs actually work. I wanted to build something lean, focused, and genuinely useful, and prove I could take a product from idea to revenue entirely on my own.

The Approach

I built RevoBill end-to-end: product design, engineering, infrastructure, marketing, customer support, and GTM. All solo. The product automates the full quote-to-invoice-to-payment flow for SMBs, removing the manual steps that cost small business owners time they don't have. I treated every aspect, including support conversations and onboarding, as a product signal, iterating fast based on what real users told me.

The Outcome

RevoBill has paying customers, acquired with zero marketing budget through product quality and word of mouth alone. It's a live, operating SaaS business that I continue to build and scale. More than the metrics, it's proof that I can operate at every layer of a product: from the first line of code to the first paying customer.

The Challenge

In an engineering-powered B2B/B2C SaaS business, developer experience was treated as a nice-to-have: something engineers cared about, but not something the business tracked or invested in deliberately. The cost of poor DevEx was real (slower delivery, more incidents, higher attrition risk) but invisible to everyone outside engineering. Changing that required more than tooling. It required a shift in how the whole business thought about engineering productivity.

The Approach

I introduced the Developer Experience Index (DXI), a compound metric combining qualitative survey data with quantitative signals, as the formal measure of engineering health. We established a baseline, benchmarked against comparable organisations, and made DXI a standing agenda item at the leadership level. Alongside measurement, we invested in the underlying drivers: internal platforms, documentation, shared capabilities, and clear ownership models. Crucially, every initiative was framed in terms of business impact, not engineering comfort.

The Outcome

The organisation moved from an untracked baseline to the 75th percentile for companies of similar size and type. More importantly, DevEx stopped being an engineering conversation and became a business conversation. It is now tracked quarterly alongside product and commercial metrics, representing a lasting change in how the company values and invests in its engineering capability.

The Challenge

Three legacy billing systems had accumulated years of technical complexity. Each had its own data model, logic, and vendor dependencies, and none spoke to each other. For a company where subscriptions were the core revenue stream, there was zero tolerance for errors. Every decision carried outsized financial risk.

The Approach

In a product leadership role, I led the initiative strategically from initiation through full migration alongside the Head of Engineering and a dedicated Product Manager. We designed a phased migration plan with parallel-running periods, automated reconciliation, and system-gated cutovers. Each phase was sequenced by risk level, with the most complex, long-standing subscriptions handled last. We worked with leading SaaS providers in the billing and payments space to ensure the target system could handle the full range of inherited edge cases.

The Outcome

Every single subscription migrated without error. Three legacy systems were fully decommissioned. The business now operates from one authoritative billing platform, giving Finance, Support, and Product a shared view of subscription state for the first time and laying the foundation for future pricing and packaging capabilities.

The Challenge

Failed payments are a fact of life in every subscription business, and recovery relied on a standard single-channel retry mechanism. There was clear untapped potential: smarter timing, more channels, and a real customer communication strategy could recover significantly more of the cash that would otherwise be written off.

The Approach

I led the strategy and owned the vendor decisions, integrating a multi-provider approach that combined direct email-based dunning with specialist cash collection providers. To validate the approach fast, I personally ran a concierge-style proof of concept, manually working a cohort of failed payments end-to-end before we built any automation. This gave us conviction in the model within weeks. We then automated the full funnel and instrumented it to make recovery rate a first-class business metric.

The Outcome

Within one month of go-live, recovery rates exceeded 50% of previously lost payments. The approach continued to compound with subsequent improvements. Failed-payment recovery became a managed, measurable part of the business, with ongoing optimisation built into the operating rhythm.

The Challenge

Customer-facing infrastructure and APIs were running below the reliability bar the business needed, generating recurring incidents and escalations. The path to five nines required fundamental architectural changes, not just better monitoring. And the migration itself had to happen without customers experiencing any downtime, a constraint that made every step more complex.

The Approach

In a product leadership role, I led the initiative alongside Engineering, owning the product strategy and stakeholder alignment while Engineering owned the technical execution. The core work was architectural: rethinking the underlying infrastructure and replacing key components with services built for the reliability bar we needed. We ran the old and new systems in parallel during migration, using internal tooling and SLA reporting to validate each phase before cutting over. Every integration point was treated as a potential failure mode.

The Outcome

Within 6–9 months, we crossed the 99.999% uptime threshold and have held it since. Not a single customer experienced downtime during the migration. The infrastructure layer and APIs now operate with the reliability expected of a mature SaaS platform, and the internal tooling built during the project gave us durable visibility into system health going forward.