Why I Created PriceOS

I created PriceOS after experiencing firsthand the chaos that comes with changing pricing…over and over again.

The product that pushed me to build it was Video To Blog, a web app that converts videos into awesome blog posts.

Like many products, Video To Blog started small. When I first launched it, there wasn’t even authentication. There wasn’t a signup form. You could paste a YouTube URL, generate a blog post, and that was it.

Then people started using it and my AI bill started to climb.

So I added authentication.

Then I asked the obvious question:

Would anyone actually pay for this?

The Pricing Experiment Spiral

The first paid plan was simple:

• $9/month
• Unlimited usage
• No annual option
• No feature gating

At the time, there weren’t even enough features to gate.

But as the product evolved, so did the pricing. And that’s when things got complicated.

Here’s roughly how the evolution went:

• Free for everyone
• $9/month unlimited
• Added annual plan
• Switched to credit-based pricing (3 tiers)
• Added more tiers for higher usage
• Raised prices
• Switched from credits to per-blog-post pricing
• Introduced feature gating
• Added a free trial (1 post per month)
• Launched an AppSumo lifetime deal (outside Stripe)
• Removed free trials
• Reintroduced free trials
• Changed prices multiple times
• Reassigned features across plans repeatedly

And now I want to introduce add-ons and a premium tier (which, at the time of writing this, I haven’t done that yet, because I didn’t want to implement it until I built PriceOS).

The Main Problem

The main issue was that I wanted to honor whatever pricing plan my users originally signed up under.

There were two reasons for this:

1. It was easier than migrating everyone.
2. I didn’t want to repeatedly email customers saying, “We’re changing your plan again.”

Changing pricing once? Fine. Changing it five, six, seven times? I felt like that would erode trust with my customers and it just didn't feel right to me.

I was never confident I had found the “right” pricing. So I didn’t want to force customers to upgrade every time I experimented.

Which meant…

I had to support every version of every plan simultaneously.

The Codebase Nightmare

Because I never expected to change pricing this many times, I didn’t build a proper system for it.

There was no centralized source of truth.

It slowly turned into branching logic scattered throughout the codebase:

if (user.plan === "pro_2023" && user.signupDate < "2023-10-01") {
  // allow unlimited
}

if (user.plan === "pro_2024_credit_v2") {
  // deduct credits
}

Feature gating logic was everywhere.

Every pricing change made it exponentially worse.

Every new experiment added more conditionals.

It became fragile, confusing, and stressful to touch.

And that was just the beginning.

Additional Problems

Besides the codebase nightmare of managing all these different pricing plans, I also encountered other problems...

Problem #1: Showing the Right Pricing Table

Here’s something I didn’t anticipate:

If you raise prices publicly but keep existing customers on legacy pricing — and they see the new pricing page — many will assume that’s what they’re paying.

And they churn (or at least in my case they did).

I learned that the hard way.

So I realized:

I needed to show different pricing tables to different users depending on when they signed up.

Which meant:

• Multiple pricing tables
• Different features per version
• Different prices per version
• Used across landing pages, billing pages, upgrade modals, emails, etc.

Managing this became another mess.

Problem #2: Usage Tracking

Except for my original unlimited plan, every pricing model required usage tracking.

• Credits
• Blog posts
• Team seats
• Connected channels
• Automations
• Connected websites
• And more

So I built my own usage tracking system.

Then came the edge cases:

• What if generation fails?
• What if a job errors halfway through?
• What if I need to refund credits?
• What happens on plan change mid-cycle?

Every edge case added more complexity.

Again, this was just another system I had to build and maintain.

Problem #3: Bonus Credits

One of the best things I implemented was bonus credits.

Users could earn extra usage for:

• Inviting friends
• Subscribing to YouTube
• Following on social
• Other engagement actions

It worked incredibly well.

It also became a powerful customer support tool that I could use to easily alleviate any

Instead of digging through logs to reverse usage after an error, I could simply grant bonus credits which not only resolved the issue faster, but let me easily give customers more credits than the were entitled too (which they loved) and often turned a potentially negative experience into positive one.

But again — this was another system I had to build and maintain.

Problem #4: Customer Overrides

Then there were also times where I wanted to give certain customers access to features that were not on their base plan. For example...

• A customer wants early access to a feature.
• Someone agrees to beta test.
• Someone wants a one-off feature that I don't want to show to everyone

What was my solution?

if (user.id === "abc123") {
  giveAccess = true;
}

Every developer reading this just cringed.

I hated it too.

But I didn’t have a better system.

The Realization

Finally, I got to the point where I wanted to change my pricing once again and realized I needed a better way to deal with all of these problems.

I wanted a system that could...

• Version plans
• Preserve legacy feature access
• Track usage
• Grant bonuses
• Manage overrides
• Show the correct pricing UI
• Experiment without breaking trust

After scouring the internet for days to find a product that did this, I found none.

So, I decided to build it myself.

And I called it PriceOS.