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
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.
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?
> 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 :)
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.
Dead Comment
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)?
I'll point them your way, to see if they can share their experiences.
Retool can do pretty much everything this thing can do and more. I'm definitely keeping my Retool instance.