Renoodles - Developer-First Subscription & Feature Flag Platform

Building Renoodles: A Subscription & Feature Flag Platform for SaaS Developers

Every SaaS developer hits the same wall early on. Before you can charge your first customer, you need billing infrastructure: subscription plans, payment recovery, failed charge handling, customer emails, and some way to gate features behind plan tiers. None of that is your actual product, but it can eat weeks of development time. Renoodles exists to eliminate that problem.

I built Renoodles from the ground up as a personal project after running into this exact friction myself. The platform lets developers connect their applications via API and get subscription management, feature flagging, and revenue analytics running in minutes rather than weeks. One of the things I specifically wanted to support was managing multiple applications from a single dashboard, since most competing tools assume you're building one product, which quickly becomes limiting.

What the Platform Does

At its core, Renoodles has three interconnected systems. The first is subscription management: plan creation, billing cycles, mid-cycle upgrades and downgrades, and the messy-but-critical work of failed payment recovery. Rather than just flagging a charge as failed and moving on, the platform runs automated retry workflows and sends configurable customer communications at each stage, which is something I found most lightweight billing libraries simply don't handle well.

The second system is feature flagging tied directly to subscription tiers. This isn't just a simple on/off toggle. Flags can be scoped to specific plans, evaluated at request time via the API, and toggled instantly without a deployment. That last part matters more than it sounds; being able to roll out or pull back a feature across all your users in real time is a genuine operational advantage.

The third piece is the analytics layer: revenue tracking, churn signals, and subscription performance broken down per-application. Since the platform supports multiple apps, the dashboard needed to give a useful consolidated view while still letting you drill into individual product performance.

Technical Decisions

The backend is Node.js with Express, backed by PostgreSQL and deployed on AWS with Docker. I chose PostgreSQL over a NoSQL alternative specifically because subscription data (plan histories, billing events, state transitions) is inherently relational, and trying to model that cleanly in a document store adds complexity rather than removing it. Event sourcing drives the subscription lifecycle so there's a full, recoverable audit trail of every state change.

On the frontend, I used React 18 with TypeScript and Material UI. The TypeScript investment paid off quickly given how many interconnected data types flow through a billing dashboard; strong types caught a number of integration edge cases at compile time that would have been painful to debug at runtime.

Payment processing runs through Stripe Connect, and transactional email through Mailgun. Both are integrated at a level deeper than just "call the API"; webhook verification, idempotency handling, and retry safety are all accounted for, which are the areas where billing integrations tend to quietly break in production.

The brand identity, including the logo and landing page design, was created in Figma. I wanted something that felt modern and approachable without leaning on the generic "developer tool aesthetic": clean typography, restrained colour, and enough personality to be memorable without being distracting.