Be enterprise-ready: reasons not to build enterprise features (opens in new tab)

I don’t think people are thinking about how they come across or what they are trying to communicate, they just do it because other people do it.

Maybe they're mimicking messaging apps like Telegram.

It's just another way people say "me too" online.

See https://alistapart.com/article/designing-safer-web-animation...

Cool, glad you enjoyed it (I enjoyed yours as well).

The developer-first security angle is interesting – not sure if you include this in your categorization of security, but what I most frequently see SaaS companies / developers struggling with is data governance. For example, ensuring that they can comply with GDPR or CCPA deletion requests, store data in local geos, etc. A lot of this gets built by SaaS companies in-house.

The flexibility piece is different but comes up in sales more IME. Essentially every CRUD action in an enterprise SaaS app ought to be logged and accessible by API (which creates the same root problem of requiring a lot of developer time). But it manifests very differently in sales cycles from complying w/ GDPR:

* Regulatory compliance is often more of a box checking exercise for buyers (like SOC2)

* Having flexibility to log and manipulate everything via API is often a line-by-line evaluation of "can you meet X use case that we have for data integration" or "can you handle Y risk that we're worried about"

Good luck building Boxy!

I'm not saying its a bad thing actually.

I think its similar to running a bank, if you cannot protect the value (money) then you are not really a good bank. The problem is people have been pretending they are not a bank and trying to skirt protecting their customers for the better part of 20 years, especially in SaaS.

Yes, it's not practical, and by design. In effect, this is simply acknowledging the reality that if they want to ensure a certain process, then someone has to bear the overhead of monitoring and control; so if a company wants to buy some sensitive service from a solo founder or a smallish company then they have to take responsibility themselves, and they can only delegate this duty to vendors only if the vendor actually has certified capability to do this high-overhead process.

It has some parallels to earlier initiatives like PCI DSS for payment cards which effectively said "If you can't do this list of requirements, then you'll have to delegate the sensitive stuff to someone who can", ensuring that every mom&pop pizza shop doesn't have a full list of their customers credit card numbers unencrypted on a publicly exposed database. It doesn't prevent all breaches, of course, but it did make them fewer.

It depends on the risk tolerance of your customer, but you would likely fail.

The reason being: What happens if you get struck by a bus? Your business dies overnight (or until the hosting bill doesn't get paid) and now your customers are screwed.

Many of the controls are about what happens when staff depart, both planned and unplanned? What is the power structure in the org? How do you prevent employees from damaging your business operations?

Resilience is important to any enterprise, and many audits now evaluate how hardened your business is.

Maybe a morbid startup idea of "I'll ensure business continuity if you die so you can pass SOC2" lol

This is, unfortunately, a legitimate reason not to make solo suppliers a part of your supply chain. Inability to implement things like mandatory vacations and separation of duties does mean only you need to be compromised to become a threat vector, and that is easier than compromising multiple people. It doesn't mean you can't run a solo business, but you should focus on selling to organizations that are not likely to become the target of a supply chain attack.

I wonder if you can hire a law firm or a consultancy to help with this. They would have people on staff who can be legally designated as your point-of-contact for a given role?

Once you hit a certain scale it is probably inevitable that users will want to assign, receive, and manage actions (or events, or triggers) inside the product. "Workflow" or "work management" orchestrates all of the backend activity that ensures actions can be recorded, zip around to assignees, have statuses updated, comments entered, and so on.

There are a few tools out there like Elsa and Microsoft Rules Engine that stay in the backend, but are still fairly rudimentary in nature. So far as I know there's no "plotly" or similar A-tier framework that solves this problem for workflow. Most groups that have done it instantly monetize it with their own front end (Asana, Monday.com, etc.) which makes it difficult to justify the effort to integrate if you are going for a lighter weight application. Hope that helps clarify!