Why We're Building Drip Drop

I've been a freelance software developer for seven years. In that time, I've built out drip campaigns for over ten major projects — the kind with conditional branches, multi-channel touchpoints, A/B testing, and all the logic that separates a real marketing engine from a batch-and-blast email.

When they're done right, drip campaigns are some of the highest-performing marketing work I've been a part of. They don't go viral. Nobody tweets about them. But they quietly generate leads, convert trials, and recover revenue in the background, every day. They just work.

So why has building them always sucked?

The Project That Broke the Pattern

A while back I was working with a client in real estate. The campaign concept was simple: target rental property owners whose listings had been sitting vacant. "Your property's been listed for 30 days with no tenants. Let us help." The longer the listing sat, the warmer the lead.

We built a multi-step drip sequence around it. Leads entered the funnel based on listing data, got an initial outreach email, a follow-up SMS a couple of days later, then a series of touches over the next few weeks that adjusted based on engagement. It was a fun one to build — real behavioral logic, lots of moving parts, clear ROI.

We used Twilio for SMS. Took weeks to wire up. Custom integrations, hard-coded logic. And it worked great.

Then the client switched to Telnyx.

Nothing was wrong with Twilio. Just a business call — better rates, different feature set. Totally reasonable. But every SMS integration point in the campaign was wired directly to Twilio's API, so switching providers meant rewriting the backend. Three days of dev work to swap one service for another. The campaign logic didn't change. The messages didn't change. The audience didn't change. We just had to touch everything because the provider was baked into the code.

Then Came the Iteration Cycle

After we launched, the client's marketing team wanted to iterate. They were seeing results and wanted to add steps, remove others, A/B test different messages for different segments of property owners. Normal stuff.

Problem was, everything lived in code. The sequence logic, the timing, the message content, the branching rules — all of it. The marketing team couldn't change any of it without a developer.

So here's what a "simple change" actually looked like: the marketing person figures out what they want. They brief the copywriter. The copywriter writes new message variants. The designer updates email templates. Then it comes to me and the client's in-house dev to actually implement the changes. The owner reviews before it goes live. Six people, weeks of back-and-forth, Slack messages at odd hours, revision cycles stacked on revision cycles.

And what were the actual changes? Adding a step. Removing a step. Testing two subject lines. A marketing person should be able to do that in an afternoon with the right tool. But we didn't have the right tool. We had custom code, and custom code means a developer ticket for every tweak.

The Pattern I Couldn't Ignore

That project wasn't special. It was just the one where the pattern became impossible to ignore.

Over seven years and 10+ drip campaign builds, I kept running into the same problems:

Vendor lock-in kills flexibility. You build on one provider's API, and switching means rebuilding. Three days of backend work to swap Twilio for Telnyx. Weeks of migration to move email platforms. The campaign logic is identical — only the delivery layer changes — but because everything's coupled, you're practically starting over.

Hard-coded campaigns can't keep up with marketing. Marketing teams need to move fast — test, iterate, adjust timing, swap messages, add branches. When all of that lives in code, every change needs a developer. And developers (especially freelance ones) aren't sitting around waiting for subject line change requests. Changes pile up, timelines slip, and the campaign that's supposed to be your always-on revenue engine is frozen waiting on a deploy.

Existing tools force bad tradeoffs. I've used a lot of platforms. The all-in-one tools (Mailchimp, ActiveCampaign, HubSpot) give marketing teams a visual editor, but they lock you into proprietary sending infrastructure with marked-up pricing and shared deliverability. The developer-friendly approach (raw API integrations with SendGrid, Twilio, etc.) gives you full control and wholesale rates, but requires code for everything — marketing teams can't self-serve. And if you want email and SMS in the same workflow, you're usually duct-taping services together with custom middleware.

No matter which path I picked for a client, somebody was making a sacrifice. Flexibility or simplicity. Control or cost. Developer power or marketing team autonomy.

So I Built the Thing I Needed

Drip Drop started as the tool I wished I'd had on every one of those projects.

The core idea: separate the orchestration layer from the delivery layer. You bring your own email provider — SendGrid, Amazon SES, Mailgun, Gmail. You bring your own SMS provider — Twilio, Telnyx, Vonage. Drip Drop handles everything in between: the visual workflow builder, conditional logic, timing, A/B testing, analytics.

Your providers plug in through their APIs. Want to switch from Twilio to Telnyx? Update your credentials. That's it. Campaigns don't change. Workflows don't break. Nobody's rewriting three days of backend code.

The campaign builder is drag-and-drop. A marketing person can add a step, remove a step, create an A/B split, adjust timing between messages, and publish — without touching code, filing a ticket, or waiting on a deploy. The kind of changes that took six people and weeks on that real estate project take one person and an afternoon.

That's the idea behind everything in Drip Drop. Changing a subject line should be trivial. Swapping an SMS provider should be trivial. Adding a step to a sequence should be trivial. But building a sophisticated multi-channel campaign with conditional branching, engagement-based routing, and A/B testing across email and SMS should be doable too — without writing custom code, and without paying an all-in-one platform's markup for the privilege.

Who This Is For

I'm building Drip Drop for the people I've spent seven years working alongside:

SMBs and marketing teams who want automated multi-channel outreach but don't want to be locked into a vendor's proprietary infrastructure. Developers who are tired of building and rebuilding campaign logic that should be configurable. Founders who've looked at the pricing on marketing automation platforms and thought, "I'm paying how much just to send emails through their servers?"

If you've ever burned three days on a provider migration that shouldn't have been necessary, or watched a marketing team wait two weeks for a developer to make a change they could've handled themselves — this is for you.

We're not trying to replace SendGrid or Twilio. They're great at what they do. We're building the layer on top that makes them easy to use together, visually, without code, and without giving up control of your stack.

What's Next

Drip Drop is in active development and we're building toward an early access launch later this year. If you want to be among the first to try it — and lock in founding-member pricing — you can join the waitlist below.

I'll be sharing build updates, technical decisions behind the product, and more content on drip campaigns and marketing automation as we go. If you want to follow along, the blog's the best place.

Thanks for reading. Let's build something better.

— Colin