Why I built directflow
Petr Guskov
I work as a software developer at Global Disposal. I've been there for 8 years. Over the last 4 of those years, I kept running into versions of the same problem: send the right message to the right person based on data we already have in our database.
It was never simple.
The problem with existing tools
Global Disposal has communities and subcommunities. Users belong to addresses. Addresses belong to communities. We wanted to send different content depending on which community or subcommunity a user's address is in. We wanted to include dynamic data like current offers or custom announcements specific to that community.
Klaviyo can't do this. You can segment users by flat properties but you can't run relational queries against your data. You can't say "find all users whose address is in community X and show them the current offers for that community." To make it work you'd need to flatten all that relational data into custom properties on the user record and rebuild it every time your data model changes.
Every tool that offers truly dynamic segmentation requires ETL. You have to extract your data, transform it, and load it into their system before you can use it. That felt wrong. Why can't this be simpler?
So we tried building our own notification system. We wrote a scheduler, built custom sending logic around SendGrid, wrote code to pull the right data and format the right messages. It worked but it was expensive to maintain. Every new campaign type meant more custom code. Every change to our data model meant updating the notification system too.
Every solution adds tools instead of removing them
When I looked at what mature tools in this space actually look like, I noticed a pattern. Each one solves a real problem and creates a new dependency.
- Klaviyo is one tool, but it locks you into its data model. You can't run relational queries against your real database.
- Hightouch pipes data from your warehouse into other tools. It does not send messages. To send anything you still need an ESP like Klaviyo or Braze. Stack: warehouse plus Fivetran plus Hightouch plus Braze. Four tools.
- MessageGears is a warehouse-native sender used by enterprises like Expedia, T-Mobile, and Chewy. They proved that companies will pay for "read in place, don't sync." But you still need a Snowflake or BigQuery warehouse to use them. Three tools, enterprise tier.
Each is a valid choice. Each adds layers. Each layer is another vendor, another contract, another integration, another thing that can break.
The hidden cost of data pipelines
The license fee is not the real cost. The real cost is engineering time and operational overhead.
A 2024 dbt Labs survey of data practitioners found that over 80% of their time goes to maintenance work. 55% goes to maintaining datasets, 26% to maintaining infrastructure. Only a small slice goes to building anything new.
A Fivetran and Wakefield Research study estimated companies lose around $520,000 per year on engineering time spent maintaining pipelines. 80% of data leaders said they have to rebuild pipelines after deployment because APIs change.
A Forrester study commissioned by Segment found CDP implementation alone runs around $1 million before you send a single message.
I'm not saying these tools are bad. They solve real problems for companies that need them. But for our use case at Global Disposal, and I suspect for many mid-market companies, the data was already there in our database. Adding three more layers to access it felt like the wrong direction.
What I believe about software
I believe most software is more complex than it needs to be.
Complexity is a choice. Sometimes it is a necessary choice. Often it is not. A simple system that does the job is more valuable than a clever system you have to maintain. Every tool you add is a tool to maintain. A vendor relationship, an integration, a failure mode, a contract.
This belief is why directflow looks the way it does.
The idea
What if a service could connect to your production database with read-only access and just use the data that's already there? No syncs. No copies. No stale segments.
The service handles templates, delivery queues, email and SMS providers. A developer writes SQL queries to define audiences and the results are ready to use in campaigns and flows. Flows can branch based on real-time conditions. Every variable your database has is available in every notification.
directflow doesn't eliminate the need for a developer. Someone technical still writes the queries. But it makes their job much easier. No more maintaining custom notification code. No more syncing data to third party systems. No more rebuilding segments when the data model changes.
That's what directflow is.
The traditional approach
The directflow approach
Where directflow fits
Hightouch and Census built tools to pipe data from your warehouse into other tools. Hightouch reached $87M in revenue and a $1.2B valuation in 2025. Together with Census, the reverse ETL category has raised over $250M. The size of those numbers tells you how painful data sync is.
MessageGears took a different angle: send messages directly from your warehouse. They proved that enterprises will pay for warehouse-native sending.
directflow takes the same idea, read your data in place, do not copy it, and removes the warehouse requirement. If you have a database running your application, that is enough. One tool instead of three or four.
What it looks like
Here's what directflow looks like in production at Global Disposal.
Campaign dashboard with real business metrics. Revenue, conversions, delivery rates. All from one email campaign running against live data.
The flow builder. You define a trigger, add actions like sending emails or SMS, set conditions and waits. The flow runs automatically for each enrolled user.
Every notification is stored with the full context. You can see exactly what was sent, when it was delivered, and when the user opened it.
Including the actual email the user received in their inbox.
Where we are now
directflow is actively used at Global Disposal. We replaced the custom notification code we maintained in our codebase. All data stays in the company database. Email and SMS campaigns are driving real revenue and conversions. It's used daily by our team to run campaigns.
I built directflow on my own time. I want to thank Josh Allen, CEO of Global Disposal, for trusting both the product and me personally. That trust made a real difference.
What directflow does
- Connects to your database directly
- Define audiences with SQL queries
- Create campaigns across email, SMS, push, and webhooks
- Automate flows with conditional branching based on live data
No data sync. No ETL pipelines. Your data stays where it is.
Today directflow connects to Postgres. We are actively working on adding support for MySQL, BigQuery, Snowflake, and their cloud variants. The engine stays the same. Only the data source changes.