Building a SaaS (or any software product, really) takes a lot of time and money. It’s hard to stay focused on the things that actually produce value for your customers. In the following, I’ll show you a few things that you can easily skip until after launching. This way, you’ll launch earlier, and maybe even learn that you don’t need some of the features you thought everyone wants.
1. Self-service on-boarding
The dream of SaaS is that it’s full self-service at some point. People sign up, give you money, and you never have to talk to them. To achieve this dream, you spend a lot of time building and tweaking your self-service customer on-boarding flow. You create wizards, guided tours and streamline everything.
However, when you have not launched yet, I urge you to skip it. Instead, manually set up your customer’s accounts for them. Afterwards, invite them to a screen sharing call and walk them through your application.
Or, for a better effect, let them try to figure it out themselves, while you’re watching. When they get stuck or confused, help them by explaining things. This way, you learn about the actual problems of your application and any potential mismatch between your assumptions and your customer’s expectations.
Take notes about the things that don’t explain themselves and improve them. In the end, you’ll get a much better understanding about what you have to (or don’t have to) explain in a walkthrough.
2. Activity streams
Activity streams are a good way to show your customers what happened while they were away. While they’re a good way to show and document the value generated by your tool, they rarely are the feature that produces the value for your customer.
On top of that, there has to be a lot of activity for them to become meaningful. So, when people just signed up, they are not going to see anything useful anyways.
Instead of implementing activity streams before even launching, remove that feature until your customers request some insights into their account activity.
3. Payment Integration
Don’t implement a payment integration before you launch. I know, this sounds bit unintuitive, because you’re building this product to make some money.
However, not implementing a payment integration, does not mean you cannot get paid.
Why don’t you start by invoicing your customers manually, asking them to wire transfer the money? You can also use services like PayPal or Gumroad to sell pre-paid subscriptions packages for a couple of months. Those tools are set up within minutes and don’t require you to integrate anything into your application.
Even if you’re expecting a huge amount of new customers at launch, you don’t need automated billing right away. You have until the end of your trial period to get payments implemented.
4. Permissions / User Roles
A fine grained roles and permissions systems is sometimes praised as a great feature of your application.
In my opinion, it makes things more complicated for both you and your users. Your application only needs one or two different roles. Chances are good that it doesn’t need them at all.
For your launch, only allow one user per customer. People can easily share their login credentials should multiple people need to work with your application. Don’t worry too much about someone in your customer’s team screwing up the settings or accidentally deleting something. A complex permissions system is not the fix for trust and competence issues.
5. Administration Interface
It’s tempting to implement a secret administration interface that gives you convenient access to your customer’s data. In my experience, you don’t really need it to get started, though.
For one, you don’t have a lot of data and customers to look at in the first place. For another, you can just peek into the database, or ask your developer to run a quick query.
Over time, you’ll recognize what bits of information you actually need, and which tasks you have to execute often. As soon as it takes your developer a substantial amount of time to do these things for you, it makes sense to implement a dedicated administration interface for those things.
6. Advanced Technology / Architecture / Infrastructure
When starting out, you want to use the latest and greatest piece of technology around. It’s nice and shiny, and all the cool kids are using it right now.
However, you don’t need it to solve your customer’s actual problems. A fancy, one-page, real-time, super fast JavaScript application is pretty cool, but it’ll take a lot longer to develop. A simple form with a bit of code in the back-end will do the job just as good.
Just because some piece of technology is the best thing for a large, successful startup with lots of customers and engineers, doesn’t mean it’s the right thing for your application. Start with something simple, and build up from there. Build more advanced stuff when you actually need it. You cannot anticipate the problems you’ll run into eventually, so don’t try to anticipate them by using an advanced and complex setup.
When it comes to infrastructure (servers and stuff), keep things simple as well. Don’t expect huge growth in the early days that would warrant a super scalable and high performance infrastructure setup. It’s not worth the time and money unless you are absolutely certain you’ll need it.
7. Settings and customizations
For the initial version of your product, implement the bare minimum of features you need to solve the customer’s problem. Try to optimize for just one simple use case, and don’t any customizing.
For one, this will make the application easier to use, for another it’ll save you a lot of time to build it. Pick some reasonable defaults and stick with them until enough people request more options and settings to tweak.
This includes things like: The number of different types of things (Field types, modes, …), custom themes and branding, available languages, sorting, filters, pagination, different views on the same data, and a whole lot more.
A good example for this is is Tiny Reminder. In the first sketches of the product, there were several types of form fields that people could use collect data from their clients. In the process of cutting down unnecessary features, Jane removed all but four simple ones (Short Text, Long Text, Tasks, and Files). Up to now, nobody missed the ones she decided to drop.
8. Metrics
Collecting data is important to understand how your customers use your application. However, the metrics are meaningless until you collected a lot of data points.
Don’t attempt to measure and track every single action your customers might take in your application. Skip that part until after your launch. You can get a pretty good first idea about your customer’s usage patterns just by looking at the data in your database.
Once this data doesn’t answer all your questions, slowly start collecting data points for different things. As always, keep it simple and to a bare minimum. Having an overwhelming amount of data only makes it harder to draw any conclusions from it.
9. Customer support tool / knowledge base
Customer support is one of the core features your application should offer. It’s important to keep your customers happy. They will run into problems and there should be an easy way for them to get help.
However, a simple support email address is more than enough to get started. You don’t need a dedicated customer support tool. Once you get too many support requests to be able to handle them via email, you can integrate a proper tool.
This also is true for the knowledge base. It’s a super useful tool to reduce the number of support requests you get. Don’t bother building it before your launch. Instead, learn from the common issues your customers have and write the knowledge base content based on that.
Bonus: Don’t build software at all
Did you ever consider that you might not even need to build a software product? Chances are, your customer’s problems can be fixed by offering a service. Start by doing things manually and learn about your customer’s actual problems and requirements.
This gets you into learning mode quickly, and you’ll save a lot of time and money that would otherwise go into building a software product that doesn’t fit your customers’ needs.
Brian Casel’s Audience Ops is a great example of this. Instead of starting with software, he started offering a service. Only now that he knows what tools would actually be useful, he’s building a software product.
Your mileage may vary…
As always, your mileage may vary. Depending on your actual product you cannot go without some of these features. Be careful about the features you add to your application early on. While most of the things listed above are useful, it’s probably too early to spend time on them.