DEV Community: Keisha Singleton

How a 19-year-old with $250k in revenue almost dropped out (and why he didn't)

Keisha Singleton — Fri, 24 Apr 2026 04:00:41 +0000

Griffin Kubicki had already built two businesses before he ever set foot on a college campus.

By the time he enrolled at the University of New Hampshire, he'd generated more than $250,000 in client revenue through paid ads and conversion funnels — working as a media buyer, head of operations, and founder of his own agency, Kube Marketing. He wasn't arriving at UNH to figure out what he wanted to do with his life. He already knew.

So why bother with a marketing degree?

He wanted the credential, sure. But more than that, he wanted to meet other young founders — people who understood the particular hunger of building something before most of their peers had held a real job.

He figured college was where he'd find his people.

The loneliness problem no one talks about

UNH has a lot to offer. For most students, its tight-knit Greek community is exactly what they're looking for. But Griffin was wired differently.

"I want people who want to wake up early in the morning and go get s*** done."

Opportunities kept coming in — founder events, clients, deals. He'd return to his dorm excited to share the news, and find his roommate gone. Everyone was out socialising. It wasn't the kind of connection he was after.

He became a regular at UNH's award-winning ECenter, treating it like a second home. His businesses were growing. His social circle wasn't.

"I was just so lost. You almost feel like you're missing out if you don't find your people."

The trip that almost ended his degree

Then came Miami.

Griffin was flown out to meet other young founders — exactly the kind of trip that should have felt like validation. Instead, he spent the weekend being told to quit college. That it was a waste of time.

He came home half-convinced they had a point.

"I was pretty set after that, like, okay, I'm going to drop out. Dude, I'm going to go buy a Porsche."

But a few days later, an admin at the ECenter who'd watched Griffin practically live there saw a LinkedIn post from Whop's John Hill: "Tag a university student entrepreneurship leader. I'll choose one to visit our offices in NYC."

She tagged Griffin. He applied and tried not to think too much about it.

Two days later, an email landed in his inbox: "Are you game?"

What changed his mind

He walked into Whop HQ and found college students who were enrolled, building, and setting goals. Not telling him to quit anything.

"Holy crap. There are college students doing business who have goals like mine, and it's a real thing."

It reframed everything. He wasn't the odd one out, he'd just been in the wrong room.

"It gave me clarity of like, okay, I have goals, I'm going to go get those goals."

Griffin flew home with direction he hadn't had before. He was staying in school, keeping his businesses running, and for the first time since arriving at UNH, he wasn't searching for his community. He knew where to find it.

Building it for others

In the weeks after his visit, Griffin was contracted to create Whop communities for both Harvard and Yale. Then he turned closer to home, becoming the administrator of the UNH whop and helping fellow students build their own.

One of the first people he brought in was Colby Chase, a digital marketer who films car content and teaches creators how to go viral. He then hired a freshman to work alongside him — someone he still works with today.

The community he'd spent his first year searching for, he was now creating for others.

"If people want to go start their businesses, they can go on the whop at the University of New Hampshire and I'm the admin of it. There's an ecosystem built, slowly but surely, it's getting populated."

The bigger picture

Griffin's story isn't an isolated one. According to a 2025 Quizlet survey of 2,000 US college students, more than half of Gen Z students maintain a job or business alongside their studies.

The ambition has never been the problem. What's been missing is infrastructure that doesn't require a co-founder with connections or a family friend with capital — and a community that gets it.

Whop's Higher Ed program has now reached more than 100 universities, with almost 4,000 student businesses launched. The goal for 2026: 1,000 universities and 100,000 students.

At Michigan State, Professor Ken Szymusiak rebuilt his entrepreneurship curriculum around a five-week sprint — and more than 350 students have since built real businesses through it:

"What has become very clear is that my students now have the ability to build at superhuman speed. What used to take weeks now takes hours. Entrepreneurship education has to be about experimenting, not case studies of the past."

Business as community

When Facebook launched from a Harvard dorm room in 2004, it connected people who already knew each other. Whop is doing something different: connecting people through what they create.

Students in New Hampshire are building alongside students in South Carolina, Michigan, and California. A freshman at UNH is learning from a sophomore at Yale.

For builders like Griffin, the business isn't separate from the community. It is the community.

Why your payment integration is leaking revenue (and how the architecture is to blame)

Keisha Singleton — Fri, 20 Mar 2026 07:53:36 +0000

Most payment integrations start the same way. You pick a PSP, follow the docs, get to a working checkout, and ship. It's the default for a reason — the integration is well-documented, the SDK handles the complexity, and payments work.

Now, single-PSP architecture isn't wrong, but it's coupled in ways that only become visible when something breaks, and by then, the cost is already running.

What single-PSP dependency actually looks like in a codebase

When you integrate directly with a single processor, payment logic tends to get distributed across your application. Checkout flows, retry handling, webhook processing, subscription billing: each of these ends up with processor-specific logic baked in.

There's no abstraction layer. Your application talks directly to the PSP. Which means:

Routing decisions live in application code, not in a dedicated layer
Adding a second processor isn't a config change, it's a new integration
Your card vault is owned by the PSP, not by you, and migrating it later is painful
A processor outage has no programmatic fallback

None of this feels like a problem when you're building it, but it becomes a problem when you're scaling.

The failure modes you don't anticipate

Processor outages with no fallback

A single-PSP architecture has one response to processor downtime:sit and wait. There's no routing layer to detect degradation and shift volume. For a merchant processing at meaningful volume, even a short outage represents significant lost revenue, and there's nothing in the stack to catch it.

Suboptimal cross-border routing

Without a routing layer, every transaction goes to the same processor regardless of where the customer is. International transactions routed through a non-local acquirer carry structurally higher failure rates and cross-border fees. The authorization rate difference between domestic and cross-border routing is measurable: but only recoverable if your architecture supports routing decisions.

Silent card-on-file failures

For subscription businesses, card-on-file transactions fail when credentials become stale: expiration, reissuance, account changes. Without network tokenization (tokens issued by the card networks that auto-update), these failures are silent. The charge just fails. By the time it surfaces as churn, the customer is already gone. Up to 12% of card-on-file transactions fail for exactly this reason.

The fraud filter problem

Every PSP has its own fraud rules. A transaction flagged by one processor might sail through another. When your stack has no routing layer, there's no mechanism to recover from a false decline — the transaction fails, the customer leaves, and you have actually paid an acquisition cost to then lose them.

The cost that doesn't show up in your monitoring

Authorization fees are charged on failed transactions as well as successful ones. Every declined transaction carries a direct processing cost on top of the lost sale. At scale, you're paying to lose customers.

The engineering cost compounds this. Adding a second PSP without an abstraction layer means rebuilding routing logic, webhook handling, reconciliation, and vault management for a new provider. That's months of engineering time: and it has to repeat for every new market or payment method.

PCI DSS scope also tends to expand with every direct integration. Without a centralized vault abstracting card data, each new processor potentially increases your compliance surface.

What an abstraction layer actually buys you

Payment orchestration introduces a layer between your application and your processors. Your integration point is the orchestration layer, not the PSPs directly.

What this changes architecturally:

Routing logic lives outside application code. Rules can be updated without deploys. New processors can be added without new integrations.
Vault portability. Credentials are stored once and usable across all connected processors. Retries through a secondary processor don't require re-authentication.
Programmatic fallback. When a primary processor degrades or goes down, the orchestration layer detects it and reroutes — before the customer sees a failure.
A single observability surface. Authorization rates, decline reason codes, and cost-per-transaction across all processors in one place, segmented by BIN range, region, and card type.

The architectural shift is from tight coupling to an abstraction layer with defined interfaces. It's the same principle you'd apply anywhere else in a distributed system.

When to think about this

The earlier the better, but the inflection points that tend to force the conversation are:

Expanding into international markets where local acquiring matters
Adding subscription billing where card-on-file failure rates compound
Reaching a transaction volume where authorization rate improvements have measurable revenue impact
A processor outage that surfaces the single point of failure

By the time most engineering teams are asked to retrofit orchestration, the vault migration alone is a significant project. Building toward an abstraction layer earlier is the lower-cost path.

For the full business case — including the cost of false declines, the vendor comparison, and what to look for when evaluating platforms — the complete guide is here: Why Payment Orchestration Is the Infrastructure Fix Most Merchants Are Overdue For

I looked into every Stripe Connect alternative worth knowing about: here's what I found

Keisha Singleton — Thu, 19 Mar 2026 01:57:44 +0000

I've been deep in research on this one. If you're building a platform or marketplace and Stripe Connect is starting to show its cracks, this is for you.

Why people leave Stripe Connect

Stripe Connect is a genuinely good default. The docs are thorough, the developer experience is polished, and most platforms can get up and running without a dedicated payments team.

The problems tend to come later, with processing fees, Connect account fees, instant payout fees, FX conversion fees, and dispute fees all layering on top of each other. And, geographic gaps in the payout network show up exactly where you're trying to expand.

On top of that, single-provider dependency creates concentration risk that's easy to underestimate until something goes wrong (like it did with Flipcause: when the nonprofit platform filed for Chapter 11 in December 2025, Stripe had frozen ~$2.2M in funds, becoming a central obstacle in creditors' recovery. Legally defensible, but a vivid illustration of what single-PSP dependency can look like at a critical moment).

