Ask HN: Main things to consider when building an app for business/enterprise?
I have a couple of ideas I’d like to build that would target business/enterprise and take the form or a SASS product (problems I see people having regularly)
I’m a pretty generalist fullstack engineer.
The things that worry me about this space are security best practices, providing features like corporate single sign on and handling data that customer expect to be healed very securely.
Its probably clear I don’t know much about this space and am likely missing even more things. Any advice or heads up would be really appreciated. Advice on business models and go to market strategies would also be really nice.
131 comments
[ 3.6 ms ] story [ 197 ms ] threadDo you want to build enterprise apps. Do you need advice on using React Native vs Flutter vs Swift ?
Do you want advice on actually building a SASSS business?
Have you ever sold something?
In large enterprises, the sales cycle time can also be quite long, but to make up for it, the deal sizes can be quite large. It’s worth working with them for several months if it means a million dollar deal.
The best advice I have as someone who has sold to enterprise customers for years now is this: understand your target customers. That is, not just the companies themselves, but the actual people you’ll be selling your software to. So before you start building, you’d do well to talk to your target customers to see what exactly it is that they need (and see if it meshes with what you had in mind) and also find out what hurdles they have in place to buy software. If you know the requirements in advance, you won’t be surprised in the sales process.
One book I’d recommend if you haven’t read it is the Mom Test. It’ll give you good guidance on asking the right questions to get feedback from your target customers.
My god the time wasted talking about branding and then a client can’t even provide a decent logo and turns out they didn’t care about the branding anyways.
Don’t waste your time on that stuff unless it’s hyper critical to the core product itself.
In your offer, state that you're happy to support Penetration Tests that might have to be carried out.
Get an IT insurance and tell customers about it.
If you've got a lot of time and money, get ISO 27001 certified (5 figure sum for a small company).
Security - complexity will absolutely kill you. I know it’s fun to experiment with Kubernetes and multi-region infrastructure deployments, but that does nothing but increase your attack surface. When we were acquired, I had a single static website hosted on AWS S3, one RDS database, and a handful of Lambda functions behind an API Gateway. You still need to follow best practices: use TLS for all connections, encrypt customer data, properly segment application users, OWASP top 10, etc. but that’s much easier to do with a simple application. Minimize application dependencies, scan them for venerabilities using free tools like Snyk, and keep things up to date.
Compliance: Depending on your domain, you may need to get a SOC II report at some point. Don’t do it until you need it, but when you do, just pay a company like Secureframe (full disclosure: I’m an advisor for them, but there are other similar companies).
Single Sign On: we used Auth0, which was great until we reached 10(?) enterprise connectors and it went from free to $15k/yr. We then migrated to AWS Cognito. If I did it again, I’d just use Cognito to begin with, but wouldn’t build the integration until you actually have customers asking for it.
Marketing: my weaker spot. I was a developer, so had a skeptical view of marketing. We tried a lot of things (agencies, paywalled content, contract writers, etc). I’m still convinced that the highest impact marketing was deeply technical content (doesn’t even need to be about the product, just the same problem space) that was published on our blog for free with a link at the bottom to our product. Simple and effective. Reddit ads on niche subreddits were helpful, especially with getting early users. Marketing agencies are probably overkill until you’ve got actual PMF.
Sales: you need to do the selling. Don’t hire a salesperson until you’ve got a significant number of users. “But I won’t have time to develop if I’m selling.” Yes, exactly. And you won’t have anyone buying if you spend all your time developing and not talking to users. It’s critical that you personally talk to every user as much as possible.
Pricing: I made the mistake of underpricing the product for a long time. I thought developers would love the low cost model. In reality, their companies were paying, and, when you give someone a company credit card, they’re a bit more willing to pay more for a good product. You can still price lower than the competition to get users in the door, but don’t try to be the bargain app. Monthly subscriptions are good, annual are better, but bring tougher sales cycles (enterprises will want to negotiate the contract, add their own legal terms, etc).
It’s a bit tough to give much more advice without knowing what domain you’re operating in, but hopefully that was helpful!
(If on AWS, you might also want to look at AWS Cognito. I've not worked with Azure or Google Cloud so no idea about those)
It’s meh. At least compared to polished / feature complete solutions like Auth0.
Keep identity and login mechanism decoupled - plan to support multiple login mechanisms per user (email/password, SAML, OpenID Connect, Google) for a single identity and multiple authentication factors (TOTP, Duo, etc). Be very careful to about what you consider a verified user and how you verify email addresses.
Use TLS even for your database connections. Use encryption at rest. Automate backups and plan to restore or export data for specific customers rather than the whole application.
Use a time series database or event logging system and create an audit trail of everything any privileged user does in your system, any account or permissions changes, destructive operations, etc.
Also, this list is quite literally supabase (https://supabase.com/) - I cannot recommend enough, especially if OP is solo, which it sounds like is the case.
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).
- 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
There are levels of multi-tenancy:
* logical multi-tenancy, where isolation is enforced in code and the database (every table has a 'tenant id' key)
* container level multi-tenancy, where you run separate containers and possibly in different namespaces
* virtual machine multi-tenancy, where there are different VMs for each tenant and you can use network isolation as well (NACLs, security groups)
* hardware isolation, similar to virtual machine, but you use separate hardware. Hard to scale this with software, though using something like Equinix metal might work: https://www.equinix.com/products/digital-infrastructure-serv...
These each have different tradeoffs in upgradeability, operations cost and isolation.
Since you identify as a full stack developer first, that probably means you’re not looking for hours and hours of time spent in Excel or QuickBooks or SAP, doing sales forecasting, etc. But those are important for big sales efforts. Instead, find people who like that, and are talented at it with a consistent track record.
I recommend this partially because I followed that approach, and we’ve had our company going for over a decade.
Forget about going after enterprise level customers. Prove yourself to the small and medium sized businesses first.
Before you do any technical work, be able to answer the question: why on Earth should businesses use what you're offering? There's no right answer here, but your answer should be super convincing. I think the most common is that you are able to beat the competition on price (cuz you're going to have such low overhead, I presume), but you'll need more than that.
Hope that helps. As others have said, I believe I'd be more helpful if you were more specific on what you were trying to accomplish.
Best of luck!
For single sign on, SAML for instance, you have to get a ton right with security certificates, xml parsing, manifest rules, signing algorithms, request expiration, etc. SAML (and other single sign-on protocols) are poorly designed and any single mistake is fatal. Some SAML libraries have support for null signing for instance, which allows anybody to sign on as anybody by simply sending a null-signed response. If you don't know about this attack vector you would never think of testing for it. There are many similar SAML pitfalls and you have to think hard about all of them.
For password reset you have to think what kind of tokens you use. How and when they expire. How to protect against length extension attacks (use HMAC).
Anyway, I'm not writing this to discourage you. If you want to go for it, go for it. But enterprise saas software is a serious responsibility and you'll have to work hard at security even though there is no business upside to it.
That’s not the worst perspective to prioritize when building a B2B SaaS product.
You’re right of course about the risk / the trust you’ll have to put into a third party.
The main problem is figuring out a sales process/gtm strategy. As others have mentioned, you would benefit from partnering with someone who knows about the problem/industry and has experience selling to enterprises. Keep in mind this will be the core competence of your company (if you want to make lots of money). The job as the technical lead will look more like consulting than just building and shipping product.
If you're going at it alone, talk to a lot of people involved in the business process you're trying to fix to make sure you understand specifics about why they do things the way they do right now. Sometimes as developers we tend to view company problems as technical issues but they're most likely org/political/social issues. Don't build much just yet, make a visual prototype you can show/pitch and charge for demos/integrating/making-it-work-for-them-to-test-it.
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
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.
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.
Give yourself time. One of the key things enterprises look for is the maturity of the company that supports a product. You’ll need to mature into a governance model, support model, and long-term viability that enterprise buyers recognize and feel comfortable with. Enterprises also make purchasing decisions slowly. It can take years to make a sale.
Enterprise and B2B are not entirely the same thing. When you’re thinking about your segments, think about business size and revenue. Billion dollar companies are different than million dollar companies. Think about the decision-making process and the network connections you have to land your first sale. It’s usually easier when you have a prior relationship with your buyer and if the business has a sole decision maker. Otherwise, be prepared for a lengthy sales process that may not result in anything other than a “thank you” email. In the enterprise, your product actually includes the technical product as well as sales/support that goes along with it.
Having said that, some GTM strategies that could cut through the noise: user-led (pricing within individual corporate budgets), open-source, free trials, etc. SaaS is a good idea but it depends on business size/industry/culture. Generally, non-regulated industries have a more open culture to trying new things.
- 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.
https://www.enterpriseready.io/
They also provide examples for certain features, which helps getting the hang of it.
For features: I think https://www.enterpriseready.io/ has a nice checklist of the 12 things commonly required for enterprise apps (SSO, Audit logs, RBAC, GDPR, etc)
All the enterprise features like SSO, integrations, audit trails, etc can be built when a customer is asking for them — these are largely solved problems. These are probably attractive problems because they are engineering problems and you are an engineer.
Ignore them and focus on the business problem. “Does my app solve a burning need for my customers?”. Read “The Mom Test” to get in the mindset of answering that question. That is all that matters right now.
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.
First thing should not be finding out what what your customers want.
First thing should be finding out IF THERE EVEN ARE CUSTOMERS for your product.
A product idea that doesn't have any market won't be successful. So find out if there are people who have a problem that can be solved, then try to solve that problem. Additionally the problem has to be annoying enough so people are willing to pay to make it go away. If you have those two, it's a great start.
First of all, you have to work through these questions and validate your assumptions on all of them. Then you'll have a chance to spot ways of solving them. This is why a lot of startup products partner with large existing suppliers in the domain as you can piggyback of their reputation and operations. But without knowing your specific needs, you can't yet guage whether this approach would be right for you.
Think beyond that space.
- 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.
- Setup a demo account in sandbox, fill it with data as close to real world as possible. Makes it super easy during sale pitch. You let your product talk instead of you.
- Consider multi-tenancy from right off the bat. It's hard to add it later.
- Look up your domain specific compliance requirements and build those from ground up. Some such as SOC 2 don't hurt. While at it, get a decent security vendor to pen-test your product, work with them to fix high/medium priority issues and get them to issue certificate. It builds credibility with customers.
- Reports. Typically the admins will require a bunch of reports. It's best to give them a CSV/Excel download and let them slice and dice in their spread sheet software.
- Users will make mistakes so always use soft-delete. You can always do hard-delete after a few months.
[1] https://owasp.org/Top10/
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.
What am I missing?
Authorization is a whole other ball of wax. You can sometimes get by with RBAC, but it is far more often entangled with business logic. I've seen a set of new companies that offer outsourced authorization like permit.io and cerbos, and for an app of a certain complexity, think they are worth evaluating.
How do you prevent a user from assigning themselves roles they shouldn't? Is there some kind of cage preventing escalation?
If you need all the features, it's a good deal, but you rarely do unless you are building something like Notion or Jira.
Open source components (Ory) can do the basic cryptography, and if you go completely from scratch, the NIST and their European counterparts have well-written standards for how to do this, and if you follow the relevant parts of the standard, you will get something essentially perfect without the baggage.
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 users. Mostly focuses on username and password, but is entirely adequate for getting started.
Ory (suggested elsewhere in the thread and by you) is OSS and free. Again, you have to operate it, which isn't free, but you get the benefits of upgrades and a team focused on auth.
Keycloak has a lot of features and is free if your run it yourself.
Supertokens has a basic plan that is free for 5k users.
There are many more, as well. And that is to say nothing of the OSS libraries (like devise/omniauth) which you can leverage.
Coding this from scratch seems like an enormous waste of time for something that is not typically a differentiator. At the least, use an OSS library or auth service and limit yourself to the features you need.
Customers pay for features, not for auth. Auth is just the front door to the application.
You'll have to dig a bit deeper into each pricing page to determine what actions make a user 'active'. I'm not aware of anyone who does MAU calculations on a day to day basis; monthly rollups are the standard.
Some folks charge per MAU (FusionAuth does) but in a band (the first 10k MAUs for a FusionAuth paid version are all one price).
HTH.
I also don't buy the argument "don't waste time on something that is not a differentiator" - I'm going to spend time on it anyway, so I might as well spend the time in the most productive way possible. Also, I guarantee that your solution isn't bug-free, and eventually one of them is going to bite me, so that also factors into the decision about time.
The basic version of authentication is actually really simple. When you add SSO, RBAC, Oauth2, ACLs, and other stuff, it gets really complicated. People should make intelligent decisions about what they want to do here rather than just using a provider.
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.
Don't outsource critical 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.)
a soc2 is also a choose-your-own-adventure cert: you describe your processes (within constraints imposed by the goals you must achieve per the soc2 principles), and then you get audited on following your process.
Like I want to Build a property saas should I start prospecting first
I didn't. I paired w/ a cofounder that is a fantastic salesperson. He ran gtm, I ran prodeng.
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.
[1] https://en.wikipedia.org/wiki/Maker-checker
We thought we had a solution to a problem. We were told from the end users we had a solution to the problem. We thought we knew the value to those people as far as pricing for the product. But the actual buyer didn’t at all value our product the way the end user did, especially when factoring switching costs etc and it was crippling.
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.
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.
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
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.