Why BulkFlow Moved from Fixed Pro/Business Tiers to Dynamic Plans

For a while, BulkFlow ran on two fixed paid tiers — Pro and Business — each hardcoded with a specific feature set and listing cap directly in the application code. That worked fine until it didn't, and the way it stopped working is worth describing honestly, because it's a common trap for any SaaS product that grows its feature list faster than its original pricing model anticipated.

Where the fixed-tier model broke down

Every time a new feature shipped — Photos → Sheet, My Store, the browser extension's batch limits, Sourcing Copilot — a decision had to be made about which tier it belonged to, and that decision was baked directly into code. Changing which tier included which feature meant a code change and a deploy, not a configuration update. Testing a different price point, or offering a limited-time plan variant, or adjusting a listing cap for one specific promotional run, all required the same thing: touching code for what was fundamentally a business decision, not an engineering one.

What a dynamic Plans system actually changes

Plans now live as real, admin-editable records — full CRUD from Admin → Plans, with feature access controlled through checkboxes rather than hardcoded conditionals, listing caps configurable per billing period, and Razorpay sync so a plan change in the admin panel reflects in actual billing without a separate manual step. Creating a new plan, retiring an old one, or adjusting what a specific tier includes is now something that happens in an admin UI in minutes, not something that waits for the next deploy.

What stayed the same on purpose

The existing autopay/recurring-billing model didn't need to change — this was specifically a fix for how plans are defined, not how they're billed. A site-wide recharge banner and reminder email for accounts approaching their renewal or cap also carried over unchanged, because that part of the system was already working fine.

The actual lesson here

Hardcoding a pricing structure feels reasonable when you have two tiers and a stable feature set. It stops being reasonable the moment either of those assumptions breaks — and for a product adding real features on a weekly cadence, that moment arrives faster than it looks like it will from the start. Moving the pricing model into data, not code, was the fix that should have happened earlier rather than later.

Start free — current plans and what's included in each are visible on signup and from Admin → Plans for anyone managing a team account.

A concrete scenario that exposed the real cost of hardcoding

Say a product decision is made to offer a limited-time plan variant for a festival season promotion — a slightly higher listing cap at the existing Pro price point, for a month. Under the old hardcoded system, this meant a developer writing a conditional check for a specific date range directly into the billing logic, testing it, and deploying it — for a promotion that would need to be manually removed from the code again a month later. Multiply this by every pricing experiment a growing product wants to run, and "pricing is a business decision" quietly becomes "pricing requires an engineering sprint," which slows down exactly the kind of fast iteration a growing product needs to be doing on its pricing.

What changed concretely in Admin → Plans

Creating that same festival promotion under the dynamic system is a form: name the plan, check the features it includes, set the listing cap and the price, set an effective date range if it's time-limited, save. No deploy, no code review for what is fundamentally a pricing and marketing decision, not an engineering one. Razorpay sync means the moment that plan is saved, it's also correctly reflected in actual billing — not a separate manual step that could fall out of sync with what the admin panel shows.

The broader lesson for anyone building a SaaS pricing model early

Hardcoding two tiers feels like the simpler, faster thing to ship first — and it is, for the first few months. The cost shows up later, specifically in proportion to how fast the feature set grows relative to the pricing model's flexibility. A product adding real, tier-relevant features on a weekly cadence will hit this wall faster than most teams expect when they made the original "just hardcode two tiers for now" call.

A smaller, easy-to-miss benefit of moving pricing into data

Beyond faster iteration, having plans as structured records rather than scattered code conditionals also makes auditing what each tier actually includes far easier — a single admin view shows exactly what every plan contains, rather than requiring someone to read through conditional logic across multiple files to answer "what does Business actually include right now."