DEV Community: Ademiju Adelakin

Your Pricing Logic Shouldn't Be Scattered Across Your Codebase

Ademiju Adelakin — Fri, 02 Oct 2026 14:58:06 +0000

You change your Pro plan from $20 to $25.

Simple, right?

Now ask yourself:

How many places in your application know that?

The pricing page might know.

Your checkout logic might know.

Your subscription logic might know.

Your payment integration might know.

Maybe your database has records tied to the old price.

Maybe your backend has conditions that still expect it.

A five-dollar pricing change can suddenly become an engineering task.

And that's usually a sign of a deeper problem:

Your application has too many places that think they own pricing.

Pricing starts as data. Then it becomes logic.

When a SaaS has one plan and one payment processor, pricing can look like a simple value.

Pro costs $20.

Store the price.

Display the price.

Charge the price.

Done.

But as the business changes, pricing stops being just a number.

Now the business needs to decide things like:

Which plan is being purchased?
Which currency applies?
Is the price monthly or annual?
Does the price change with the number of seats?
Which payment processor should handle the transaction?

These are pricing and billing decisions.

And if your application has to answer all of them itself, pricing logic starts spreading.

A value that once lived in one place becomes a collection of rules distributed across your codebase.

That's when things become difficult.

The problem isn't having more prices

A SaaS can have multiple plans, currencies, billing intervals, and seat-based pricing without those things automatically becoming an architectural problem.

The problem is where the rules that govern them live.

Imagine changing Pro from $20 to $25.

The pricing page displays $25.

But checkout still uses the old amount.

Or the subscription logic still references an old price configuration.

Or a processor-specific condition still expects the previous setup.

Now you don't have one pricing definition.

You have multiple parts of your system interpreting pricing independently.

And every time the business changes something, engineering has to find all the places that need to change with it.

That is the hidden cost of scattered pricing logic.

Your codebase shouldn't have to reconstruct a business decision

Here's the architectural question worth asking:

Where does the decision about what a customer should pay actually live?

If the answer is:

“Some of it is in the frontend, some is in the backend, some is in our payment integration, and some is in our database,”

then your application isn't simply using pricing.

It's reconstructing pricing.

That's an important distinction.

Your business has already decided what it wants to charge.

Your application shouldn't have to rediscover that decision through a collection of hardcoded values and conditions.

Instead, pricing should have a clear place where those rules are defined and managed.

The payment processor is part of the flow, not the whole pricing model

This becomes especially important when a SaaS uses more than one payment processor.

For example, a business might use Stripe for dollar payments and Paystack for naira payments.

That doesn't mean the application should contain a separate pricing implementation for each processor.

Stripe still needs to process the Stripe transaction.

Paystack still needs to process the Paystack transaction.

But neither processor needs to become the place where your application's entire pricing model is reconstructed.

The business needs a way to define its pricing and billing rules independently of the mechanics of collecting the money.

That's a separate responsibility.

Separate the responsibilities

A cleaner architecture makes the boundaries easier to understand.

Your application owns your business logic.

It decides what customers can do, how your product behaves, and what happens inside your SaaS.

Your pricing and billing layer owns pricing rules.

It handles the configuration that determines what customers pay, including plans, recurring pricing, currencies, and seat-based pricing.

Your payment processor handles payment collection.

Stripe, Paystack, PayPal, or Flutterwave can process the transaction without becoming responsible for your entire pricing architecture.

These systems need to communicate.

They don't need to own one another's responsibilities.

This is where AoraHQ fits

AoraHQ gives SaaS businesses a dedicated layer for handling their pricing and billing logic.

You can add the credentials for the payment processors you already use to the AoraHQ dashboard.

Then you can configure your pricing plans, currencies, recurring pricing, and seat-based pricing from the dashboard instead of manually implementing separate pricing logic around each processor.

Your application remains focused on your business logic.

Your payment processors remain responsible for collecting payments.

AoraHQ handles the pricing and billing logic between them.

Once configured, you use your AoraHQ secret credentials in your application and use the AoraHQ pricing UI.

So if your business uses Stripe and Paystack, for example, you don't have to build one pricing implementation for your dollar flow and another for your naira flow just because the payment processors are different.

