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.
- 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.
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.
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.
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.
Often in enterprise after people use your app, they want to automate things themselves, or integrate your app into some other system. Having APIs means there's no extra work. Anything they can do in the app, they can also automate.
If there's a database involved, having a read replica that your users can access can help them answer any business question very quickly. Many business people, report writers, engineers, etc.. are very well versed in SQL, and often your app is just the gate keeper to ensure the database is updated correctly. The database is the real 'state of the company' that everyone is constantly querying for answers. As well as putting reporting layers on top of such as Excel, Tableau and Power BI.
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.
Anyway
Most important thing is simply: find a problem a business is willing to pay for to solve (i.e. it costs them money and time). Set up a simple MVP if that's possible and grow from there.
Do NOT listen to soc/iso talk on this thread, they are an distraction and you will have a lot of time to do them later. Security audits, certificates etc. Might be important LATER when big accounts will ask for them but not at the beginning (unless you are doing fintech etc).
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.]
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.
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!
I wouldn’t be too worried about things like SSO, that’s extremely well-tread territory for thousands of Saas founders so getting advice won’t be hard.
If it’s not a bottoms-up, self serve Saas product I’d be almost 100% focused on finding the proper decision makers (who also have budget at their disposal) at enterprise orgs and talking to them first before building.
Once you have a repeatable strategy for successfully getting the attention of the correct decision-maker types, THEN I’d worry about all the implementation details. Otherwise you don’t have a business.
This is harder than it looks because the people with real spending authority also typically have full calendars.
iso 27001, soc2, Pcidss
Sso with force logout
Allow fine granular role based access (RBAC) to let distinguish between all kinds of roles. Admins, super admin, bots. Have audit logs available.
Multi tenant saas and Encrypt the data on a per customer basis or even per department of a customer.
Publish your api spec as OpenApi/Swagger/raml in order for api gateways to be consumed. In case you offer some kind of web hooks, publish the api spec of your webhooks as well.
Support custom truststores, key stores.
Support a private access to your api, e.g. a VPN or a vpc private endpoint in the same AWS region where your customer might have their cloud environment running. Or fixed IPs which will be used for egress/ingress traffic.
Document your supply chain. How do you program the software? Which Saas providers do you use yourself? In case for Europe: how do you ensure the data stays in Europe (I.e. in case you might be monitoring your saas product with for example pager duty, then maybe the data might be hosted in the us. Therefore ensure your supply chain is also in Europe. I think OpsGenie has an Europe endpoint)
Provide support contracts and SLAs.
Look at the evolution of how AWS has changed their services.
I see your HN account was created in 2021. If you haven't been watching this space for a long period of time (6-10+ years), go back and watch the AWS re:Invent keynotes.
You'll notice a trend of starting out with a very simple IAM and then evolving into vastly more complex mechanisms of authentication, authorization, auditing, accounting, network policy, and representation of multi-tiered organizational hierarchies between all of these systems.
This will give you an idea of what the MVP looks like, but also allow you to plan for what WILL be requested in the future (even if it's a stupid idea). Tragically, the briefest way I can summarize this is to say: "give them a Rube Goldberg machine so they can take Conway's Law and run with it."
context: I've worked exclusively on the intersection of FL/OSS and "Enterprise" software for almost 20 years.
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.
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!
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.
- 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.
If an organisation is using an actively developed custom system that is decades old, then you will need decades of development to replace it. This should be obvious, but I can already feel many people reading this shaking their heads in disagreement.
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.
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.
Your considerations and things you need to worry about will vary greatly based on your stage (early-stage startup, late-stage startup, public, etc.), market (fintech, health-tech, etc.) and customers you target (early-stage startups or bigger, Fortune 100 types). As others have stated, it's important to figure out the go to market strategy first by talking to potential customers before building anything.
Assuming you've pressure-tested your idea and built an MVP/early product that shows some traction, you'll want to take care of app + data security basics (authn, authz). Guides like the OWASP Top 10 and your future customers will guide you in the right direction here.
On the authz side (since that's my area of focus) - multiple comments have mentioned RBAC (role based access control) which most enterprise/SaaS companies end up implementing but it's rarely where authz stops. As products evolve and grow more complex over time, you'll need to implement some form of fine-grained (object/resource based) authorization (ex. attribute based, relationship based access control) as well as auditing capabilities, all of which customers will ask for at some point.
In an ideal world, you'd have all of these capabilities already built but that's rarely the case. In reality, you prioritize and implement these over time based on security needs, risk and customer requirements.
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.
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).
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.
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.
Overall though I would heed the advice of others in this thread and focus on the buyer/customer. Enterprise SaaS is all about effective (note – not even necessarily elegant) solutions to important business problems. Absolutely everything else is secondary until you're at a larger scale.
Just as an example this blog post was written with post-traction / scaling startups in mind because before then everything on your mind should just be buyer/buyer/buyer. Even past $100m ARR it should still be buyer/buyer/scaling.
This is one of the reasons I'd probably never go solo unless I had little or no choice. I've seen it up close in a small (5 to 7 people) company selling to enterprise and from further away (I very rarely interact directly with clients & prospects at all these days) as part of a larger company (in both cases working on software to manage T&C and other regulatory requirements, mainly for public facing investment banks and insurance vendors), and I would find it infinitely infuriating.
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 Lightsail or another simple VPS solution and create a simple monolithic app using a framework I knew well.
[1] let me emphasize again that I’m not suggesting serverless unless you know it and I’m definitely not suggesting DDB unless you both know it’s limitations and have very well defined query patterns.
Go read the Cloud Security Alliance’s CAIQ questionnaire. There’s much more to serving enterprise than just your code quality and cloud platform. You need to operate the business in a safe way.
- Who is going to manage your software inside the business?
In my case we expected that by now almost all of those companies would have internal IT personnel or at least some qualified IT partners but it wasn't based on anything... and it wasn't true, this was a major pain point. We had to create a "sibling" company that handled user training, implementation, integration and many other things because most of our customers couldn't do this themselves. As you might understand customer spend on those services is higher than that on the actual SaaS but with way lower margin, think of Salesforce for example: many SF customers spend way more in partners than on software licences, and many if not most SF customers need a partner to implement SF and cannot do it themselves.
- Which problem are you trying to solve for those companies? Is this problem linked to other stuff?
When you start your project it may seem that it is a perfect fit and solves all the problems you are imagining, but as soon as you start selling you notice that those problems you are solving are just the tip of the iceberg. In a short time you may find yourself with a software that actually only solves 5% of the bigger problem and now there is a 95% of unknowns that must be addressed. Maybe in those unknowns there are other SWs, maybe legacy SWs, and you need to communicate/integrate with them or else your offer doesn't make sense to the customer.
From my anecdotal experience you need to find some initial customers that look like your potential target customer and sell them your idea, maybe having just a simple prototype, and only after you have a few you start building for real keeping those early adopters in the loop. If you're not a seller find a sales co-founder, sales are extremely important when dealing with business.
Please note: I don't know what you are building so those adivices might be totally irrelevant, I hope they can help you anyway :)
Have you ever sold something?
If you are doing UI/UX worry only about what it should look like to be maximally pleasant to use, worry about how later.
If you are doing marketing/sales, worry only about what sells and what gets traction, not about what you want to or think you should be building.
It took me a long time to figure out I was sabotaging myself by thinking about implementation while making other decisions.
Being a dev is just a tool in your toolbox but you aren’t really a software engineer anymore so behave as such.
Then the other stuff, but that is not so important.
EnterpriseReady - https://news.ycombinator.com/item?id=34290249
But I've seen apps out there where a screen takes 10+ seconds to load, and often that fails and you have to try again! That is absolutely unacceptable.
I am sure that at the very least you'll get some ideas on how to approach this. I have aggregated different sources on that, but I am not an expert myself at this point in time.
Enterprise scale stuff has different requirements than just business software. In general enterprises have scale problems and demand you integrate into their workflow.
Never design enterprise software unless you have a domain expert and a customer in hand. Their requirements will make it impossible to do anything else.
More at https://youtu.be/GMIawSAygO4
https://www.enterpriseready.io/
They also provide examples for certain features, which helps getting the hang of it.
Do 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?
Think beyond that space.
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!
Then flexible reporting.
Then security.
Then UX design.
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)