
Launch HN: Flowdash (YC W20) – Human-in-the-loop tooling for operations teams - nickgervasi
Hi everyone!<p>We’re Nick &amp; Omar from Flowdash (<a href="https:&#x2F;&#x2F;flowdash.com" rel="nofollow">https:&#x2F;&#x2F;flowdash.com</a>). We help companies quickly build internal tools to track and execute human-in-the-loop workflows.<p>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.<p>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.<p>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.<p>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.<p>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.<p>Here’s how it works:<p>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.<p>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: <a href="https:&#x2F;&#x2F;flowdash.com&#x2F;demo" rel="nofollow">https:&#x2F;&#x2F;flowdash.com&#x2F;demo</a>.<p>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!<p>Nick and Omar
======
erichocean
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.

------
tomashertus
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?

~~~
Chetane
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 :)

------
dpcheng2003
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.

------
tekacs
Congrats on the launch!

This reminds me of Orchestra by B12 in many ways:

[https://orchestra.b12.io/](https://orchestra.b12.io/)

Do you have any thoughts on how you compare to that solution (besides it being
OSS and yourselves a company)?

~~~
nickgervasi
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?

~~~
tekacs
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.

------
peterhunn
Hi Nick and Omar - excited be this. Synergy with what I am doing at Clause.
What to have a chat?

------
chrdlu
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.

------
Nilef
Looks brilliant!! Have signed up with
[https://aidem.network](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

~~~
nickgervasi
Thanks for signing up! We tried reaching out but the email bounced. Can you
message me directly at nick <at> flowdash <dot> com?

~~~
Nilef
That's worrying! Will do

------
blob42
How does this compare to Retool?

~~~
kornish
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.

~~~
parentheses
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.

------
nexuist
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!

~~~
nickgervasi
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.

~~~
nexuist
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.

~~~
nickgervasi
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.

------
vladsanchez
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.

~~~
quickthrower2
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!

------
theptip
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?

~~~
nickgervasi
> 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.

------
thhoward
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.

------
grandmczeb
Wow, this sounds like a really cool idea! Best of luck!

------
frequentnapper
interesting. couldn't this just be done with a popular kanban tool like jira +
Zapier?

~~~
nickgervasi
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.

------
seikij
Congrats, looks really great!!