The processors can remain different.

Your pricing layer doesn't have to be.

The goal isn't fewer systems. It's clearer ownership.

Adding another tool doesn't automatically make an architecture better.

For a small SaaS with one plan, one currency, and one payment processor, keeping pricing close to the application may be perfectly reasonable.

The problem starts when pricing becomes a changing business system and your application becomes responsible for keeping every part of that system in sync.

That's when a clear pricing layer starts to matter.

Because your business will change its prices.

It may introduce another currency.

It may change its billing model.

It may add seats.

It may change how payments are collected.

Those changes will affect different parts of the system.

But they don't all need to become changes to the same codebase logic.

The next time someone says:

“Let's change Pro from $20 to $25.”

The question shouldn't be:

“Which files do we need to change?”

It should be:

“Where does our pricing live?”

If your answer isn't clear, your codebase may be carrying more pricing responsibility than it needs to.

Give pricing its own layer.

Why Supporting Two Currencies Is More Complicated Than Adding a Currency Symbol

Ademiju Adelakin — Fri, 28 Aug 2026 12:06:59 +0000

Why Supporting Two Currencies Is More Complicated Than Adding a Currency Symbol

«"We'll support dollars later. For now, let's just add naira."»

It sounds like a small feature.

Add a currency selector.

Show "$" for one customer and "₦" for another.

Maybe convert the price using today's exchange rate.

Ship it.

The problem is that supporting another currency usually isn't a frontend change.

It's a pricing decision.

And those are two very different things.

The day one price becomes two

Imagine your SaaS launches with one plan:

«Pro — $20/month»

A few months later, Nigerian customers start signing up. They ask if they can pay in naira.

So you do the obvious thing.

Convert $20 into naira.

Except your business doesn't actually want to charge the converted amount.

Maybe the exchange rate says it's ₦34,800.

But you've decided the local price should be ₦30,000 instead.

Now your product has something it didn't have before.

Not another currency.

Another price.

The Pro plan now exists in two versions:

Currency| Monthly Price
USD| $20
NGN| ₦30,000

That's not currency conversion.

That's multi-currency pricing.

And your billing system needs to understand the difference.

The complexity sneaks in from there

Once each currency has its own pricing, the questions start multiplying.

Do annual plans have separate prices too?

What about seat-based pricing?

If your USD plan charges $8 per additional seat, is the naira version a direct conversion, or its own business price?

What happens when someone paying in NGN upgrades their plan?

Or switches to a USD-priced subscription later?

None of these questions are about displaying a different currency symbol.

They're about how your business wants pricing to work.

Then your payment processors enter the picture

A lot of SaaS businesses don't use the same payment processor for every currency.

Maybe Stripe handles your dollar payments.

Paystack handles your naira payments.

That's completely reasonable.

The mistake is letting those processors become the place where your pricing lives.

Suddenly your application starts thinking like this:

USD plan → Stripe
NGN plan → Paystack

Instead of thinking:

Pro plan → USD price
Pro plan → NGN price

That difference seems small.

But it's the difference between pricing rules and payment infrastructure.

One is a business decision.

The other is simply how money gets collected.

Your pricing needs one source of truth

Your application shouldn't have to recreate the same pricing logic every time another currency or payment processor is introduced.

It should be able to understand something as simple as:

«Pro plan

USD → $20/month

NGN → ₦30,000/month»

Everything else should build on top of that.

Your pricing.

Your billing rules.

Your seat-based pricing.

Your recurring subscriptions.

The payment processor should only come into the picture when it's time to collect the payment.

That's the problem AoraHQ is built around

AoraHQ gives your pricing its own layer.

You connect the payment processors you already use—whether that's Stripe and Paystack, or PayPal and Flutterwave.

Then you configure your pricing from one dashboard.

Currency-specific prices.

Recurring plans.

Seat-based pricing.

Everything lives in one place instead of being recreated for every payment processor.

Once it's configured, you copy your AoraHQ secret credentials into your application and use the AoraHQ pricing UI.

Your application keeps focusing on your product.

Your payment processors keep processing payments.

AoraHQ handles the pricing and billing logic in between.

Because supporting another currency shouldn't mean rebuilding your pricing system.

