[ajax33]

This is a really good list.

I head engineering for an enterprise SaaS startup in the manufacturing space. Wanted to add a few points to this:

1. Software Integrations: Enterprise software is almost never deployed in a vacuum. There will be a ton of existing software that companies use that they would want you to integrate with - most commonly being either some CRM like Salesforce or an ERP like SAP, Oracle. When pitching to a customer, it would be great to try and learn what existing software tools they use and see if opportunities exist to try and integrate with them ultimately. This will make your software very very hard for them to get rid off later and will also help distinguish you from your competitors who might try to be avoiding integrations. Designing your architecture with integrations in mind is a good idea.

2. Audit logs: Depending on the industry, there might be a strong requirement for compliance/auditing. The enterprise would want to ensure that every action undertaken on the platform is audited and can be reviewed on-demand later.

3. On-premise vs Cloud deployments: You might find certain clients that operate their own hardware and software and want you to just hand them some executable that they can deploy in their systems. On the other hand you'll also find companies that have gone all-in on cloud and won't bat an eyelid as long as you are deployed on some known cloud like Azure, AWS or GCP. Increasingly more and more companies are going the private cloud route and ask you to deploy on their cloud accounts (most commonly Azure - Microsoft has a much stronger hold on the enterprise market). Be prepared to handle requests like these. In several cases, you might be able push to have the SaaS being served from your cloud accounts but not always.

4. IT departments: Enterprise companies will invariably have an IT department that is supposed to ensure that the procurement process goes smoothly from a technical perspective and that you are compliant with all of their technical requirements. Their primary job is to ensure their asses are covered and nobody blames them later for technical/compliance issues later. Do not cut them out of the sales process. While they don't have the ability to approve the sale, they definitely have the ability to block it. Involve them closely and get their strong buy-in so that they don't become a bottleneck later.

[john_the_writer]

If you can avoid ON-premise do so. Unless you have full control. I've had a few rails apps go pear shape when the customer updates their ruby version. Then fixing the app is on me.

I spent weeks building an app, and I send it out in a nice package. 18 months later I get a call telling me it stopped working. I (being honourable) looked into the issue (free of charge). When I found out they'd updated their OS and Ruby version I bowed out. There's a line between building something and maintaining it for free for ever.