"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?
Top comments (0)