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

Great feedback about knowing who the buyer is. Lots of folks think about the user, but knowing the buyer (and they are usually not the same person) is critical too.

If you are a building a SaaS, I'd recommend outsourcing your auth, since that is both critical and undifferentiated functionality.

There are lots of solutions out there. FusionAuth is one option (I work there); here's our multi-tenant guide: https://fusionauth.io/docs/v1/tech/guides/multi-tenant .

There are of course other options too. Here are some I've heard of that seem like they fit your needs (offering some combination of RBAC, SSO, and multi-tenancy), but I'd suggest doing a spike:

* clerk.dev

* workos

* supertokens

* propelauth

You could also start off with an open source solution like devise/omniauth (if building on rails) or passport.js (if building on JS). I'd only go down this path if you are familiar with the tech, as it can be difficult to configure if it is your first time, and, again, this is critical but undifferentiated functionality.

I like this coverage of tech, though it's missing soc2 which will be required. And 27001 eventually.

I disagree on making it easy for admins to add users. Just don't: rather, implement (a bit of) scim or jit user creation with the idp flows.

The big thing it's missing is sales. This software is sold not bought. In any sales process with 3 different constituencies (users who really don't matter much, a champion, and an economic buyer) you need talented sales people. Bluntly, the vast majority of b2b / midmarket or enterprise tech companies are dead without an exceptional salesperson as a founder. The reason is that you have to sell your first 10 deals while the software basically doesn't work.

Realistically, tech matters less than sales here. When you look at your risks, tech falls well below sales and execution risks, because you're highly unlikely to be building something that's never been built before. ie it's not like google, which basically was build a significantly better search engine using novel relevance tech. Almost all midmarket or enterprise saas products have no novel technology inside them. (Which is not to say that you don't have to build a high-quality implementation: you do. But "can we build this / can we make it work" is rarely a top risk.)

Focus on:

* Having a product that people want to buy. Most important thing in business is sales and it's close friend marketing. Worry about everything else after you have something people will buy.

* Make your software demo well. This is probably the most important thing you'll do. It will increase sales a lot, make marketing easier.

* Figure out where, how and who sells your software.

* Focus on making your app and company secure before you worry about theatrics that make compliance people happy. The hard part is securing the company.

* Make sure your customer data is only accessible by that customer. Leaks look bad, and so in your unit tests, make sure that there are a suite of tests that will find leaks where a developer got crossed up on keys.

* Invitation-style onboarding is fine. Not all vendors support SAML, and SSO is a nice to have.

It appears the things closest to your heart are technical issues. "[business questions] would also be really nice." Literally a last place afterthought.

That's not knocking you--there's absolutely nothing wrong with a technical view. But a successful business is primarily not about the technical issues. It's a people thing--customers, users, employees, suppliers. Case in point: a current thread on HN right now is how terrible SAP is. Technically terrible. As a business they're terrific. They know how what the important people issues are to them, and how to address them (i.e., how to sell to the decision makers, how to "impedence match" with their customer organizations)*. (And if you have no clue what I could possibly mean by "impedence match" then that's a hint.)

I think the odds are high you wouldn't, at this point, actually enjoy building a business. Pursue what it sounds like you're most interested in--building systems. For example, go ahead and create a POC for your idea. If possible, create some IP protections. Then expose it to the world as an example of your skills and abilities. Leverage that to get a gig in an interesting place, maybe as a founding engineer. Get exposure to the really important people and business aspects of a business. Become a team lead, manage a team, grow a team. Own a product, grow it. All of this doesn't necessarily take decades, but it won't be a year, either.

Basis for advice: Been there :) Started out as uber-geek, totally focused on the technical. Entrepreneur at very eary stage. System grand-slam technical success, business not so much. Despite being at the perfect opportunity point, product never got the traction and success it could have. Gradually, over the years, got into the people side and realized that's even more fun.

* [edit: Sorry, "impedence mismatch" is an engineering term (esp. electrical engineering). It describes the bad results you get when you connect two otherwise-good systems which have differing fundemantal properties. I will say that the comment is kind of pleasingly meta; its an excellent analogy (trust me!), but is totally inappropriate for an audience which is not familiar with the core term.]