I was a bit disappointed to see yet another authentication service advertised. I'm still looking for a reasonable open source (or SaaS) framework for managing workflow / action assignment & tracking. It seems like everyone who builds one immediately tries to sell it with a front end rather than a component.
Be enterprise-ready: reasons not to build enterprise features
31–40 of 40 posts
Re: Be enterprise-ready: reasons not to build enterprise features
#32IMO this is a pretty narrow definition of enterprise-ready, which is often actually more of a focus on being able to map a large organisations process into your application, and also how it scales with the number of users (ie your app is made for 1000 people to use rather than 10, and scales from a process/organisational perspective not just a technical perspective). Small organisations are more willing to change pro…
We are initially focused on common undifferentiated enterprise features, but this is just the first step, we have broader plans for developer-first security tools.
Re: Be enterprise-ready: reasons not to build enterprise features
#33I was reading an article by the other day about a person who had a disability that caused them to be highly disturbed by meaningless animations on the web. I might have voted it up but those stupid memes drag this article down to a low level.
Re: Be enterprise-ready: reasons not to build enterprise features
#34I was a bit disappointed to see yet another authentication service advertised. I'm still looking for a reasonable open source (or SaaS) framework for managing workflow / action assignment & tracking. It seems like everyone who builds one immediately tries to sell it with a front end rather than a component.
Would love to hear more about the "framework for managing workflow / action assignment & tracking" that you are looking for. Could you please elaborate a bit more?
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!
Re: Be enterprise-ready: reasons not to build enterprise features
#35A good resource for things to consider when building for Enterprise Ready is this: https://www.enterpriseready.io/ It's not a product, just a list of things to consider. (not affiliated, saw it recently, and thought it was cool).
Re: Be enterprise-ready: reasons not to build enterprise features
#36Earlier quoted context omitted.
Would love to hear more about the "framework for managing workflow / action assignment & tracking" that you are looking for. Could you please elaborate a bit more?
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 tha…
Re: Be enterprise-ready: reasons not to build enterprise features
#37Earlier quoted context omitted.
Would love to hear more about the "framework for managing workflow / action assignment & tracking" that you are looking for. Could you please elaborate a bit more?
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 tha…
Re: Be enterprise-ready: reasons not to build enterprise features
#38Earlier quoted context omitted.
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 tha…
This sounds super interesting to me, particularly as an API-first or API-focused product to be used inside other products. I’ve been chewing on a related idea for managing aspects of data compliance. My email is my username at gmail if you’d be up for a conversation about this.
Re: Be enterprise-ready: reasons not to build enterprise features
#39Seems like these enterprise-in-a-box services are taking off and I like the role that they play in the ecosystem. That said there's a lot more to it than what Boxy offers – a lot of what enterprises need is about configurability and flexibility for wildly varying use-cases, as well as general compliance. It looks like Boxy (authors of this post) are building more logging and governance features soon which I think wil…
I just read your blog post and found it interesting; thanks for sharing it. I'm one of the co-founders at BoxyHQ, agree that there is more to it, enterprise requirements are always different, some certifications could be standard but if you double click each enterprise has its own complexities. From our side, we have started with these features since we have seen they are common pain for early-stage startups, but in…
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!
Re: Be enterprise-ready: reasons not to build enterprise features
#40Earlier quoted context omitted.
I just read your blog post and found it interesting; thanks for sharing it. I'm one of the co-founders at BoxyHQ, agree that there is more to it, enterprise requirements are always different, some certifications could be standard but if you double click each enterprise has its own complexities. From our side, we have started with these features since we have seen they are common pain for early-stage startups, but in…
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 i…