The alternatives, by category

I broke these into three tiers: full replacements, payout specialists, and merchant of record platforms.

Full Stripe Connect replacements

Whop Payments Network — full-stack infrastructure with multi-provider orchestration, automatic retry on decline, 100+ payment methods, 135+ currencies, 195 countries, and a connected accounts model for platforms. Payout options include next-day ACH, Instant RTP, crypto, Venmo, and international bank transfers. Transparent pricing, 24/7 support, 99.999% uptime. The one I'd look at first if vendor dependency is the core concern.

Adyen for Platforms — best-in-class acquiring infrastructure used by eBay, Wix, and Lightspeed. Interchange++ pricing is cost-efficient at volume, but it's enterprise-only and not self-serve. Assumes a dedicated payments engineering team.

Checkout.com Integrated Platforms — standout feature is split payment configuration at any stage of the transaction lifecycle (authorization, capture, or refund). Strong in Europe, MENA, and APAC. Enterprise-only, sales-led.

Mollie Connect — best option for European platforms. 35+ local payment methods including iDEAL, Bancontact, and Klarna. Pay-per-transaction pricing. Note: the pending GoCardless acquisition (expected mid-2026) adds bank debit to the stack but introduces near-term roadmap uncertainty.

Rainforest — purpose-built for vertical SaaS replacing Stripe Connect. Vertical-specific underwriting improves approval rates in healthcare, logistics, and professional services. Buy-rate interchange++ pricing, no monthly fees, no revenue split. US-focused for now.

