Groundbase
← Back to the Pipeline
Notes·

Why I killed Groundbase's credits system and went BYO Twilio

The "platform credits" model looks great on a pricing page. Behind the scenes it's a maze of compliance overhead, customer confusion, and accounting friction. Here's why I scrapped it.

For a stretch of Groundbase's early life, it had a credits system. Customers added dollars to a wallet. Sending an SMS deducted from the wallet. Making a voice call deducted from the wallet. I marked up Twilio's underlying per-message and per-minute rates — that markup was supposed to be part of the platform's revenue.

I killed it. The whole system. Replaced it with BYO Twilio — customers connect their own Twilio account directly, and their per-message cost is whatever Twilio charges them, full stop. No credits, no markup, no wallet.

This is the story of why, and why I'm glad I did it.

What the credits system looked like

The architecture: I had a master Twilio account. Each Groundbase customer got a subaccount provisioned under my master. Their SMS sends and voice calls flowed through the subaccount but billed to my master account at Twilio's rates. The customer paid me, in advance, via the credits wallet — and Groundbase debited their wallet at a marked-up rate when they sent.

Numbers, roughly:

  • Twilio charged me about $0.0075 per SMS
  • Customer paid the wallet a markup on top of that — somewhere in the range mainstream "communications platforms" use
  • Voice calls similar — Twilio rate underneath, customer paid a higher rate to the credits wallet

On a pricing page this looks great. "Use the platform; we handle billing." Customers don't need a Twilio account. Onboarding is one click. And the markup is real revenue per active customer.

So why kill it?

Complication 1: A2P 10DLC nightmare for multi-tenant SaaS

When you operate a platform where many businesses send messages through your master Twilio account, U.S. carriers expect specific A2P 10DLC registration. The right brand type is ISV-Reseller — a category that comes with its own paperwork, its own campaign approval flow, and its own structural responsibility.

The fundamental problem: every customer sending through the platform is a different business with a different message use case. Carriers want to know who's actually sending. As an ISV-Reseller, I was on the hook for vetting my customers' use cases and forwarding their info into the A2P registry. Multi-tenant A2P registration with rotating customers is a workflow most solo founders don't want to maintain.

Then we hit specific campaign rejections — the descriptions, the opt-in consent matching, the verification documentation. Each rejection meant a re-review cycle. Each new customer use case potentially needed its own campaign registration.

The work-to-revenue ratio on this overhead is brutal at indie SaaS scale. You spend hours on compliance for an extra few cents per customer in markup margin. The math doesn't work.

(I wrote up the A2P 10DLC mechanics here — the structural overview of what A2P is and what trips most people up. That post is partly drawn from this experience.)

Complication 2: customer confusion about "credits"

"Why did I just get charged $5? I added $10 last week and have only sent 20 messages." Every credits system generates this question. Customers don't have an intuitive sense of what a credit represents because the markup obscures the underlying cost. The wallet model invites the question "where did my money go?" in a way that flat-rate or pay-Twilio-directly doesn't.

Each customer-support email to explain "20 messages × $0.X markup × roundup = $5" was 10 minutes of solo-dev time that didn't make the product better. Multiply by every confused customer, every billing cycle.

Complication 3: refunds, disputes, and accounting overhead

What happens when a campaign sent badly and a customer wants a refund of the credits they spent? In the credits system, that meant manually crediting their wallet from Groundbase's books. What happens when a customer churns with $8.32 left in their wallet? Refund? Forfeit? Both have downsides.

What happens when Twilio runs a price change on the underlying SMS rate? My markup margins shift. Do I update the credits-per-message ratio? Do I absorb? Notify customers?

What happens when a Stripe dispute on a credits top-up happens AFTER the customer has spent some of the credits? Now I'm out the credits AND the chargeback fee.

None of these are catastrophic individually. Collectively they're a constant low-grade tax on my attention.

Complication 4: the "platform markup" smell

This is the part that bothered me most. The whole indie SaaS pitch — the reason I built Groundbase — was that I was tired of CRMs that nickel-and-dimed users on every adjacent service. HubSpot marking up SMS. Salesforce wrapping every external service in their pricing. The exact behavior I was building Groundbase to escape.

And there I was, marking up Twilio rates inside Groundbase. Different platform, same dynamic.

