On Premise or SaaS - Challenges!

Discussions
#1

So this is a question primarily asked to @ian but i welcome all contributions

Having listened to 73 episodes of Bootstrapped, 15 episodes of Chasing Product (so far), 20 episodes of Startups for the rest of us (so far), read The Business of Software book plus a couple of others, Most of Ian’s blog, various other blogs and forums all in the last 3 months… I’m tired LOL!

Anyway, my research so far has validated 2 good ideas for software businesses, both of which i’m sort of connected with and understand intimately (one by proxy via my wife). There is good competition in both and both have seen vendors move to SaaS ver the past few years. Both markets are fragmented enough that there is no real dominant player.

From my research (which includes talking to people) I think there is a differentiator and a market for ‘on premise’ stuff even if it’s an option alongside a SaaS model.

I understand SaaS better than the challenges of doing a PHP app for on premise as I’ve written plenty of SaaS type apps during my consultancy days including multi-tenant stuff.

So I’d like to ask…

  • If you were starting again would you still do on premise
  • What do you think the unique challenges are for On Premise
  • I imagine the support overhead for getting clients to install and setup is quite high, was that the case with Helpspot

I’m still early days on this and haven’t started coding but have the first steps of marketing ready to go so other than my time researching these markets nothing has been lost.

again all responses welcome

thanks

#2

I think one of the deciders between SAAS & on-premise is whether the client wants to keep their data inside their walls (B2B seem to favour this). I made a desktop app where a SAAS app would have been easier to support (for me) because the app deals with clients’ AutoCAD drawings that they don’t want out in the cloud. I could deploy it to a web service and get drawings from Dropbox etc. but nobody has shown any interest in that. So, where does their data live? That’s where you need to live.

1 Like
#3

Hi!

I’m not Ian, but I’ve done tech support on HelpSpot for 2.5 years or so, and built the infrastructure for HelpSpot Cloud!

Here’s my perspective, although Ian I’m sure can fill in more (I’m definitely curious to hear).

There’s definitely a trade-off between SaaS and on-premise. Neither are really great or bad, but here’s what I see with the on-premise portion.

Note: We support the app on both Windows and Linux.

1. Automate:

When I was hired, Windows customers already has a install process (think: install_helpspot.exe) automated by Bitnami (BitRock). Ian’s told stories of entire days spent doing windows tech support before that existed. We’re just now automated a similar install for Linux.

Lesson: Automate an install process. It reduces a ton of support time.

2. Restrictions:

HelpSpot’s Windows installer adds it’s own PHP (and Apache + MySQL if you want) and isn’t compatible with a Windows servers running other PHP applications (php installed on the server by other means) unless the customer wants to manually install everything.

On the Linux side, we only support MySQL (formerly pgsql too, but no one really uses it in reality), since MS drivers for SqlServer are, for now, Windows-only. I suspect that will change since they’re working on getting sqlserver running on Linux.

Lesson: Have restrictions in what you’re willing to support. Enforce them as much as we can (we still try to support customers who need or want to go outside of what we “officially support”. It’s more work, but keeps customers)

3. KISS

For years, HelpSpot “just worked” on most servers. It was friendly to cheap hosting as it didn’t require special software, specific directory structures, or calls to CLI commands (nothing more complex than a CRON task at least), and worked on multiple databases (easily). Many modern apps rely on queues. HelpSpot does not. It may in the future, but won’t include third party software (probably!) to do this.

We do now use SphinxSearch to power search, which has increased support a bit - since we need to help customers adjust it occasionally. We document Sphinx heavily and test on many systems to help with common things customers might run into.

This has the side affect of needing more than basic hosting. However, that’s more common now and gives us a way to push customers to our Cloud offering.

Lesson: Keep is as SIMPLE as you can for on-premise customers. Solutions such as “put everything in docker” for dealing with complexities might seem nice, but I’ll bet many customers aren’t ready to trust or maintain docker images which hide complexities.

Document the hell out of anything the least bit complicated. Take the time to test everything on multiple systems and document the steps needed to get around more complex aspects.

4. You’ll help customers resolve their own IT issues, a lot!

Most of our support is from Windows customers with semi-complex systems. This support is almost all related to network issues related to third party systems they connect to (exchange, active directory, load balancer/cdn setup, private networks, firewalls).

You’ll have support requests that often results in helping an IT person resolve issues within their own infrastructure.

Linux customers are relatively self-reliant!

2 Likes
#4

