Case Studies

Link-in-bio products have been dominated by competitors that treat commerce as an afterthought — a checkout button that hands users off to an external platform, or a shop page that is a link list in disguise. The result is a fragmented experience: creators collect email and social links in one place, then push their audience to Gumroad, Shopify, or a standalone store to actually buy something.

The opportunity I saw was to build a link-in-bio platform where commerce was first-class. Not a checkout button bolted on, but a full commerce stack — cart, guest checkout, orders, digital delivery, coupons, subscription management — embedded inside the same editor that creators already use to build their page.

The harder part was doing this as a multi-tenant SaaS. Every creator needs their own isolated data, their own subdomain, their own plan enforcement, their own subscription state. And it all has to be fast, secure, and operable by one person.

The architecture I settled on is a three-domain system: brand.com for the authoring editor where creators build their pages, brandpages.com for the public-facing published pages their audience visits, and brandstatic.com as a CDN origin for user-uploaded media. Each domain has its own role in the security and caching model.

For authentication, I chose a strict posture: __Host- cookie prefix for session tokens, dual JWT rotation, and security_stamp session invalidation. These are the patterns you expect from an auth provider, not a SaaS side project — but for a multi-tenant commerce platform they are non-negotiable.

The commerce stack was built from scratch. Cart, guest checkout, orders, digital delivery, coupons, and Stripe subscriptions all live in the same codebase, working against the same multi-tenant data model. Plan enforcement runs across six-plus dimensions (max sites, allowed block types, custom domain, visual effects, analytics, commerce) and each tier gets evaluated at request time.

A three-domain Next.js application stack: the editor (brand.com) runs as an authenticated admin surface; the published pages (brandpages.com) are public, cache-friendly, and tenant-isolated at the path level; the static CDN (brandstatic.com) serves user media with strict CORS and content-type validation.

A Stripe subscription lifecycle handler with a 7-day grace period for past-due accounts. Webhooks run through a verified handler that writes to the same database that the editor and public pages read from, with plan state reflected in real-time everywhere.

Plan enforcement at the rendering layer: every block type, every commerce feature, every customization option is gated against the current tenant plan. Downgrading a subscription does not break a creator’s existing page — it hides or disables the premium features until they upgrade again.

Analytics built on an in-memory event buffer that rolls up hourly via a cron job. GDPR-compliant (no IP storage, no cookies for non-authenticated visitors), stored in the same PostgreSQL database as the rest of the app, and queryable by the creator in their dashboard.

Thumbstack runs as a single operator SaaS with a complete commerce stack, three-domain architecture, and multi-tenant data isolation. Every commerce feature that competitors treat as a pro add-on is included in the default build.

The authentication posture is stricter than most link-in-bio platforms in the market — __Host- cookies, JWT rotation, security_stamp invalidation. The setup was written so that session compromise is recoverable without logging every tenant out.

Subscription lifecycle is fully automated: upgrades, downgrades, grace period handling, and plan enforcement are all driven by Stripe webhooks without manual intervention. Billing state is always authoritative from Stripe, never from the application database.

The whole system is operated solo. The three-domain architecture, multi-tenant database, full commerce stack, and subscription lifecycle are all maintained by one person — which was the original design constraint, not an afterthought.

E-commerce platform migrations are the kind of project every operator dreads. WooCommerce and Shopify both have REST APIs, but the shape of the data — variants, categories, media, orders, customers, SEO metadata — differs enough between them that a generic export-import tool always loses something important on the way across.

The common failure modes are all the same: variants get flattened into separate products, categories lose their hierarchy, media files get broken URLs, historical orders don’t transfer, SEO redirects are missing entirely, and the new store launches with half the traffic the old one had. The migrations that “work” often turn into multi-week rescue operations.

The opportunity I saw was to build a managed migration service with a real pipeline — not a download-one-CSV-upload-another tool — and sell it as a productized engagement with tiered pricing and a hard 48-hour SLA.

I started with the two source platforms I needed to handle most often: Shopify Admin REST API (2024-10) and WooCommerce REST API v3. I spent the first few weeks building field-level knowledge of both — not just reading the docs, but actually exporting real stores of varying sizes and watching which fields are present, which are missing, and which have subtle differences between the two platforms.

From there I designed the migration engine as an abstract pipeline with SourceClient and MigrationTarget as the two ends. SourceClient handles reading from WooCommerce or Shopify; MigrationTarget handles writing into a TanStack Start storefront. Every data type — products, variants, categories, tags, media, orders, customers, SEO redirects — gets its own pipeline stage with its own failure handling.

For pricing, I tiered the service: Starter at $69 for up to 50 products, Growth at $199 for up to 500, Scale at $399 for up to 5,000. The Scale tier carries the 48-hour SLA because at that size the migration is mission-critical and the customer needs a guarantee.

