[HN Gopher] Ask HN: Main things to consider when building an app...
___________________________________________________________________
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.
Author : AM1010101
Score : 140 points
Date : 2023-01-07 13:10 UTC (9 hours ago)
| HarrietJones wrote:
| 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 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.
| kgc wrote:
| The customer is usually not the user.
| midenginedcoupe wrote:
| My 2p is understand what your target customers need from their
| suppliers in this area. Are they going to require ISO27001
| certification before they even consider your product? Are you
| going to have to demonstrate robust business continuity
| procedures for them to take you seriously (e.g. are they going to
| really trust their critical processes to a single guy who could
| get run over tomorrow?) Is there legislation you have to
| demonstrate compliance against in their domains?
|
| 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.
| pabe wrote:
| Enterprises often have deals with cloud providers. Offer to host
| your app on "their" Azure / AWS / whatever. That way, they're
| taking responsibility for their data.
|
| 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).
| 01acheru wrote:
| There are lots of really useful advices on all other comments but
| there is something I haven't seen mentioned yet. I had those
| problem when building a SaaS targeted at small to medium business
| (up to 200M annual revenue).
|
| - 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 :)
| fakedang wrote:
| Don't build for small business. They are the 20% customers with
| 80% of the problems. Large business problems are lucrative and
| you can use them to name drop on small businesses once you want
| to go to that market.
| scarface74 wrote:
| 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 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.
| secretwho wrote:
| At minimum, implement your application to address the OWASP Top
| ten: https://owasp.org/www-project-top-ten/ Document how you
| addressed these. Check with every new feature or change if you
| create a new vulnerability. Don't store data without a clear
| purpose Don't invent your own encryption. Think how data is
| erased or archived Separate the data of different tenants
| Implement a proper audit trail Once you gain traction: ask an
| independent party to do a penetration test. Be transparent to
| customers about vulnerabilities discovered and patched. Limit
| third party dependencies to components that get regular security
| patches. You need to proof your security is better than what your
| customers have in-house.
| mannyv wrote:
| Enterprise software is different from business software.
|
| 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.
| latchkey wrote:
| Build a product your customers want.
| catsarebetter wrote:
| Fyi enterprises and medium to small business are different.
| Enterprise you really do need to love sales, small business you
| have to know sales but it's much less annoying.
| PradeetPatel wrote:
| For the non technical side, depending on the size and nature of
| your clients, you may want to consider certain compliance
| requirements. Such as GDPR, ISO, and SOC.
| candiddevmike wrote:
| Have a potential customer before you build anything.
| ensemblehq wrote:
| I've been on both sides of the table: software vendor/consultant
| and buyer so I can share some other insights others may not have
| yet. Your question is still too general and without knowing your
| product, it's hard to advise on go-to-market.
|
| 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.
| revskill wrote:
| Data consistency is top priority.
|
| Then flexible reporting.
|
| Then security.
|
| Then UX design.
| spapas82 wrote:
| Some things that I think are useful for an enterprise app:
|
| - 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.
| rst wrote:
| If you're SaaS, enterprise doesn't necessarily care what
| database _you 're_ using -- and some of them may be a polyglot
| even internally. (My dayjob is a SaaS that's old enough to have
| started on Oracle in part because we thought it would make us
| look "serious" to enterprise clients, which include some fairly
| large financial institutions. We just finally turned off the
| last Oracle server, after switching to Postgres; no one cared.)
| spapas82 wrote:
| Yes that's true. But please consider that some orgs prefer
| self hosting their software. In this case using their
| database would be preferable.
| vulcan01 wrote:
| In that case, only using ANSI SQL will help (i.e. no
| vendor-specific queries).
| bottlepalm wrote:
| Build your app to expose APIs and then have your web client
| consume those APIs by doing client side rendering. No need to
| worry about having to do server side rendering for SEO in the
| enterprise space!
|
| 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.
| dspillett wrote:
| If you are alone, consider taking on someone for sales and
| finance. Selling to large businesses is a long, slow, drawn-out
| process, with much "paperwork" and an endless array of reasons
| for meetings. On your own you'll have no time to do actual dev or
| design work!
|
| 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.
| cddotdotslash wrote:
| I started a side project turned bootstrapped B2B SaaS that was
| eventually acquired, so I can share a bit of what I learned. Some
| day I'll write up a longer list of lessons.
|
| 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!
| safeerm wrote:
| Good advice!
| RonaldOlzheim wrote:
| Good advice. What is your linkedin? You can also add me if you
| like. Ron.
| hackitup7 wrote:
| Wrote a blog post on this one about a year ago that has a list of
| what I've seen:
| https://staysaasy.com/product/2022/02/19/enterprise-selling-...
|
| 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.
| 999900000999 wrote:
| This feels a bit too vague for anyone to give you advice on.
|
| 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?
| xwowsersx wrote:
| No, OP said: " things that worry me about this space are
| security best practices, providing features like corporate
| single sign on and handling data that customer[s] expect to be
| healed [handled] very securely."
| dchuk wrote:
| Read the book Crossing the Chasm by Geoffrey Moore
| [deleted]
| rqtwteye wrote:
| From my experience the technical part is easy. The real problem
| is how to sell it to enterprise.
| jrvarela56 wrote:
| Not to be dismissive, but if I were you, I would leave the
| technical aspects of a B2B/Enterprise product for later.
|
| 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.
| curiousllama wrote:
| I once wrote a business case for something I wanted to build. I
| was really interested in the solution, but thought I should be
| specific about the type of customer that would benefit. It was
| a whole detailed doc of imagined problems & how my solution
| would fix them.
|
| 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
| kasey_junk wrote:
| Note also that enterprises have extremely long and high touch
| sales cycles for most products. If you don't know someone who
| has actually sold the kind of thing you are selling into an
| enterprise just figuring out who to talk to can take forever.
|
| 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.
| jrvarela56 wrote:
| Just to give a sense of how long these things take: you have
| to make the same presentation to the same people because it's
| been so many months they just forgot what you said the last
| time.
| worewood wrote:
| Performance and reliability are things sadly missing from
| corporate apps. You don't need CDNs, caching servers and all that
| good stuff; if a screen is taking 3secs instead of 1sec to load,
| no problem. No problem it being web-based instead of native,
| either.
|
| 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.
| ianpenney wrote:
| What happens when your unencrypted laptop gets stolen or lost?
|
| 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.
| czbond wrote:
| Don't build an app / SaaS / etc. Too competitive of a landscape.
|
| Think beyond that space.
| Rastonbury wrote:
| Is this sarcasm? You can make totally new product in the form
| of app/SaaS in a niche with no/few competitors. It doesn't have
| to be yet another CRM/analytics tool
| dna_polymerase wrote:
| HA! Have a look at this website, it gives you plenty of things to
| think about.
|
| https://www.enterpriseready.io/
|
| They also provide examples for certain features, which helps
| getting the hang of it.
| silvertaza wrote:
| Hi there, I just wrote about it here:
| https://silvertaza.com/product-market-fit/
|
| 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.
| vishnugupta wrote:
| 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.
|
| - 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/
| bradgessler wrote:
| https://www.enterpriseready.io/ is a good starting place that
| enumerates most of the great points made in the parent comment.
| x0x0 wrote:
| Background: cofounded an enterprise saas company.
|
| 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.)
| moneywoes wrote:
| How did you build your sales skills and get those first 10
| customers?
|
| Like I want to Build a property saas should I start
| prospecting first
| x0x0 wrote:
| > How did you build your sales skills
|
| I didn't. I paired w/ a cofounder that is a fantastic
| salesperson. He ran gtm, I ran prodeng.
| stevesimmons wrote:
| When would you prioritise SOC2 before ISO27001? And when the
| other way around?
| x0x0 wrote:
| I'm not an expert on this, but I'd start with a soc2 type
| 2. soc2 served us well in the US. Some of Europe prefers
| 27001, but we sold into the EU with just a soc2 in the
| beginning.
|
| 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.
| mooreds wrote:
| 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); 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.
| moneywoes wrote:
| What about next js auth
| mooreds wrote:
| If it fits with your tech stack, definitely worth
| evaluating.
| pclmulqdq wrote:
| I'm not entirely sure I agree with this - most auth providers
| are very expensive, and if you don't need the full-featured
| offering, you are way overpaying for the engineering time to
| build your replacement.
|
| 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.
| mooreds wrote:
| > 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 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.
| braveyellowtoad wrote:
| Thanks for sharing. Do you know of any auth providers
| that charge based on auth event (login / logout /
| password change / etc) rather than per user?
| mooreds wrote:
| The big cloud providers have substantial free tiers (50k
| MAUs). Cognito, Firebase and Azure AD B2C all have a
| similar free tier. After you go through the free tier,
| you pay per MAU ($0.005 per MAU, according to
| https://aws.amazon.com/cognito/pricing/ , I think similar
| for the other providers. For smaller players, I think
| Stytch is 10c/MAU/month, where an MAU is any interaction
| with the Stytch service (login in all the many forms).
| https://stytch.com/pricing has more.
|
| 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.
| sebmellen wrote:
| IMO https://ory.sh has completely changed this calculation.
| With the help of Ory Kratos it makes sense to roll your own
| auth.
| mooreds wrote:
| Do you mean to use Ory Kratos in a self-hosted manner? From
| a brief look it seems like you aren't rolling your own auth
| when you use this, but rather integrating it into your
| application.
|
| What am I missing?
| sebmellen wrote:
| 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).
| mooreds wrote:
| Gotcha. There are still security concerns with the UI,
| but I agree, offloading the heavy lifting of password
| hashing, preventing enumeration attacks, and algorithm
| selection to a dedicated system makes sense.
|
| 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.
| NetOpWibby wrote:
| This is excellent, thank you!
| mywacaday wrote:
| 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.
| throwaway20222 wrote:
| This is a really solid reply - I would emphasize "know your
| buyer."
|
| 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.
| dieselgate wrote:
| I wasn't familiar with the acronym RBAC (but certainly familiar
| with the concept) until web searching for it. First link was
| from solarwinds.. nope, found an okta link.. yep! Thanks for
| the well thought out list this was helpful
| twojacobtwo wrote:
| Since I had the same experience just now, it seems useful to
| post the answer here. In computer systems
| security, role-based access control (RBAC) or role-based
| security is an approach to restricting system access to
| authorized users. It is an approach to implement mandatory
| access control (MAC) or discretionary access control (DAC).
|
| https://en.m.wikipedia.org/wiki/Role-based_access_control
| dieselgate wrote:
| Thanks for the call out
| roflyear wrote:
| Don't do soc just to do it. It's a lot of overhead if you don't
| need it, and your clients if they require it should give you a
| grace period.
| dang wrote:
| Related ongoing thread:
|
| _EnterpriseReady_ -
| https://news.ycombinator.com/item?id=34290249
| jodoherty wrote:
| Build and design for multi tenancy all the way down to your
| schema.
|
| 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.
| fullstackchris wrote:
| As an alternative, if you containerize everything in the stack,
| you can simply spool up another seperate and isolated stack of
| containers for each given customer. Then it's also trivial if
| they want it 'on premise' somewhere or 'in the cloud'. No need
| to try and add complexity at the schema level and make a
| monolith support multiple tenants.
|
| 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.
| mooreds wrote:
| You can do this with containers, or, if the price point is
| right, with VMs for even more isolation.
|
| 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.
| jodoherty wrote:
| I like this idea a lot, personally. Separately deployed
| customer instances as an approach for "multi-tenancy" also
| eliminates the need for sharding databases at scale, since
| most of your scaling will just be new deployments. Overall,
| this suggestion has an appealing set of trade offs if you
| have the DevOps chops to pull it off.
|
| 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).
| fullstackchris wrote:
| I realized after commenting if it is specifically a product
| where you actually need / want these customers' data to
| "talk" to eachother, then actually your architecture might
| be a bit simpler - then you can expose what you need
| between all the tenants. I can't speak to this approach
| much more though, since I haven't done a project like that
| yet.
| scarface74 wrote:
| This is absolutely the worse idea possible. I would never
| base my business on a technology that's not widely used.
| [deleted]
| fullstackchris wrote:
| 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
| browningstreet wrote:
| There are additional requirements about exporting logs in real
| time (Splunk, etc), and sharing data via mechanisms like S3, if
| your service needs to sell to highly regulated industries.
| You'll need third party audit findings as well.
| pryelluw wrote:
| Do you have any business experience?
|
| Have you ever sold something?
| hectormalot wrote:
| Enterprise software is all about sales.
|
| 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)
| mikkom wrote:
| I have been a CTO/founder in few b2b saas services for maybe
| 15-20 years (one was scandinavian market leader with 100k+
| users).
|
| 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).
| la_fayette wrote:
| I would use a standard open source product like keycloak for user
| management and all related permission, authentication and
| authorization handling. Most requirements like you said sso,
| connecting to active directory, etc can be solved out of the box
| then. When working with such a product you learn a lot about
| security, as you need to configure all the things.
| spion wrote:
| I can't second this strongly enough. You _will_ be asked for
| SSO, SCIM and so on very quickly by any sizable business. Using
| a mature auth solution will save you a _lot_ of work.
|
| (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)
| konha wrote:
| Google Cloud has Identity Platform. Basically Firebase Auth
| re-branded.
|
| It's meh. At least compared to polished / feature complete
| solutions like Auth0.
| karmelapple wrote:
| Find a cofounder or two who enjoy the sales and outreach aspects
| of things.
|
| 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.
| rubberband wrote:
| My advice would be to get waaaaaaaay more specific about what you
| want to do, then find a business partner who knows the "ins and
| outs" of the industry and has a few contacts you folks can use to
| get your foot in the door.
|
| 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!
| mch82 wrote:
| Study GitLab. They've done a great job of creating a product that
| enterprises buy. Their strategy has evolved over the years.
| Because so much of what GitLab does is public you can learn from
| them instead of having to relearn everything yourself.
|
| 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.
| indymike wrote:
| You can wast a lot of time and money pursuing enterprisey
| features and miss the boat completely.
|
| 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.
| weitzj wrote:
| For insuretec/fintec
|
| 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.
| Def_Os wrote:
| Great answer. It might dissuade people from starting A SaaS
| company, though, LOL.
| kcsavvy wrote:
| From 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 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.
| akuji1993 wrote:
| Adding to this:
|
| 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.
| nnurmanov wrote:
| 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.
| ericmcer wrote:
| Separate your engineering brain from the other aspects of what
| you are trying to do.
|
| 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.
| dinkleberg wrote:
| Much will depend on the type of businesses you're going after. If
| you're targeting government agencies and/or financial services
| organizations, you'll find that their requirements will be a lot
| steeper than your average software company.
|
| 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.
| jonahbenton wrote:
| There are books/tomes written about each of those topics, more
| than can be written here, but the place to start is not to build
| at all, but instead find ways to talk to potential users and
| buyers and their specific pain points, use cases, and your
| proposed solutions/features/workflows. This can be turned into
| slide decks and Figma interface walkthroughs without writing any
| code. These can be used to line up interest, piloters, potential
| buyers.
|
| 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.
| gizmo wrote:
| Frankly, you have no chance of making a secure product if you
| don't have a ton of experience in this area.
|
| 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.
| konha wrote:
| The obvious solution to all these problems is to not implement
| them yourself and use a platform like Auth0 or WorkOS.
| gizmo wrote:
| That's a solution only from a business perspective. Some of
| these SSO platforms have a "move fast break things" attitude
| to software development and a security track record to match.
| konha wrote:
| > That's a solution only from a business perspective.
|
| 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.
| thebeardisred wrote:
| I searched through the comments and was surprised no one had
| mentioned this:
|
| 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.
| venins wrote:
| Ready to deploy your service/product on-prem environment. The
| main problem with on prem deployment is maintaining multiple
| versions. try to make sure you have better test coverage from day
| 1. in saas its easier to push the changes but on prim setup even
| minor update will take months from taking approval to deployment.
| code_runner wrote:
| If the smaller companies I've worked for are any indication...
| don't get hung up on branding this app. Be able to swip swap a
| logo and call it a day.
|
| 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.
| cschmatzler wrote:
| To add to this, I have an application in production with a
| client right now that literally doesn't have a logo. The
| favicon is the initial of the service's name on a random color
| background. Nobody has ever asked or commented.
| el_zako wrote:
| I have a client who asked for the favicon to be changed 5
| years after the app was in production.
| mgsouth wrote:
| Cold, logical advice, based on your questions: "don't do it."
|
| 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.]
| pembrook wrote:
| The #1 thing you should be worried about is sales.
|
| 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.
___________________________________________________________________
(page generated 2023-01-07 23:01 UTC)