@fideloper did a great job covering questions #2 and #3 (thanks!) so I’m going to focus on question #1.

My answer is it depends :slight_smile:

SaaS is much much much simpler to manage and support overall since you are in full control of everything. So these days on-premise has to prove it’s value in your market to be worth that path. Some ways it can:

  • Competitors offer download versions. That would imply it’s in some demand. I’d be leery of entering an all SaaS market with an on-premise version (that wasn’t open source or such) without an extremely strong conviction on if there’s demand.
  • There’s some market need for on-premise versions such a regulations or security implications.
  • The software interacts with the physical world in some way like running machines or what not.
  • You intend to make heavy customization and potentially one off customization a cornerstone feature.
  • You intend to have it be open source and you sell the SaaSified version.

Still, nobody really starts a product as on-premise these days if it can be a SaaS. I tend to think that leaves a bit of a niche you can exploit if you can reach those customers. That may be something you really need to consider in conjunction with marketing plans though. In the help desk software space it is something we do discuss in our marketing directly.

So what would I do. All things being equal I think I’d be inclined to hedge my bet assuming there was some indications the market would like on-premise but where it’s not required.

Build it as a SaaS, but focus on not creating a lot of dependencies on other SaaSs. If you do that, you can always offer a on-premise version fairly easily if there is demand. It would also give you the option of perhaps only have an ‘special’ on-premise or enterprise kinda version. So you never offer on-premise to the average joe, but for an enterprise type price point those kind of customers can have it. Kinda how Github does.

One of the really nice things about bigger customers and on-premise is they almost always have the right IT staff. So they have a database person and a network person and an Exchange admin, etc. So they’re very capable of debugging issues on their own and also helping you get information on issues between your systems and theirs. It tends to be a much easier (and more lucrative) support situation.

Hopefully that’s helpful :slight_smile: without knowing the markets and more info it’s hard to be specific.

3 Likes
#5

Bravo sir! This deserves a standing ovation.

In most startups, the fad is to use the latest and greatest sexy tech. Message queues, docker, acmp, Mesos, blah blah blah. It leads to a mess.

Not to mention, many of these technologies aren’t really that mature (or well tested). You then have to deal with Fails on 7th day of the month, randomly type bugs.

Keep it simple, and screw the fads.

The problem occurs when you want a job with these startups. Then you need to fad up your CV…

2 Likes
#6

Thanks for the reply Ewen, there is a definite need for something on premise in the couple of niches exactly for the reason of ‘keeping’ data inside the firewall.

I’m still trying to gauge how much of the overall market it is. I’m thinking I have to totally rip off helpspot’s model of both.

#7

Thanks so much Chris, a great answer and thanks for the steer to bitnami

Surprised about postgres as I thought that was gaining ground again, maybe that’s because I’m re-evaluating it after hitting some issues with MySQL/innodb with multi gb databases that are really transaction heavy.

One vertical I’m looking at (training/learning management) may require mongodb to be installed which is something I need to consider much further as its a little out of the norm.

I’m seeing a need for more responsive and immediate support capability for on premise against more infrastructure related considerations for SaaS.

Lots to think about still and maybe I’ll need to pick your brains a little about SaaS infrastructure. :grin:

1 Like
#8

Brilliant response Ian, thank you so much.

I’m very impressed with the helpspot model and how you’ve established yourself in a very crowded and tough market. I’ve many years under my belt in corporate/enterprise IT, internally as support, infrastructure and management and externally as software/web app supplier.

My contacts in corporate still have the pain points I’ve seen first hand and for a user base in the 1000s or 10,000s per user pricing gets expensive even for big companies. That’s when I’ve seen ‘solutions’ built internally. They are usually functional but not great to use. They usually have a minimal feature set and an abysmal UX.

Training and learning management is one area I’ve seen that needs attention and I have and industry expert sat next to me and she has the same surname :grinning:

These are my ideal customers but after a day of chewing the fat after reading the answers on here I’m leaning towards starting as SaaS and aiming for smaller customers initially. Going this route means I can startup part time where as fully on premise would mean full on support offerings.

I would like to add that I wasn’t under the illusion that I’d build something and sell 1000 seat licenses from day one. That is the dream and the magical goal but if you don’t know where you are heading then how can you plan getting there.

I know from the podcasts you’ve said about not wanting to do SaaS and be responsible for people’s data and running servers etc. I’d love to hear more about how you became more comfortable with that and what you’ve done infrastructure wise (happy to take it offline and under nda if you prefer)