A 2,527-LOC migration engine with an abstract pipeline architecture. SourceClient is an interface; WooCommerceClient and ShopifyClient are implementations. MigrationTarget is the interface for destinations; the initial implementation targets TanStack Start storefronts. Adding a new source or destination is a matter of implementing one interface, not rewriting the pipeline.

Variant handling that preserves the full variant matrix: a T-shirt with size and color options transfers as a single product with the full variant grid intact, not as twelve separate products. Category hierarchy is preserved using a two-pass walk — first pass builds the category tree, second pass assigns products to the right nodes.

Media re-encoding on the way across: images get downloaded from the source, re-encoded to modern formats (WebP, AVIF), uploaded to the destination, and URLs are rewritten in product descriptions to point at the new locations. No broken image links on day one.

SEO redirects generated from the migration mapping: every old product URL gets a 301 redirect to the new one, so the new store inherits the old store’s search traffic instead of starting from zero. This is the single most important thing for a migration and the thing most migration tools completely miss.

The engine handles stores up to 5,000 products on the Scale tier with a 48-hour SLA. That SLA is achievable because the pipeline is designed to parallelize where it can and fail gracefully where it cannot — a single product failing its media re-encode step does not block the rest of the migration.

Variant matrices, category hierarchies, media re-encoding, order history, and SEO redirects all transfer as first-class concerns. The resulting TanStack Start storefront is functionally equivalent to the source store from the customer’s perspective, but with modern performance and a cleaner codebase.

Pricing tiers map directly to pipeline complexity: Starter runs mostly from cache, Growth runs the full pipeline end-to-end, Scale runs with parallelization and dedicated SLA-backed attention. One operator can service multiple Scale migrations per week because the pipeline is the product, not the work.

Switch Cart runs as a productized B2B service, not a consulting engagement. Customers pay a fixed tier, receive a finished migration inside the SLA, and keep the storefront. The engine’s abstract pipeline means the next source or destination platform is an interface implementation, not a rewrite.

This one is not a commercial problem. It is a passion project that grew into a brand. Captain is my dog. Squish Biscuit started as a handful of short-form videos, turned into something audiences kept sharing, and eventually crossed a million followers across TikTok, Instagram, and YouTube without any paid distribution, no products, no e-commerce, and no ad revenue strategy driving it.

The interesting thing about Squish Biscuit from an operator perspective is what it demonstrates: content creation and audience building at scale, brand voice that is distinctive enough to carry across platforms, and the genuine pet-owner perspective that cannot be manufactured by a marketing team pretending to care about dogs.

Everything is built around Captain as the central character. Every video has a consistent voice, a consistent visual treatment, and a consistent emotional register — wholesome, short, genuinely funny, and grounded in real moments rather than staged setups.

The distribution approach is platform-native. TikTok gets TikTok-shaped content (hooks in the first second, native audio, tight cuts). Instagram gets Reels that are subtly reframed for a different scroll rhythm. YouTube gets Shorts plus a slower long-form cut when the moment warrants it. The same footage rarely gets posted identically across platforms — each one gets its own edit.

Brand voice is not written down in a document anywhere. It lives in my head and in the pattern of what gets posted. The tone is specific enough that I can tell within two seconds whether a piece of content belongs on the Squish Biscuit feed or does not.

Squish Biscuit is a pet content and creator brand — a viral dog content channel, not a business. No products, no e-commerce, no monetization strategy underneath it. Audience growth has come entirely from organic distribution on TikTok, Instagram, and YouTube, with Captain as the anchor character.

The content is short-form wholesome dog video: TikToks, YouTube Shorts, and Instagram Reels. Production is straightforward, the focus is on moment capture and tight editing rather than elaborate setups. The quality of the audience connection comes from the perspective being genuine — a real dog, a real owner, not a pet brand pretending.

Everything about the brand is owned end to end. I shoot, edit, write captions, post, respond, and steer the voice. There is no team. The constraint is the point: the brand stays tonally consistent because the same person touches every piece of content before it goes out.

Approximately 1.3 million total followers: ~800K on TikTok, ~300K across Instagram and Facebook, ~165K on YouTube. All organic. No paid distribution, no influencer partnerships driving the growth.

The brand demonstrates genuine pet owner perspective at scale. That matters because it is the thing most pet-brand content is missing and cannot fake — the distance between marketers writing about dogs and a person who actually lives with one shows up in the tone and the audience response.

Squish Biscuit is the thing outside of work that informs the thing inside of work. The pet industry is one of the verticals I care most about applying my operational experience to — registration, reunification, safety, welfare, community. Breed Standard is a planned counterpart that focuses on those serious concerns where Squish Biscuit focuses on entertainment.

At the operator level, the brand is proof that I can build and sustain audience from zero without a playbook — the same way I build products from zero without a team.