Why Stripe is the wrong default for a 6-student studio (and what works instead)

The first thing every billing tool aimed at independent music teachers asks you to do is connect Stripe. Segnoly is no exception in the abstract — lib/stripe-connect.ts exists and is the path most teachers will eventually take. But I want to make a case I haven't seen any of our competitors make, and which the engineering choices in our codebase reflect: for a teacher with fewer than about ten students, Stripe is usually the wrong default. Not in the long run. On day one.

The reason is operational, not financial. The financial part is easy to get to, so let's start there.

The dollar math on a 6-student studio

Take a teacher with six students, each doing a 60-minute weekly lesson at $60. Four lessons a month per student. The monthly card volume is:

• 6 students × 4 lessons × $60 = $1,440 per month

Stripe's standard fee in the US is 2.9% + 30¢ per successful transaction. If each lesson is invoiced individually (the default for most teachers when they first set up Stripe — they invoice as they go, not in monthly batches), that's 24 transactions a month:

• Stripe's percentage: 2.9% × $1,440 = $41.76
• Stripe's per-transaction: 24 × $0.30 = $7.20
• Stripe's monthly take: $48.96

On Segnoly's PAYG plan, the platform fee on top is 2% (lib/entitlements.ts:applicationFeeBps() returns the configured 200 bps for PAYG):

• 2% × $1,440 = $28.80

Total monthly fees: $77.76, or about 5.4% of the studio's gross.

That's the number to keep in mind. A 6-student studio running everything through Stripe Connect plus a billing tool with a small platform fee is paying somewhere between five and six cents of every dollar to the rails before they pay themselves.

For comparison, the rails that don't charge per transaction:

• Zelle: No fees in the US for personal accounts. (Business accounts are a different story, but a sole-proprietor teacher with a personal bank account isn't there.) No auto-charge, but no fee.
• Check: No fee. Manual deposit. Manual reconciliation.
• Cash: No fee. No paper trail unless you generate one.
• ACH via something like Plaid: Roughly 0.8% capped, often around $0.50–$1.00 per transaction. Cheaper than card on every dimension except onboarding UX.

For the same 6-student studio, switching to Zelle/check brings the fee total from $77.76/mo to $0/mo — a $933 a year saving — at the cost of: no auto-charge, no chargeback protection, no parent-portal "click to pay" UX.

That tradeoff is worse than it sounds for a 30-student studio and better than it sounds for a 6-student one. Here's why.

What a working teacher actually wrote about this

In late 2023, a piano teacher named Chad Twedt updated a long-running post on his blog Cerebroom to reflect a change in his collections:

"2023 update: the vast majority of my students now pay me either via Zelle or cash. I do not take Venmo or Paypal as I do not want to entrust my most sensitive financial information to any more parties than I have to, with reports of constant data breaches."

— Chad Twedt, Cerebroom, "Flat Tuition Payments For Private Music Lessons"

Two things in that paragraph that are easy to skim past. First, the vast majority. Twedt isn't a hold-out who refuses to integrate with the modern world. He's running a studio in 2023, his families have iPhones and bank apps, and the modal payment is Zelle. Not Stripe, not card-on-file, not Venmo.

Second, I do not want to entrust my most sensitive financial information to any more parties than I have to. That's a position most fintech blogs treat as eccentric. It is not eccentric for a teacher running a 20-student studio out of a home, who is one chargeback dispute away from a frozen merchant account and a locked-out Stripe Connect login on a Tuesday at 4pm with an invoice they were planning to send tonight. The fee is the visible part. The risk is the part teachers spend longer thinking about than fintech blogs assume they do.

The friction of saying yes to Stripe

The other side of this is what it actually costs the teacher to onboard Stripe Connect in the first place. Not in dollars — Stripe's own onboarding is free — but in time, attention, and rejection rate.

Here's the function in our codebase that initiates that flow:

// lib/stripe-connect.ts:createOnboardingLink
export async function createOnboardingLink(): Promise<{ url: string } | { error: string }> {
  if (!stripe) return { error: "Stripe is not configured." };
  const result = await ensureConnectedAccount();
  if ("error" in result) return result;
  const link = await stripe.accountLinks.create({
    account: result.accountId,
    refresh_url: `${env.APP_URL}/settings?tab=integrations&stripe=refresh`,
    return_url: `${env.APP_URL}/settings?tab=integrations&stripe=return`,
    type: "account_onboarding",
  });
  return { url: link.url };
}

What that does in practice: the teacher clicks a button, gets bounced to Stripe, fills out an Express account onboarding form (legal name, SSN last four, business address, bank account, in some cases an EIN, in some cases ID verification, in some cases a 24–72 hour review hold). Then they bounce back to our settings page, at which point our refreshConnectStatus() polls Stripe for the actual account state.

That state lives as stripeAccountStatus, which is one of none | onboarding | restricted | active (db/schema.ts:45). The relevant detail is that none is a real, intentional, supported state. A studio with stripeAccountStatus: "none" can use Segnoly fully — manual invoicing, manual payment logging, late-fee automation, the parent portal, recurring lessons, the reminder cadence, all of it. The only thing they can't do is take a card payment through us.

The drip-onboarding stages in lib/drips-stages.ts only nudge a teacher to connect Stripe after they've crossed a usage threshold — not on day one, not in the welcome email. The reason is the audience. A meaningful slice of independent music teachers don't currently take card at all, and many of them don't intend to. For that audience, "first onboard Stripe" is the wrong day-one ask.

The Canadian-merchant gap

There is a second case where Stripe-as-default is wrong, and it's structural. A 2018 Capterra review of Fons by a music teacher named Daniel N. names it directly:

"as a user in Canada, I hope that one day there will be alternative payment options for my clients other than credit card."

— Daniel N., Capterra review of Fons, July 27, 2018

That's a teacher saying out loud what every Canadian, UK, EU, or Australian teacher running through a North-American-defaulted billing tool already knows: the percentage-fee model is calibrated to a US payments market where families pay almost everything by card. In Canada a substantial slice of the parent-side population pays by Interac e-Transfer (the local equivalent of Zelle) or by cheque. In the UK, Bacs and Faster Payments. In the EU, SEPA Direct Debit.

Stripe supports many of these rails. Setting up Stripe Connect to prefer a non-card rail — where the parent-side experience is "click here, pay by Interac" rather than "click here, enter card" — is a non-trivial product setup that most billing tools simply don't ship. The Fons review is from 2018; the same complaint resurfaces in more recent reviews on the same product page. The structural shape of the problem hasn't changed in seven years. For a tiny Canadian or UK or EU studio, the right rail is local, low-fee, and not Stripe.

When Stripe does become the right call

I'm not arguing against Stripe Connect as a long-run play. I'm arguing against it as a day-one default. The break-even isn't a card-volume threshold. It's a collections-friction threshold — the moment when the time and money lost to chasing manual payments exceeds the $77/mo (or whatever the studio's specific number is) of card-rail fees that auto-charge would cost.

In practice, this lands between 8 and 12 students, depending on the families. For a teacher whose families pay reliably, the threshold is higher — they can run 20+ students on Zelle without much pain. For a teacher whose families need three reminders to pay an invoice, the threshold is lower — even 6 students might cost more than $77/mo in chase-and-collect time.

The signal to watch is: how many lessons per month is the teacher not getting paid for, in the sense of late-cancelled, no-showed, or "I'll catch up next month, sorry"? Once that hits one lesson a month — at $60, that's $60/mo of foregone revenue plus the time cost of recovering it — Stripe's auto-charge plus a charge-on-late-cancel policy becomes net positive. Below that, it's net negative.

What "stay on none" actually looks like in Segnoly

A 6-student teacher who follows the advice in this post does the following on Segnoly:

1. Signs up. The 14-day Studio trial starts; stripeAccountStatus is none.
2. Adds their six students, sets a billing rate per student.
3. Sets their cancellation and late-payment policy in settings.
4. Sends invoices through the system. Parents see "pay by Zelle to chad@example.com" or "pay by cheque" in the invoice body, customised in the studio's email-template settings.
5. Logs payments manually as they arrive — Segnoly tracks the invoice as paid once the manual entry is recorded.
6. The reminder cadence at D7, D14, D30 (lib/scheduler.ts:runOverdueJob) fires for any unpaid invoice, regardless of whether the rail is Stripe or manual.
7. At the end of the trial, the studio falls back to PAYG (lib/entitlements.ts:resolvePlan() does this automatically). PAYG's 2% platform fee only applies to card payments through Stripe — and there are none, because Stripe isn't connected. Effective platform fee: $0.

That's the configuration that costs the example 6-student studio nothing in software fees and zero per-transaction fees, because both Segnoly's platform fee and Stripe's per-transaction fee are conditional on a card payment that isn't happening.

The reason the manual-payment soft-nudge logic exists at all (lib/entitlements.ts:manualPaymentSoftLimit() — fires when manual payments exceed 20% of monthly volume on PAYG) is to catch the moment when the studio has outgrown this configuration: enough manual volume that they're probably losing time chasing it, in which case the right move is to onboard Stripe and switch the rail. Not before.

The thing I want every tiny-studio teacher to take away

The most expensive mistake a teacher running a 5–10-student studio makes isn't picking the wrong billing tool. It's picking the right billing tool and then turning on every payment rail it offers because the onboarding flow nudged them to.

The right tool, used right, charges a 6-student studio nothing. The same tool, used wrong — Stripe Connect onboarded on day one, every lesson charged through cards because the parent-portal "pay now" button was the path of least resistance — charges that same studio about $933 a year. That's not a feature flag. That's a default behaviour question.

The Cerebroom post is evidence that experienced teachers, given a choice, often make the right call here without help. The Daniel N. Capterra review is evidence that the wrong defaults persist for years in this category because the vendors don't acknowledge them. I'm trying to ship a tool where the right default is also the easy one.

If you're in the first 18 months of a studio: stay on none. Tell parents to pay by Zelle, Interac, cheque, or whatever local rail their bank supports. Log the payments as they come in. Use the rest of the software — the scheduling, the reminders, the cancellation policy, the parent portal — as the time-savers they actually are. When the friction of manual collection starts costing more than auto-charge would, then onboard Stripe.

That's not a glitch in the pricing page. It's the recommendation.

---

Building Segnoly — billing and automation for independent music teachers. The Cerebroom and Fons quotes are real, the engineering choices in this post are how the software actually works, and the waitlist is open for the first cohort.