Loving this forum, a great informal asrermind group.

#9

Shantu. Completely agree, I even avoid Ajax if I can LOL

#10

Chris, forgot to say how much I love Servers for Hackers. Looking forward to next week :smiley:

#11

Thanks!! Appreciate it :smiley:
I’m uploading and prepping all that this weekend for Tuesdays release.

#12

Like @ian - our friendly competitor :vulcan: - we’ve been selling both on-premise and SaaS versions of our helpdesk app for many years so here’s my two cents:

  1. It is way easier to Saasify an existing on-prem app then the other way around (“on-premifying” an existing SaaS app). WAY EASIER. Keep that in mind. Also, having an on-prem version keeps your code cleaner, keeps dependencies more organized. It’s a win for saas too

  2. On-premise support is not a problem if you have an installer/updater + automated emails for version upgrades etc. etc. Just make sure you pass the Joel Tests. Especially this one - “your build-deploy-release-upload should happen with a click of one button”. We click a button - the Visual Studio script runs all the unit-tests,builds the app, packs it into a windows installer, uploads it to the server, etc.

  3. Despite our efforts of advocating SaaS and educating customers - still 45% of our revenue is on-prem. Things have improved a bit during the last couple of years after Microsoft and other big vendors started offering cloud-based perks like “Azure Active Directory” etc. (and you integrate your app with it) but still lots of people prefer their basement to AWS. Policies, regulations, hipaa-compliance, you know…

and - yes - I would still do onpremise in 2016

4 Likes
#13

In places I’ve worked, one click of the button means: “You do jiggery pokery with svn, run a few scripts, spend an hour debugging them, then click a button, then copy the exe to a server”

So yeah, 1 click should mean one click.

#14

Thanks Alex, much appreciated

it is way easier to Saasify an existing on-prem app then the other way around

that’s totally why I’m looking at on premise now as an option even if its not offered until later. I know my software ideas have a market to be on premise as well as SaaS but how I bootstrap will dictate when each option is available. Probably easier to start SaaSing

I have more research to do on the infrastructure needed for bullet proof SaaS though, regardless of what the software does it should be always on so this is something i need to look at now.

I’m with @andrey dependencies are evil :slight_smile:

Just make sure you pass the Joel Tests

Hmm Joel Tests… i need to find those and read more

Despite our efforts of advocating SaaS and educating customers - still 45% of our revenue is on-prem.

Thanks for sharing that number, that helps to validate my research even more.

I really appreciate you taking the time to answer, it means a lot. I’m hoping to take you all on the journey with me much like @ian did with Helpspot. It’s still very early days though (pre content/audience)

Oh, recently listened to your interview on @Christopher’s Chasing Product podcast, thanks for being so open with info. Between Bootstrapped FM, Chasing Product and Startups for the rest of us I’m learning so much and avoiding some errors. I’ve a lot to catch up on after 8+ years helping to build a consulting business

thank you

Dean

#15

So yeah, 1 click should mean one click.

Ah, the Holy Grail :wink:

#16

The Joel Test: 12 Steps to Better Code

1 Like
#17

many thanks, i’ll take a look

#18

Have you reached a similar conclusion?

#19

I don’t have any decent hard figures as i’m not that far down the rabbit hole but I have validated from companies I’ve canvassed (through contacts) that there is quite often a policy of no cloud services. This is especially the case where personal data of employees is involved (even just names of employees).

If I was pushed I’d say the percentage wanting on premise (or more specifically, no cloud) is more like 70%. This is based on answers I have from 20 companies with > 100 employees. A small sample i know, but they are directly my target market.

I’ve also noticed companies in the 10 to 30 employee range saying the on premise option is preferred, I’m wondering if it’s because these companies still have the founders involved with day to day operations and are in the tech related sector? The sample is tiny sample though (7 companies).

#20

I’m currently working on something that I plan to launch as a SaaS product initially, but would like to also offer an on-site version of the product.

So, as I develop it I’m trying to be careful about keeping things portable (not tying myself to a particular cloud provider by using their proprietary API, for example) and keeping complexity, deployment, and dependencies as simple and manageable as possible.

As a result, I suppose it won’t be as ‘scaleable’ as it could possibly be (not going crazy with microservices, etc). But designing a beautiful, scaleable architecture hasn’t been my problem with any of my previous attempts. If I start running into serious scaling issues on the SaaS size, that probably means I’m successful enough to hire some help :slight_smile: