So You Wanna Go On-Prem

As to vulnerabilities in the handful of 3rd party libraries that we use? In the 10 years that Twiddla has been around, we've had exactly zero cases where we had to patch something from our end for security reasons.

I guess there's something to be said about avoiding the tall skinny (and wobbly) tower of 3rd party dependencies that seems to be the norm these days in web app development.

On premise vs saas is a trade off in the type of customer support.

With on-prem, you do have support complicated by customers have unique infrastructure, and varying degrees of knowledge and post within their organization. Some people are adept, some are not. Some support keeps you screen sharing for hours, some do not.

In general for on-prem, support is done via your customer support app, professionally, as you're usually dealing with an IT department.

On the other hand, SaaS customer support volune/time is a measure of how often you break stuff for ALL (some, of you're lucky) of you're customers at the same time). Often an issue is experienced by many rather than a single person. "Always" (ish) it's your fault instead of being an issue of a customers configuration or infrastructure. Often Twitter becomes the public stomping ground for complaints, as you get end-users going to Twitter rather than an issue bumped up from an end user took their IT before reaching you.

In considering of you want to support on-prem, a key point is to keep your software simple. For example, optionally (and easily) logging to files instead of to reduce requirements on external systems (elastic search).

Making the app as simple and easy to run as possible is pretty important. Definitely very strongly consider if you need to rely on that saas app for your App to run.

We have extensive experience doing this over here, and this is key. Keep things even simpler than you think they could ever be, because "simple" times gazillions produces terrific economies of scale.

During interviews I'm often asked if I have experience on a product "at scale", by which interviewers often suppose it can only mean some typically tiered load balancers/front-end code/backend code/data persistence and you spin up new dynos/AWS of what is really (taken as a whole) a single cohesive application to face demand, and ultimately get dismissive when I tell them I'm not working on a 1Mreq/min product... but there's a whole other orthogonal dimension to "scale" which most products have firmly locked to 1, and believe me, everything suddenly follows a square law when your code and architecture can have an impact on each dimension, especially the one that involves humans that don't have the level of intimacy with neither your product, team, or methods.

That's old news, as Forrester reported back in 2009. https://static.googleusercontent.com/media/www.google.com/en...

It's just a matter of doing the math. It's very situational, and unfortunately I don't have anything that I've done that I am at liberty to share. I can say that in my case, at least 75% of apps we've looked at were rejected for AWS/Azure because they clearly cost more (25%) to operate, or savings were very marginal and our data about stuff like outbound bandwidth requirements was insufficient.

Keep in mind, my employer operates two shiny, efficient datacenters. We drive significant vendor savings based on purchase volumes. For a startup with no capital, AWS/Azure/etc is a no-brainer.

That is quite good compared to the rest of the industry. Nice work!