I wanted to add billing to my SaaS, so that I could finally start charging customers. Sounds simple, right? Except that billing needs Stripe integration. It also needs a scheduler to send reminders, and then an alert system, and then…
Stop! This is getting out of hand. I have a serious case of building the thing needed to build the thing. Is this really necessary to get the MVP out the door? Am I over-engineering this? The answer isn’t so clear cut…
The Decisions that Got Me Here…
Here’s the reasoning I followed. Charging a basic subscription via Stripe isn’t hard. But, it’s important that customers get notifications such as trial ending and subscription renewal reminders, and payment failure notifications too. Hence, the need for a scheduler to periodically run the code that sends those messages. I don’t like relying on cron, so that means the app needs its own scheduler.
Next, if there are delivery issues or something else that went wrong, then it’s important that I know about it. Hence, the need for an alerts system, that alerts me of failures.
On top of that, the app is for WhatsApp based sellers, so my WhatsApp sending module needed an upgrade to support the notifications which is, unfortunately, way more complicated than sending an email.
Meanwhile, my app still hasn’t launched publicly, and I’m spending time building infrastructure rather than validating that there is a market for this app. The only way to truly know if there’s demand for your app, is to offer it to the market, and have strangers pull out their wallets, and pay for it…
Am I Over-Engineering? Did I Over-Build?
So, am I over-engineering? Is this scope creep? Am I wasting time building when what I need most is market feedback?
I’m sure some would say yes. Those trial ending reminder messages won’t be needed until at least two weeks after initial launch. So, I could postpone the scheduler and alert system, and shave days to weeks off the time to get the MVP out
On the flip side, we’re talking about billing here. Real money is involved. Other people’s money. Failures are serious. If a subscription renewal fails, the customer needs to know. And if the system breaks, then I need to know, ASAP.
Yes, that’s a weak argument, and I know it. The billing system can be robust without notifications, and I could easily add the notification system after launch.
I just don’t want to. I hate technical debt. And, when I release the MVP I want to be able to focus on marketing instead of scrambling to build & fix all the stuff I skipped to rush the MVP out the door.
I also have one other reason. I’m not building just a SaaS app. I’m also building a SaaS app foundation called ZitaKit on top of which I’ll build multiple apps. And that changes the cost-benefit equation. Getting a solid billing module and scheduler working may be overkill for my first SaaS app, but for ZitaKit it’s a core feature, and a very important one at that
So, I’ve opted for some short-term pain, which I hope will pay off later.
Bear in mind that every single one of those modules could be over-engineered by itself. I wrote the bare minimum Stripe integration needed for the MVP. The same goes for the scheduler and alert modules. I could have built full-blown heavy-duty versions, but I didn’t.
The Technical Founder’s Dilemma
The engineer wants to build things properly. The founder needs to get the app out into the market ASAP.
I am an engineer at heart, so I tend to err on the “build it properly side.” That said, I’ve gotten a lot better at shelving tasks for later. I add those tasks to the project’s “bug/issues tracker” and then forget about them for now. ZitaKit’s “Issues Board” has been growing…
What do you think? Am I over-engineering? Or is making the billing fully functional important enough to justify building out all the support modules that it’s built on. Let us know in the comments below.