So the team of co-founders has a product in mind, and you know you have to design the MVP of it (in case you’re not fluent with MVP’s, here’s a good starting point). You try not to be too inclusive of what it will include, and at the same time, you’d better include all the fluff that makes the product usable, beyond just its core feature set. The core feature set the team initially had in mind, is usually the pinnacle of what the product would shine at, but there’s stuff around it you need to nail too.
For example, you may need to be able to manage users. If your product is an online presence one, a service you can use for that, is this one which I tend to like. You can role your own, as in the old way of doing things, but then it means you need to also scale-your-own as your needs from it evolve. I find it more Lean to use a cloud service, as it will be leaner to get more as your needs evolve using this approach. You may not always get 99.9% of what you had in mind, but if your needs are pretty standard you’ll get quite close to that. A cloud service feels almost as the quivalent of having another person on the team, but without the need to manage them, or even wait for them to get code ready to integrate – rather, you can integrate right away, and scale much better – when you need to use more features. Overall, my experience with Software-as-a-Service providers has been that they provide adamant support even for inquiries that are more of a question than a bug report.
While that means that you assume reasonably good proficiency at selecting your Software-as-a-Service vendor, it is not as complicated as it seems. The important pieces are, that you can integrate right away (excluding the initial registration process that comes with that), and you future proof your ongoing investment by moving it at large from your side, to the vendor. Admittedly, you’re better off focusing on your core unique features, than on ubiquitous aspects, such as in this case, how to enable basic user management.
Still, you will have to invest time, to properly manage with using software-as-a-service solutions for stuff that’s outside of your core. That would comprise ‘administrative’ aspects such as mainly – keeping your credentials for the service available to relevant team members, looking at invoices for the billing charges (once you surpass the free tier threshold for each service – but for startups, the free tier can suffice for a very long time), as well as calculating the financial scalability of the service for your usage pattern, and tracking it along time. This all may even mean that you’d want to include code that logs your usage of the service so that you can be on top of your actual usage pattern at any point in time. But these are all simple to do with a professional approach in mind.
If you’re not the type that’s quick on getting up to speed with a Web service api, or going through its documentation – you’d probably want to become one. Besides, beyond being helpful in the narrow sense, it will also help you when you come to design your own Web service api if you will ever want to.
So you start designing your Minimum Viable Product around features and capabilities that work towards the product vision. And you add complementary capabilities and features, that are necessary for actually having something that can actually be used. For example, you add the capability to manage users. But then, having a Minimum Viable Product that can just be used by users, is still not enough… how would you know its actual performance? that’s a great small topic – for a future post.