The buying process dictates what kind of product you should build and what parts of it you should optimise.
Ask HN: Main things to consider when building an app for business/enterprise?
121–130 of 132 posts
Re: Ask HN: Main things to consider when building an app for business/enterprise?
#122I 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.…
I disagree.
I manage a multi-million security tools and services budget for a Fortune 20.
MY ADVICE: Focus on go-to-market strategy and value proposition before figuring out security.
REASONS:
1. We dodge salespeople like the plague. There’s a reason enterprise sales timelines are 18 months. If we don’t want you first, then expect to chase us for a year plus trying to convince us.
2. Enterprises of a decent size usually have a vendor/supplier/third party risk program. If your service is identified as low risk, then we may have little to no requirements for you. Everyone doesn’t need to provide a SOC2 Type II, align with NIST or certify ISO.
3. Mine your network for prospective enterprise design partners and build something that meets their needs. As your product grows in risk, they’ll let you know what you need to have in order to win or keep their business.
ADVICE:
- Focusing in security before you have a product is a direct route to failure.
- Providing a service that doesn’t require handling sensitive enterprise data means less requirements and quicker onboarding
Re: Ask HN: Main things to consider when building an app for business/enterprise?
#123From someone who has built 2 successful enterprise apps as eng #1 (1 sold, 1 going strong today valued over 100M) and worked on others that failed, the ONLY thing to worry about now is whether or not your customers really want and need your app. 99% of enterprise saas products fail because of this, not because of a missing feature. All the enterprise features like SSO, integrations, audit trails, etc can be built whe…
I can’t agree more. I have delivered several solutions to local enterprises, with questionable UX, no SSO, p2p integrations. We made changes while implementing, after we signed contract. The only thing you should care is to solve their burning problem and find the person, who has that problem. The rest is easy, not necessarily fast though. It took one year to sign contract.
Can't emphasize the "Burning Problem" part of it more! If it is not a burning problem, it's not a problem worth solving. If your solution is something that is slightly or significantly better than the stuff on the market, but their existing solution is something that still works for them, however complex, they will not buy your product.
Perhaps it is also worth rephrasing it as "a burning problem for the buyer", which might most likely be a stupid unscrupulous solution that doesn't make sense like those sensors they have in hotels to detect employee whereabouts. Stupid and completely useless, but still "a burning problem" for hotel managers.
Re: Ask HN: Main things to consider when building an app for business/enterprise?
#124Disclaimer: 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.
The idea is to build something using technology that he already knows and to focus on the business and not get bogged down on learning new technology. Keep it simple
Re: Ask HN: Main things to consider when building an app for business/enterprise?
#125I 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.…
I don't agree with the multi-tenancy. I've been part of two start ups that cracked the 3 million user mark (from staff to 3 million +). They all lived happily on one postgresql database. We didn't even consider breaking the DB apart until near this point. When we did we had the income to support the staff.
I'd say don't build for scale. When you need it, you'll be making enough to pay for it. Even if you have to start over, you're income will pay the devs.
Re: Ask HN: Main things to consider when building an app for business/enterprise?
#126I 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 pitc…
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.
Re: Ask HN: Main things to consider when building an app for business/enterprise?
#127I 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.…
Some great points there. I would also add a way for business users or admins to easily review accounts and privileges and sign off on that review if you are targeting any kind of regulated industry.
+100.
Look up maker-checker [1]. Almost all the enterprise systems require a human to review and approve changes initiated by someone else.
Even if you don't implement it right away, be aware of it and if possible build your entity/data model such a way you can add it later without turning your architecture upside down.
Re: Ask HN: Main things to consider when building an app for business/enterprise?
#128How regulatory capture works in your target industry. If you don’t understand this, the opportunity you think you see may be a trap leading to a tar pit business.
More at https://youtu.be/GMIawSAygO4
Re: Ask HN: Main things to consider when building an app for business/enterprise?
#129I 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.…
I don't agree with the multi-tenancy. I've been part of two start ups that cracked the 3 million user mark (from staff to 3 million +). They all lived happily on one postgresql database. We didn't even consider breaking the DB apart until near this point. When we did we had the income to support the staff. I'd say don't build for scale. When you need it, you'll be making enough to pay for it. Even if you have to star…
I took multi-tenancy here to mean that you have multiple customers on the same instance of your software, with separate user/data control, admins, configuration, etc for each customer, rather than what youve described with databases.
Re: Ask HN: Main things to consider when building an app for business/enterprise?
#130Earlier quoted context omitted.
> most auth providers are very expensive Some are, sure, but there are many that are not. FusionAuth (again, I'm an employee) has a free community edition ( https://fusionauth.io/pricing?step=plan&hosting=self-hosting ) if you run it yourself with no limits on MAUs, SAML connections, tenants or users. Of course, we have plans that cost money because, hey, we all like to eat. Auth0 has a basic plan that is free for 7k…
I think you're assuming that scratch coding is slower than integrating an OSS you don't know. When I was thinking about this for one project, it came close enough that I rolled my own basic auth system according to the NIST recommendations and it definitely took less time than integrating something that I didn't know (and accepting all the unknown bugs that are inevitably there). I also don't buy the argument "don't…
> I think you're assuming that scratch coding is slower than integrating an OSS you don't know.
I think that depends on all kinds of factors (domain knowledge, docs of the library, etc). I think learning one or two auth libraries or frameworks will be useful to most devs, as they can re-use that knowledge repeatedly. But I get your point, sometimes rolling your own can be quicker. (And it is certainly more fun to code something up than to read up on integration docs.)
However, I think you're dismissing the long term maintainability advantages you get from using a focused library or auth server.
When a request comes in for a feature (let's change the hashing algorithm and factor of our passwords to meet new NIST standards, let's add login with LinkedIn, can we integrate using SAML), if you have the right library or auth server, it's often a configuration parameter, as opposed to code.
When there's a security issue, someone clearly owns it and has an incentive to fix it as fast as possible. Some auth servers (FusionAuth among them) pay people regularly to penetration test the system. Is that something you are going to do with your homegrown auth system?
That said, I'm glad you found a solution that works for you. Different strokes for different folks, as they say.