I told myself the markup was "reasonable" and "covered the operational overhead." But every time I had to explain to a customer why a Groundbase SMS cost $0.04 when Twilio's published rate was $0.0075, the lie got harder to sustain. The honest answer was: "I marked it up because that's how platforms make money on this." Which is what HubSpot does. Which is what I built Groundbase to be different from.

What BYO Twilio looks like instead

The current model:

  • You sign up for Twilio yourself (your own account, your own billing).
  • You connect your Twilio account credentials to Groundbase in Settings.
  • Groundbase sends SMS / makes calls via the Twilio API using YOUR credentials.
  • Your messages are billed by Twilio to YOU at Twilio's published rates. Groundbase doesn't touch the money.
  • Groundbase charges you $9/month flat for the application, period.

What I gave up: the per-customer markup revenue. For early-stage Groundbase that markup was small money anyway (you don't get rich on $0.03 markups when you have low customer count). For larger scale it might have been real revenue — but only if A2P and customer-confusion overhead could be amortized, which they couldn't as a solo dev.

What I got: the platform stops carrying compliance responsibility for each customer's sending. They're a Twilio customer now, on their own A2P registration, billed by Twilio for their own usage. Groundbase is a tool that consumes their Twilio API; the relationship between them and Twilio is direct.

The honest trade-offs

I don't want to pretend BYO is purely better. The trade-offs:

Worse for customers: more setup friction. They have to create a Twilio account, find their account SID and auth token, paste them into Groundbase Settings. For non-technical customers this is a real hurdle and likely costs me signups.

Better for customers: their per-message cost is genuinely lower (no markup). Their compliance is in their own hands rather than mediated by me. Their data lives in their own Twilio account where they can audit and export it.

Worse for me: lose the markup revenue. Lose the "all-in-one billing" sales pitch ("just one bill from Groundbase!"). Higher signup friction = fewer signups.

Better for me: no A2P compliance overhead per customer. No credits-support emails. No refund accounting. No "platform markup" pitch I have to make with a straight face. And, importantly: Groundbase becomes the kind of product I'd want to buy as a customer.

That last one is decisive. The reason I built Groundbase is because I wanted a CRM I'd actually use. Marking up Twilio rates inside it would mean I built a CRM I wouldn't buy. The pivot to BYO Twilio means I built one I do.

The bigger lesson

Every "convenience" feature you bundle into a platform has a hidden cost. Sometimes the cost is engineering complexity. Sometimes it's compliance overhead. Sometimes it's customer confusion. Sometimes it's brand-positioning awkwardness. Sometimes all four.

The default in SaaS is to bundle more — it's "more convenient for the customer," it's "more revenue per customer," it's "more reasons to pick us over the competition." All true. But each bundled feature has a tax, and at solo-dev scale those taxes add up faster than the revenue they generate.

BYO is a deliberate counter-default. It says: "you bring your own infrastructure for the adjacent services; I provide the application." Smaller revenue ceiling, smaller surface area, simpler relationships all around. For a one-person company at $9/month, the trade-off goes the right direction.

Will I miss the credits markup revenue? Probably, when Groundbase hits scale and a few cents per customer would actually move the needle. But by then I'll have a sustainable solo product instead of a bigger one I can't support. That's the trade I made and I'd make it again.

For more on this anti-platform-markup philosophy, see why I won't build social media management into Groundbase — same logic, different surface. And if you're curious how the BYO model affects your A2P situation: I wrote up A2P 10DLC for solo operators here.

Built by a solo dev. Try it.

Start your 14-day trial →

More from the Pipeline

Notes

Why I'm not marketing Groundbase on LinkedIn

Most indie marketing advice eventually arrives at "you should be on LinkedIn." Here's why I deliberately wo…

Notes

Why Groundbase won't build social media management

People ask if Groundbase will become Hootsuite-plus-a-CRM. Short answer is no. Long answer is more interest…

Features

Connect Claude (or any AI) to your CRM via MCP

Most CRMs bolt on a chat sidebar and call it "AI." Groundbase exposes itself as a Model Context Protocol se…

Guides

Twilio A2P 10DLC for solo operators (and how to figure out if you even need it)

A2P 10DLC is genuinely confusing. Here's the structural overview, the rejection traps I hit firsthand, and …