My idea initial is/was to offer the product in an on-prem version only. I didn't want to handle all the issues regarding customer data, data residency, etc.
Of course, going on-prem also limits the product. It requires a certain level of knowledge of the customer with regards to infrastructure, server setup, etc. At the moment I'm not entirely sure how this affects my ideal customer.
My gut feeling is that this will limit the success of the product.
What do you think?
If you want to know how this affects your ideal customer, if you have a customer and you don't mind talking to them, TALK TO THEM! Get their feedback, the good and the bad. I run a small startup in the food&bev space (2 people) and we have a couple of clients - and if there's a day where I don't talk to a customer or wholesale client, I feel as if it's a day wasted. If your customer likes you, or likes your product, they will have something to say, and it's important that they as your user feel like they can have an open line of communication with you. Keeping that line open and active is super important IMO....but that also depends on the scale you'd like to hit and how fast you want to hit it.
Also, what in your mind defines the success of the product?
Another thing is: does your ideal customer for this exist and who are they? People who want analytics and ownership via on-prem, right? Go find those people and ask them, without describing your product to avoid biasing them, how they currently solve the problems your product solves.
If they don't actually care about analytics or on-prem, then you'll know if there's a mismatch in the definition of the product as you see it, and need to change to match those customers or another segment. Also are those customers even big enough operations to have someone who can set up on-prem, like you allude to. If not, time to switch it up.
NickC25's advice is good.
On premises is going to require support resources for installation and maintenance. You’re going to need a build & distribution team who cut a release and package it for distribution. You are going to have to develop to a release schedule cadence, you are not going to have continuous delivery & integration. You are going to have to pick and use components that can sustain that cadence. You are not going to want to use, for example, a library or framework that releases monthly, if you’re doing quarterly, bi–annual, or yearly releases.
None of this is wrong…it is just very different from how product development has shifted to the cloud.
A cloud SaaS shifts the resource allocation around. It doesn't necessarily cut it. You pick up continuous development/integration. You increase release velocity. You have a smaller build/deployment team but a larger operations/SRE team. If successful you become a critical component of your customer's operations. But, when successful, you also become a target for intentional information security attacks (depending on the value of your customer's information you’re storing and processing).
If your customer’s information is valuable or interesting to governments you become a target for legal and regulatory investigations. So you may need a bigger legal team if you’re providing a cloud based service vs on premises.
So…I don’t think there's a right answer. I think it depends on how you’re building the business, how you want to allocate capital, and how rapidly you want to build revenue.
Gut instinct is that a cloud based service will generate revenue and get you to break even earlier but an on premises solution may generate higher profits once you hit your stride.