we wanted a crm that could read product reality, not just store notes, and help us act on it.
we built floo-crm because we wanted one place to see what was changing across the product and which accounts needed attention. that only really works if the crm can tap into the same data the product already has.
a generic crm can store contacts and notes. it cannot naturally tell us which orgs are deploying more, which teams are going quiet, or how many users an app has. once the tool can see those signals, it can also carry more of the next step.
what we needed
we wanted one place to see org activity, deploy velocity, usage, and the simple signals that tell us who needs attention next.
that sounds small, but it changes the workflow. instead of jumping between product dashboards and a separate crm, we can work from one view that already understands the product and the teams using it.
why we built it ourselves
once we wrote down the workflow, the buy-vs-build tradeoff changed. the off-the-shelf version would still need workarounds, and it still would not reflect the product well.
the custom version is inexpensive to run, easy to change, and closer to our own data model. because it is ours, we can keep extending it with the views, automations, and agent workflows that are actually useful. for a tool like this, building it turned out to be both more economical and more useful than buying another saas product.
why floo made it easy to build
floo made the custom route practical because we could focus on the workflow instead of platform glue.
we put floo-crm behind accounts auth, so we did not have to build authentication at all. no login flow, no password reset, no auth side quest. that kept the v0 small and let us spend time on the parts that matter.
what the app does
floo-crm is connected to read-only product data, so it can see orgs, recent deploys, usage, and how many users customer apps have.
every hour, a cron job pulls in fresh data and sends the next actions to Slack. that keeps the team close to what customers are actually doing, and it gives us a place to add more workflow and agent help over time.
why this pattern matters
the interesting thing about floo-crm is not that we built a crm. it is that this kind of small internal app is now a good use of time.
when the workflow is close to the product, custom software can be cheaper than buying something generic and much more effective in practice. it can read the right data, fit the business as it changes, and carry more of the work. floo is what makes that tradeoff feel good instead of painful.