Payout specialists

These sit downstream of your PSP and handle disbursements only — useful if your core issue is the payout side, not pay-ins.

Payoneer — strong emerging market coverage (190+ countries, 70 currencies), recognizable brand among freelancers and international sellers. The 2025 fee changes matter: transfers under $400 now carry a flat $4 fee, and FX markups run 0.5–3.5%.

PayPal / Hyperwallet — 400M+ active PayPal accounts means near-instant payouts for payees already in the network. 200+ markets. No published rate card — all pricing is negotiated.

Trolley — purpose-built for mass disbursements. 210+ countries, 135+ currencies, DAC7 compliance automation, white-label payee onboarding. API-first. Disbursement only.

Routable — sits between payout specialist and AP automation tool. Four ACH speed tiers, 220+ countries, strong ERP integrations. Good fit if you're managing both AP and seller payouts.

Tipalti — enterprise standard for global payables. 196 countries, 120 currencies, KPMG-approved tax engine, SOC-compliant audit trails. Finance-team-led, not developer-first. Implementation takes weeks to months.

GoCardless — not a payout tool. It collects recurring payments from buyers via bank debit across 30+ countries at lower cost than card. Worth considering if your specific pain point is the cost of recurring payment collection, particularly in Europe or Australia. Being acquired by Mollie (mid-2026).

Merchant of Record alternatives

MoR platforms become the legal seller of your products, absorbing tax, compliance, fraud, and chargeback liability. Built primarily for SaaS and digital product businesses — not for routing funds between sellers. If you're running a marketplace with third-party sellers, this tier isn't for you.

Paddle — category leader, 13 years as MoR, 6,000+ customers. Handles tax across 100+ jurisdictions, subscription management, fraud, chargebacks. Stripe Managed Payments is now a direct competitor, though Paddle's compliance infrastructure is considerably more mature.

Lemon Squeezy — acquired by Stripe in July 2024. The team is building Stripe Managed Payments. Still works, still simple, but the long-term direction is Stripe-native.

How to choose

Most switching decisions come down to one of three things: cost at volume, geographic gaps, or compliance overhead. Identify which one is actually your problem before evaluating alternatives — it cuts the shortlist fast.

The most important decision in the evaluation is your compliance model. MoR platforms absorb liability in exchange for a higher fee. PSPs and payout specialists hand that responsibility back to you. There's no right answer — only the right fit for your team's capacity.

And don't underestimate connected account migration. Moving active sub-merchants with saved payment methods or live subscriptions is the hardest part of any infrastructure switch. Get explicit written confirmation from any vendor on how they handle it before entering a sales process.

Read the full Stripe Connect alternatives comparison here.