Building SaaS (Software-as-a-Service) products is hard. Although your priority is to deliver something of value to your users or customers, other things can get in the way. It doesn’t matter what development approach you take, SaaS products have certain characteristics that cannot be ignored.
Once upon a time I built a simple portfolio management tool that made it easy for creative types (film directors, designers, photographers etc.) to manage the content for their websites.
Soon several of our friends and colleagues were using it; we even had a reputable production company and university on our books. There was something special in our creation, however simple it was, and we wanted to take it further. We wanted to build a product, but our instance-per-customer solution wasn’t going to scale. We needed to build a multi-tenant application.
This was my initiation into the world of building SaaS products. Trying to find good resources on how to do this (especially in the .NET world) was hard, especially since everyone had a different approach depending on the framework they were using.
Eventually I was able to build something that worked for our us, but it took time. Tenant identification strategies, scoping dependencies and data isolation were aspects of multi-tenancy I just had to learn along the way (and alongside trying to run a business).
We had all the makings of an MVP, though we didn’t know that’s what it was called at the time. After building our own claims-based identity system (this was a long time before ASP.NET identity) we had a complete product. It wasn’t ground-breaking but we were excited to get this far.
Our beta period proved positive with lots of people giving the product a try. By the time we were ready for launch we had around 50 customers ready to pay. SaaS startups weren’t quite as mainstream back then but the big players like 37signals had fancy sign-up pages with different plans and automated billing.
I opted for a radically more simple approach of generating invoices manually that customers would then pay by bank transfer or cheque (they’d post them to my house). Trial accounts would be deactivated with a few SQL scripts. For email notifications I’d open a spreadsheet each morning to view the trials that were ending or renewals that were due and email off some Outlook templates. A tedious but necessary task.
A year or so later I did a complete overhaul of the product. I put my contracting commitments to one side. I was determined to do it better this time.
I needed to automate our on-boarding, subscription management and billing processes yet even with SaaS becoming more mainstream, there still wasn’t that much guidance on how to build this sort of thing. After a month or so of development we had trials, subscriptions and the ability to take payment built into the product. We didn’t have recurring billing (customers still had to pay manually each year) but it was better than them having to send cheques to my house!
As I spent more and more time on my little startup I became acutely aware of how much resource goes into non-product work. Though on-boarding and billing were more or less automated I was still sending out notifications manually. With our customer-base growing this was a daily task that I just didn’t have time for. A few more weeks development and I had automated subscription notifications (it’s still in use today).
Fast-forward another year (in which I stepped away from the company completely) and with a new team, lots of enthusiasm and great ideas we were ready to take our portfolio platform for creatives to the next level.
4 months of hard work goes into a revamped version of the product; a new brand, a new vision and some big technology changes. It’s an exciting time as we’re able to deliver a number of new features that our customers had been asking for. This is what spurs me on, delivering value to our customers and improving our product in the process.
After our relaunch it’s time to get serious and put together a product roadmap. Looking through our backlog I’m amazed at the number of high priority tasks that aren’t directly related to the product. There are certain expectations of what a SaaS product should have, especially if you want to be taken seriously. Surprisingly we’d made it this far without providing customers with invoices or payment receipts. A week or so of work and we finally had a billing section in our dashboard where customers could view and download their invoices.
I’d love to get back to “product work”, but next on the list is monthly subscriptions. We know we need them - yearly subscriptions are a blocker for many of our potential customers. Unfortunately our existing manual renewal process won’t work for monthly subscriptions - we need recurring billing too.
I don’t normally shy away from a development task but this is something I really didn’t want to do. There are so many aspects to building subscription-based products - different plans, billing periods, failed payments, invoicing. Stripe makes things a bit easier but there’s still a lot of legwork and again, not many concrete resources on how to do this.
3 more weeks of development and we have a complete subscription system in place with support for multiple plans, trial periods and both monthly and yearly billing. I’m pleased that it works but I didn’t enjoy it. I want to work on our core product, not on infrastructure.
A familiar story?
This was a shortened version of my experience building Fabrik.
The biggest frustration throughout has been the resource that goes into non-product work; and it doesn’t stop once you’ve launched. Add management dashboards, event tracking (for analytics), monitoring and more. All of these things are necessary but not exclusive to your product and don’t directly provide value to your customers.
This is a story shared by many developers and startups. In fact, during my time building Fabrik I contracted for a number of other startups where I implemented many of the same things, again.
In the years I’ve spent working on Fabrik I’ve longed for better tools and resources to help with building SaaS products. I’m embarrassed to admit that as much as 40% of my time went into non-product development work in the early stages of Fabrik.
Startups don’t use .NET, right?
Microsoft lost a lot of credibility in the startup scene but times are changing. The reality is that many startups are using .NET. I’m certain that Azure plays a part in this (at least it did for us) as it makes reliable and scalable infrastructure available to the little guys. Microsoft’s new direction and open development of ASP.NET 5 has also help to kickstart what felt like a dying community.
That said, building SaaS products on the .NET stack isn’t easy. With so many frameworks (despite the supposed “One ASP.NET”) it has made it difficult to know where to start. It seems the .NET landscape is full of articles on infrastructure and tools, but end-to-end examples of how to build a SaaS product from scratch are thin on the ground, if not none-existent.
It’s time for a change
Over a year ago I introduced SaasKit, a developer’s toolkit for building SaaS products using the .NET stack. The goal is to alleviate developers of tasks that are common to SaaS products so they can focus on what is most important - delivering real value to their customers.
However I can’t achieve this alone. Aside from working full time at Fabrik, I need feedback from other startups and developers who’ve built or are building SaaS products.
Here’s how you can help:
Talk to me. Email me or reach out on Twitter. I’m looking to interview those with real-world experience to better understand the most common problems shared by SaaS startups. If you’re in London even better - the drinks are on me.
Join the community - I’m developing SaasKit in the open, but I’m not going to do any more work on it until I have a decent level of engagement from the community. I’ve set up a room on Gitter so we can get acquainted.
Spread the word. I want to see more startups (especially those using .NET) put their time into building awesome products, not infrastructure. Follow the project on Twitter and GitHub.
Finally, if you don’t have anything to contribute but are interested in where SaasKit is heading, please subscribe to our mailing list below. Emails won’t be frequent, only when we have something to show you.
Email Address