Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

111–120 of 132 posts

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

#111

Post by scarface74 »

fullstackchris wrote: post #67
scarface74 wrote: post #55

Earlier quoted context omitted.

This is absolutely the worse idea possible. I would never base my business on a technology that’s not widely used.

While supabase could be considered a "technology" it's really more or less fancy wrappers around a postgres database. And even then, the wrappers it uses are rather well known: - gotrue for auth, 3.2K GitHub stars - postgREST to expost postgres as REST API, 19.8K GitHub stars - kong as API gateway, 33.7K GitHub stars

And that still adds more complexity than just installing Postgres and creating a monolithic API

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

#112

Post by saluki »

mooreds wrote: post #51
vishnugupta wrote: post #40

I was heading tech and product of a SAAS software for ~15 months so writing this from that experience. - Who is the buyer? Typically they are not same as the user of the product so understand what they look for in similar products. - SSO, preferably SAML based. - As for security, take care of OWASP top-10 [1] and you should be covered for app-sec. - Implement RBAC. Make it easy to add/manage users for an admin-user.…

Disclosure: I work for an auth service vendor. 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…

Don't outsource your auth, auth is a solved problem for every framework worth using for the rest of your SaaS.

Don't outsource critical functionality.

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

#113

Post by saluki »

We built our MVP with two developers using a popular framework.

We went through a security audit + SOC-2 audit.

We passed our security audit with no issues, just two minor suggestions, they said we did better than most of the fortune 500.

If you're using a good framework and are following security best practices you should be fine. If you're not comfortable with sys/dev ops and security try to find a technical co-founder that is.

There are lots of packages/gems for SSO for various services.

As far as data, minimize what data you store that is sensitive, encrypting your database is becoming more and more common.

As far as business models and market strategies, start here: https://www.youtube.com/watch?v=0CDXJ6bMkMY (@DHH StartUp School talk 2008)

Good luck, enjoy the ride!

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

#115

Post by akajla »

mooreds wrote: post #110
akajla wrote: post #108

Earlier quoted context omitted.

Building and maintaining UIs for RBAC and org management (including self-service, user-facing UIs) isn't trivial. That's why we built it into Warrant. We handle basic authz schemes like RBAC as well as fine-grained authz: https://blog.warrant.dev/introducing-the-self-service-dashbo...

That's cool. FusionAuth has a self service function: https://fusionauth.io/docs/v1/tech/account-management/ but it is limited to user profile data, rather than roles and permissions. How do you prevent a user from assigning themselves roles they shouldn't? Is there some kind of cage preventing escalation?

The self-service dashboard is scoped only to privileged users (typically account/tenant-specific admins like IT admins) that have a specific permission.

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

#116

Post by sebmellen »

akajla wrote: post #108
sebmellen wrote: post #89

Earlier quoted context omitted.

Kratos is not a complete Auth solution - if you self host you still need to write your own UI. We built another layer over it to handle RBAC and organization management. But at least Kratos covers all the complex crypto and security items related to authentication (not authorization, which I consider to be a part of “auth” writ large).

Building and maintaining UIs for RBAC and org management (including self-service, user-facing UIs) isn't trivial. That's why we built it into Warrant. We handle basic authz schemes like RBAC as well as fine-grained authz: https://blog.warrant.dev/introducing-the-self-service-dashbo...

We’ve found one of the biggest issue with RBAC services to be the integrations with our tech stack. Building the RBAC system ourselves helped it be congruent with our stack.

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

#117

Post by ajax33 »

vishnugupta wrote: post #40

I was heading tech and product of a SAAS software for ~15 months so writing this from that experience. - Who is the buyer? Typically they are not same as the user of the product so understand what they look for in similar products. - SSO, preferably SAML based. - As for security, take care of OWASP top-10 [1] and you should be covered for app-sec. - Implement RBAC. Make it easy to add/manage users for an admin-user.…

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.

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

#118

Post by dplgk »

HarrietJones wrote: post #91

I'm someone who works on mature products in this space. The biggest mistake that people make is they assume that the slow, clunky old fashioned systems that current organisations use are easy to replace. They are nearly always wrong. This is great for me, because I get customers apologetically coming back to me after converting to whatever the ERP de jour is has failed. If an organisation is using an actively develop…

I think there are opportunities to augmentate the behavior of those old systems that can be a business/Saas. Not using the built in ERP crap but something new that integrates with the dinosaur ERP.

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

#119

Post by dplgk »

scarface74 wrote: post #56

Disclaimer: I work at AWS in ProServe all opinions are my own. What I wouldn’t do if starting my own business unless I already knew AWS is use AWS or any other cloud provider except for using a simple VPS solution like Linode or AWS LightSail (a fixed cost VM). I know the ins an outs of AWS well. But if I were doing a side project that wasn’t completely serverless - Lambda + DynamoDB + API Gateway[1], I would use Lig…

I agree but you don't explain why this is your opinion.

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

#120

Post by subbu »

saluki wrote: post #112
mooreds wrote: post #51

Earlier quoted context omitted.

Disclosure: I work for an auth service vendor. 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…

Don't outsource your auth, auth is a solved problem for every framework worth using for the rest of your SaaS. Don't outsource critical functionality.

This, totally. I manage a large B2B CRM with complex user-auth requirements and we use an off the shelf provider. It was an easy decision when we began, but now it has become a bottle neck in many ways. As your application becomes big you need a lot more customization to your auth logic. Large customers have specific customizations that off the shelf auth providers don't provide, or make it complex to implement. Over time auth and RBAC becomes crucial to your application. Engineering effort required to read through your providers documentation and implement workarounds exceeds a purpose built, native solution.
Post reply on HN