Sometimes the hardest part of multi-currency billing isn't accepting another currency.

It's deciding what that currency should actually mean for your business.

I'm curious—how does your SaaS handle pricing in multiple currencies?

Do you use live exchange rates, configure separate prices, or something in between?

The Problem With Building Billing "Just for Now"

Ademiju Adelakin — Mon, 24 Aug 2026 09:46:09 +0000

"Let's just hard-code it for now."

It's an MVP.

You have one pricing plan, a handful of customers, and one payment processor.

You don't need a billing architecture that can support every possible pricing model your SaaS might have three years from now.

You just need people to pay.

So you create the plan, connect checkout, write the necessary logic, and move on to building the product.

And that's a perfectly reasonable decision.

The problem starts when your business grows, but your "temporary" billing setup becomes permanent infrastructure.

Your MVP didn't break. Your business outgrew it.

Imagine you launch with one plan:

$20/month.

Simple.

Then customers ask for annual billing.

You add it.

A larger customer wants to pay for 15 employees, so you introduce seat-based pricing.

You add that too.

Then you start accepting customers in Nigeria, so you need naira pricing alongside your dollar pricing.

Then you add Paystack alongside Stripe.

None of these decisions are unreasonable.

They're signs that the business is growing.

But now look at what happened to that original $20/month plan.

What started as one pricing rule is now connected to plans, currencies, seats, billing periods, and payment processors.

The business changed.

But the billing logic is still living in the architecture you built when the business had one plan.

This is where technical debt starts hiding

Technical debt doesn't always look like broken code.

Sometimes everything works.

Customers can subscribe.

Payments go through.

Invoices look right.

Nobody is complaining.

Until someone says:

«"We want to change our pricing."»

Now changing a business decision means changing the code that was written to support the old decision.

And the problem isn't necessarily that the original code was bad.

It solved the problem you had at the time.

The problem is that the solution was never given somewhere to evolve.

The code starts carrying your pricing history

At first, your application might only need to understand:

«Customer is on Plan A → charge $20.»

Then it becomes:

«Customer is on Plan A → charge $20 monthly, or $200 annually.»

Then:

«If they're on the team plan, charge based on seats.»

Then:

«If they're paying in naira, use the naira price.»

Then:

«If they're paying through Paystack, use this implementation.»

And suddenly, your application isn't just running your product.

It's carrying every pricing decision the business has made.

The problem isn't that there are more rules.

It's that those rules can end up scattered across your application, database, pricing UI, and payment-provider integrations.

So the next pricing change isn't just a business decision.

Someone has to find where that decision lives in the codebase.

That's the separation that's easy to miss

Your application has a job.

It needs to know what a customer can do.

Your billing layer has a different job.

It needs to know what that customer should pay.

And your payment processor has another job.

It needs to process the transaction.

When those responsibilities are tightly coupled, a change in one area starts creating work in the others.

Add a new plan, and you touch the application.

Add another currency, and you touch the payment integration.

Add another processor, and you implement the pricing logic again.

That's how "just for now" turns into infrastructure you don't want to touch.

What if pricing had somewhere else to live?

Your business should be able to define its pricing without having to care which processor ultimately collects the money.

You should be able to configure:

Your plans
Recurring prices
Currencies
Seat-based pricing
The payment processors you support

in one place.

Then your application can focus on the business logic that actually makes your SaaS unique.

That's the problem AoraHQ is built around.

You connect the payment processors you already use by adding their credentials to the AoraHQ dashboard.

Then you configure your pricing there.

Whether you're using Stripe and Paystack for dollar and naira payments, or PayPal and Flutterwave, you don't have to manually recreate the same pricing logic for each processor.

Once your pricing is configured, you copy your AoraHQ secret credentials into your application and use the AoraHQ pricing UI.

Your payment processors still process the payments.

Your application still handles your actual product and business logic.

AoraHQ handles the pricing and billing layer in between.

Because hard-coding your first pricing plan isn't bad engineering.

Forgetting that your pricing will eventually change is.

Your MVP can be temporary.

Your pricing shouldn't have to be trapped inside it.

How did your first billing implementation hold up as your SaaS grew?

Did you eventually have to rewrite it, or did you manage to evolve it without touching everything else?