Hi everyone!
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.