Ask HN: Main things to consider when building an app for business/enterprise?

I like this idea a lot, personally. Separately deployed customer instances as an approach for “multi-tenancy” also eliminates the need for sharding databases at scale, since most of your scaling will just be new deployments. Overall, this suggestion has an appealing set of trade offs if you have the DevOps chops to pull it off.

Just watch out for really really big customer instances (but then they should be paying more than enough to spend time on their particular scaling issues).

There are books/tomes written about each of those topics, more than can be written here, but the place to start is not to build at all, but instead find ways to talk to potential users and buyers and their specific pain points, use cases, and your proposed solutions/features/workflows. This can be turned into slide decks and Figma interface walkthroughs without writing any code. These can be used to line up interest, piloters, potential buyers.

This is a lot of work but it is the essential starting point in defining WHAT to build. It is a LOT less work and orders of magnitude less expensive than actually building, especially if you build the wrong thing.

SSO, security, data governance and compliance regimes are just "ilities"/HOW to build details that come later at actual system design time. If you understand what needs to be built, you can hire people who know how to build with those ilities.

I once wrote a business case for something I wanted to build. I was really interested in the solution, but thought I should be specific about the type of customer that would benefit. It was a whole detailed doc of imagined problems & how my solution would fix them.

The best feedback I got was a sr guy who I quite respected just commented “can you link the client’s LinkedIn?”

That’s when I realized I was never going to be specific enough, and starting from the tech was working backwards

Note also that enterprises have extremely long and high touch sales cycles for most products. If you don’t know someone who has actually sold the kind of thing you are selling into an enterprise just figuring out who to talk to can take forever.

Also once the sale lands, contracts and getting paid are their own challenges.

You’ll have plenty of time to figure out SSO in the enterprise world if you can get to a sale.

Some things that I think are useful for an enterprise app:

- Integrate with the organisation's authentication system, usually LDAP would suffice (sso is a plus but not really required)

- Replicate the organisation's structure (directorates, departments, job titles, who reports to who etc). Some of this may be in LDAP but usually it is not enough and you need to integrate with another system like PeopleSoft

- Auditing. Every action should be fully audited. Who and when did that?

- Very strict access to raw data (databases or servers). Be friends with the admins because you'll need them.

- No need for fancy interfaces, don't lose any time with that. A bunch of traditional request response pages would suffice. People don't really have a problem using command line interfaces without mouse supports (you navigate using tab and the fn keys)

- Error handling. Be very careful on stale data. Under no circumstances your database should be left in an inconsistent state. Especially when money is involved.

- Security is not usually a big problem because enterprise apps should be accessible only from the organisation's internal network. Many organizations use internet explorer 6 (through citrix) to access old apps. External apps are a very different thing of course.

- Web services. Forget json, rest and the like. Only way to consume or offer data to other services in enterprise is through soap based web services using wsdl.

- No open source databases. Enterprise mainly uses oracle, ms sql server and even ibm db2!

- Nobody wants to try new things unless they are offered by a big company.