Launch HN: Flowdash (YC W20) – Human-in-the-loop tooling for operations teams
33 comments
Good idea, works really well for companies with "established" operations.
However, the missing problem we've found (and are investing significant resources internally to fix) is that, in a lot of situations (especially in a startup), you don't actually know what you're doing operationally at a detailed enough level to have engineers write code for, or even humans to "do". You're learning as you go, but still need everything in the database as you do so you can automate thing sooner rather than later.
So, automation is still required. But not yet! You need a way for humans to do things, then automation, and back again...on a "flow" (to use your terminology) that is radically changing as you learn.
In our case, new business opportunities require creating and/or updating tens of millions of rows in our Postgres database, but can start out very small as we learn—say, 5000 independent flows.
Oftentimes, we need to temporarily "fix" things that we've already done a lot of work on—again, with a mix of human and compute tasks, depending on what's going on. Those fixes are temporary and we remove them once the data in Postgres is clean.
Another major area is, for lack of a better term, "tech onboarding". There's a lot of work that's effectively one-off, needs to be done at scale, and yet each day it's something different. (Imaging ramping up some service over four weeks—a literal situation we encounter regularly.) Being able to mix human and automation there is again critical, but really no tooling that I'm aware of exists to help with.
Anyway…congrats on the launch. I can definitely see it working for really well-defined operation systems that just need that extra touch of automation to reduce the busy work when humans are inserted into flows.
However, the missing problem we've found (and are investing significant resources internally to fix) is that, in a lot of situations (especially in a startup), you don't actually know what you're doing operationally at a detailed enough level to have engineers write code for, or even humans to "do". You're learning as you go, but still need everything in the database as you do so you can automate thing sooner rather than later.
So, automation is still required. But not yet! You need a way for humans to do things, then automation, and back again...on a "flow" (to use your terminology) that is radically changing as you learn.
In our case, new business opportunities require creating and/or updating tens of millions of rows in our Postgres database, but can start out very small as we learn—say, 5000 independent flows.
Oftentimes, we need to temporarily "fix" things that we've already done a lot of work on—again, with a mix of human and compute tasks, depending on what's going on. Those fixes are temporary and we remove them once the data in Postgres is clean.
Another major area is, for lack of a better term, "tech onboarding". There's a lot of work that's effectively one-off, needs to be done at scale, and yet each day it's something different. (Imaging ramping up some service over four weeks—a literal situation we encounter regularly.) Being able to mix human and automation there is again critical, but really no tooling that I'm aware of exists to help with.
Anyway…congrats on the launch. I can definitely see it working for really well-defined operation systems that just need that extra touch of automation to reduce the busy work when humans are inserted into flows.
Congratulations on the launch. You are definitely tackling an interesting problem, but I will play a devil's advocate here, because I've spent some time researching similar use-cases for dealing mainly with triage of security & abuse incidents. From the demo, the application seems to be pretty basic, you accept an input and allow users to set actions, take actions, and move tasks through the tasks' life-cycle. You argue that your solution will lower the costs associated with the implementation and maintenance of such applications, but is that really the real added value of your solution for a customer?
In my experience, many teams have already established flows and homebrew solutions that are working "just fine". With your solution in place, how do you convince these type of customers to migrate? Why they should spend time on integrating with your application that offers just fancy manual triage of tasks? You list numerous use-cases which I would say are mission critical (onboarding of customers, triage of risk transactions, etc.) and your solution doesn't really help the operators (=humans) to resolve the problem faster. In my experience, the operators often times have to deal with so called "alarm/alert fatigue", how does your solution helps companies do more with less?
In my experience, many teams have already established flows and homebrew solutions that are working "just fine". With your solution in place, how do you convince these type of customers to migrate? Why they should spend time on integrating with your application that offers just fancy manual triage of tasks? You list numerous use-cases which I would say are mission critical (onboarding of customers, triage of risk transactions, etc.) and your solution doesn't really help the operators (=humans) to resolve the problem faster. In my experience, the operators often times have to deal with so called "alarm/alert fatigue", how does your solution helps companies do more with less?
Hey! Omar here, co-founder of Flowdash. Thanks for playing devil's advocate, and for so many great questions -- I'll try to take a stab at it, and curious to hear your perspective on it as well.
> but is that really the real added value of your solution for a customer?
It's two-fold: 1/ On the engineering side, there's immediate value in freeing up time that can be used elsewhere. Also, because we've built a lot of the features operations teams would need as they scale (e.g. task assignment, analytics, common integrations), we expect a lot less "feature requests" to make their way back to engineering. 2/ Operators are arguably benefitting even more from Flowdash, as they're able to update how they work on their own. Many operators we've chatted with expressed frustrations from being unable to change their workflow, or having to wait 6+ months for engineering to make simple updates to their tools.
> how do you convince these type of customers to migrate?
Short answer is, it depends. If the current process works well, has no pain points, and requires no new features for the foreseeable future -- why change? However, if business is evolving (or team is growing), that's where the maintenance cost of these tools starts to grow quickly. Companies may find themselves building basic task assignment at first. Then, some sort of audit log for debugging issues. Before you know, you need notes for team collaboration. The team grows a bit more and you have to build analytics, and so on... Our goal is to partner with companies throughout their growth with the features they'll need to keep the business running efficiently.
> your solution doesn't really help the operators (=humans) to resolve the problem faster
In the demo video, it's not immediately clear how we help operators resolve their problem faster as the API simply talks back to the core application. However, actions can be setup to automate many of the more mundane tasks that operators have to do (e.g. sending email, triggering alerts, generate documents).
> so called "alarm/alert fatigue", how does your solution helps companies do more with less?
Alert fatigue is real, I'm glad you brought that up. I know it's cliché to say we're the one tool that hopes to bring all the others in a single place... but that's what we're trying to do. For operators, "Work" can originate from many places such as email, slack alerts, another person in the organisation, and so on. Keeping track of all those places makes it hard to be efficient, and also causes things to fall through the cracks. By making it easy to push data into Flowdash from various sources, we want to become the single place where operators have to work from. There's a lot of work to get to that ideal, but that's the vision :)
> but is that really the real added value of your solution for a customer?
It's two-fold: 1/ On the engineering side, there's immediate value in freeing up time that can be used elsewhere. Also, because we've built a lot of the features operations teams would need as they scale (e.g. task assignment, analytics, common integrations), we expect a lot less "feature requests" to make their way back to engineering. 2/ Operators are arguably benefitting even more from Flowdash, as they're able to update how they work on their own. Many operators we've chatted with expressed frustrations from being unable to change their workflow, or having to wait 6+ months for engineering to make simple updates to their tools.
> how do you convince these type of customers to migrate?
Short answer is, it depends. If the current process works well, has no pain points, and requires no new features for the foreseeable future -- why change? However, if business is evolving (or team is growing), that's where the maintenance cost of these tools starts to grow quickly. Companies may find themselves building basic task assignment at first. Then, some sort of audit log for debugging issues. Before you know, you need notes for team collaboration. The team grows a bit more and you have to build analytics, and so on... Our goal is to partner with companies throughout their growth with the features they'll need to keep the business running efficiently.
> your solution doesn't really help the operators (=humans) to resolve the problem faster
In the demo video, it's not immediately clear how we help operators resolve their problem faster as the API simply talks back to the core application. However, actions can be setup to automate many of the more mundane tasks that operators have to do (e.g. sending email, triggering alerts, generate documents).
> so called "alarm/alert fatigue", how does your solution helps companies do more with less?
Alert fatigue is real, I'm glad you brought that up. I know it's cliché to say we're the one tool that hopes to bring all the others in a single place... but that's what we're trying to do. For operators, "Work" can originate from many places such as email, slack alerts, another person in the organisation, and so on. Keeping track of all those places makes it hard to be efficient, and also causes things to fall through the cracks. By making it easy to push data into Flowdash from various sources, we want to become the single place where operators have to work from. There's a lot of work to get to that ideal, but that's the vision :)
Congrats on the launch guys!
Full disclosure, I worked with Nick and Omar at Gusto. I saw firsthand how much software can help an ops team. Since we didn't have Flowdash at Gusto, we often scrambled for resources to empower our operations team. We also probably could've done a better job responding to user feedback since we were so resource constrained.
Having a tool that the Ops team can truly own is a game-changer for that iterative feedback loop and frees up the eng team. Really looking forward to seeing this product grow.
Full disclosure, I worked with Nick and Omar at Gusto. I saw firsthand how much software can help an ops team. Since we didn't have Flowdash at Gusto, we often scrambled for resources to empower our operations team. We also probably could've done a better job responding to user feedback since we were so resource constrained.
Having a tool that the Ops team can truly own is a game-changer for that iterative feedback loop and frees up the eng team. Really looking forward to seeing this product grow.
Congrats on the launch!
This reminds me of Orchestra by B12 in many ways:
https://orchestra.b12.io/
Do you have any thoughts on how you compare to that solution (besides it being OSS and yourselves a company)?
This reminds me of Orchestra by B12 in many ways:
https://orchestra.b12.io/
Do you have any thoughts on how you compare to that solution (besides it being OSS and yourselves a company)?
Thanks! I actually hadn't heard of Orchestra before but will definitely check it out. Have you used it in production before? How was your experience?
I've spoken to folks who've used it and spoken positively about it, but not myself.
I'll point them your way, to see if they can share their experiences.
I'll point them your way, to see if they can share their experiences.
Hi Nick and Omar - excited be this. Synergy with what I am doing at Clause. What to have a chat?
Flowdash has really improved our workflows at my job! We use to have a very tedious human in the loop process which is now much faster and more transparent for the entire team. The main benefit has been turning excel spreadsheets into a more defined work flow with a better user interface.
Looks brilliant!! Have signed up with https://aidem.network as this is perfect for us and potential my sister company. Was going to use Orchestra by B12 but this is a much better package for us + no code
Thanks for signing up! We tried reaching out but the email bounced. Can you message me directly at nick <at> flowdash <dot> com?
That's worrying! Will do
How does this compare to Retool?
We see Retool and Flowdash as being pretty different and, in some cases, complementary. Flowdash is focused on the types of internal tools that are about managing repeatable workflows. By choosing this specific use case, we're able to focus on features that operations teams need as they scale: things like task assignment, documentation, analytics, and SLA's.
Seems like it provides a business logic backend, which Retool does not, and less customizability on the frontend. You could conceivably use Retool to build a frontend to a backend powered here. e.g. in their demo video instead of a Rails app, you could use Retool for the GUI and API calls instead.
They're just different. Retool has a more sophisticated app builder and is much more mature.
Retool can do pretty much everything this thing can do and more. I'm definitely keeping my Retool instance.
Retool can do pretty much everything this thing can do and more. I'm definitely keeping my Retool instance.
This is really cool. My one concern is the pricing strategy. I run a really small ridesharing business with sub 500 users, and $25/mo is too steep for me right now. I was extremely excited to start transferring some of my flows over, but the pricing plan killed it.
Can you talk a bit more about your pricing strategy and how you settled on these plans? I may just not be in your target market, in which case - totally understand!
Can you talk a bit more about your pricing strategy and how you settled on these plans? I may just not be in your target market, in which case - totally understand!
Happy to provide more details. We settled on our current pricing based on conversations with our early customers. For many of them, the alternative was to build something in-house, so they saw our pricing as pretty affordable when compared to the dev cost to build a custom solution.
That being said, we’re pretty early and still iterating on our pricing. If you’re up for it, we’d love to learn more about your use case.
That being said, we’re pretty early and still iterating on our pricing. If you’re up for it, we’d love to learn more about your use case.
Sure. What questions do you have? I replied to another comment down below explaining why the pricing model is out of my reach, but I'll copy it here too:
>
I can definitely put down the $25/mo, but if I want to add two people who can help me out that jumps to $75/mo or $900/yr. I'm not at the stage where I can afford to hire employees yet (I'm the only one, and the drivers are contractors), so this would be a big expense for the company.
>
I can definitely put down the $25/mo, but if I want to add two people who can help me out that jumps to $75/mo or $900/yr. I'm not at the stage where I can afford to hire employees yet (I'm the only one, and the drivers are contractors), so this would be a big expense for the company.
Thanks for sharing your perspective. I can see how per-user pricing doesn't scale well for you.
> What questions do you have? We're curious what specific flows you were interested in migrating over? Who performs this work today? How does it work end-to-end? What tools do you use to track the work? If you prefer to message me privately, my email address is nick <at> flowdash <dot> com.
> What questions do you have? We're curious what specific flows you were interested in migrating over? Who performs this work today? How does it work end-to-end? What tools do you use to track the work? If you prefer to message me privately, my email address is nick <at> flowdash <dot> com.
How much can you afford to spend on something like this?
I can definitely put down the $25/mo, but if I want to add two people who can help me out that jumps to $75/mo or $900/yr. I'm not at the stage where I can afford to hire employees yet (I'm the only one, and the drivers are contractors), so this would be a big expense for the company.
That makes sense. I often find per user pricing to not scale well, though I recognize how well it works as part of each employee’s overhead in a fully funded org.
I may be wrong but this is a "MeToo" workflow automation app/engine. It's nothing that can't be done with open source tools, for much less than $400/year per user.
Just research "Open source workflow automation engine" to see it for yourself.
Good luck guys, WORKFLOW AUTOMATION IS A SOLVED PROBLEM!!! You'll make a buck, it's a big pie, but not from everyone.
Just research "Open source workflow automation engine" to see it for yourself.
Good luck guys, WORKFLOW AUTOMATION IS A SOLVED PROBLEM!!! You'll make a buck, it's a big pie, but not from everyone.
But I think that’s he point. This is aimed at non tech teams. It minimises the amount of work the engineers need to do. Using open source solutions doesn’t because let’s face it an engineer needs to sit down figure out how to install it and they have to maintain it. For example at work we use Wikipedia. That’s open source right. It’s run on a k8s cluster. Open source! This is not a no-cost solution!
This is a problem that I'm facing right now, and the solution looks simple and easy to use.
I wonder if anyone has experience to make a comparison with more complex BPMN tools like Camunda and Zeebe? Or with Salesforce plugins like Process Builder? These came up when I looked at more established solutions for the "business process automation" solutions.
Can Flowdash handle fan-out/parallel stages for example?
I wonder if anyone has experience to make a comparison with more complex BPMN tools like Camunda and Zeebe? Or with Salesforce plugins like Process Builder? These came up when I looked at more established solutions for the "business process automation" solutions.
Can Flowdash handle fan-out/parallel stages for example?
> I wonder if anyone has experience to make a comparison with more complex BPMN tools like Camunda and Zeebe? Or with Salesforce plugins like Process Builder?
I don't have any personal experience with these tools, but am also curious to hear from the HN community here.
> Can Flowdash handle fan-out/parallel stages for example?
Not at this time, but we're adding new features every week. If you're up for it, I'd love to learn more about your use case and how you're evaluating the different options on the market.
I don't have any personal experience with these tools, but am also curious to hear from the HN community here.
> Can Flowdash handle fan-out/parallel stages for example?
Not at this time, but we're adding new features every week. If you're up for it, I'd love to learn more about your use case and how you're evaluating the different options on the market.
This is a very interesting solution, and is going after some of my main pain points right now (I operate within a large operationally focused org with about 20,000+ employees). I signed up for early access, would be very interesting to try out.
Wow, this sounds like a really cool idea! Best of luck!
interesting. couldn't this just be done with a popular kanban tool like jira + Zapier?
You're right, simple workflows can be wired up with Jira + Zapier. Tools like Jira are great at tracking work, but the work itself generally happens somewhere else. Our vision is for Flowdash to not only be the place work is tracked, but also where it's performed. We make this happen by providing common building blocks like reading from a database or kicking off a document signing flow and allowing teams to configure them to match their workflows.
Congrats, looks really great!!
We’re Nick & Omar from Flowdash (https://flowdash.com). We help companies quickly build internal tools to track and execute human-in-the-loop workflows.
We’re built specifically for technology companies that have manual work behind the scenes. For example, a fintech that has a beautiful mobile-first experience for its end users, likely also has a risk team internally approving new accounts, or reviewing suspicious transactions for anomalies. These teams need tools to get their jobs done, but building those tools is time consuming and often means spending your limited engineering resources on internal tools when you’d much rather invest in building user-facing features.
What’s more, maintenance of these tools is an ongoing endeavor. As the company scales and the operations team identifies ways they can improve their workflow, they’re often bottlenecked on engineering availability, forcing the team to implement workarounds in the interim, such as working out of spreadsheets and Slack. These workarounds, while easy to implement, come with pitfalls such as tasks slipping through the cracks or data getting out-of-sync.
With Flowdash, we’re combining the best of both worlds. We want to enable the deep integration that comes from building custom software, while making it possible for operations teams to iterate and improve their workflow over time. We’re able to do this because we’re not trying to be a general-purpose low-code platform, but really focus on use cases where a team of humans works through a backlog of tasks.
Flowdash was inspired by our own experience. Omar and I were early engineers at Gusto and over the course of six years, built several internal tools to support our payments, risk, and payroll operations teams. We saw first-hand the benefits of equipping our ops teams with great tools, but also struggled to prioritize improvements to these tools against user-facing features.
We think of operations teams as unsung heroes. Their work is critical to the day-to-day operations of the company, yet few people externally know they exist. We want to give them better tools to get their work done.
Here’s how it works:
Flowdash’s core primitive is a Flow, which we define as a pipeline of work, where tasks move through a set of stages from creation to completion. Every Flow exposes an endpoint where developers can push new tasks with a single POST request. Users then claim tasks and move them along the pipeline. Additionally, actions can be customized in a number of ways, such as sending email, calling a third-party API, or talking back to your main application. Because stages and actions can be customized without code, the end-user can change how they work without requiring engineering intervention. From the developer perspective, you can think of it as a human-powered background job.
As a concrete example, let’s consider a fintech onboarding new clients. When a new client signs up, a task is automatically pushed to Flowdash. From there, a risk agent reviews the account and decides whether to Approve or Reject the client. In turn, that action issues a callback to the main application to complete onboarding. Here’s a 3-min video setting this up end-to-end: https://flowdash.com/demo.
We’re excited (and a little intimidated) to be on HN today, and would love to get your feedback. Have you had to build similar tools? What were some of the pain points or challenges? Thanks in advance!
Nick and Omar