Most founders who think they've outgrown Shopify haven't. They're frustrated. Frustration is not the same signal.

The founders who genuinely need a custom build have specific problems Shopify cannot solve at any price. Plugin stacking won't fix them. A new theme won't fix them. They need their own application.

This piece is the honest version of that call. Here are the four signals that mean you've actually outgrown the platform, what you should keep vs rebuild, and how to migrate without blowing up the business you already have.

The Four Signals You Have Genuinely Outgrown Shopify

These are the only four reasons I treat as a real "go custom" signal. If none of these are true, the answer is almost always "stay on Shopify and fix the operations problem you actually have."

1. Your business model is no longer commerce-shaped. Shopify is brilliant at product, cart, checkout, fulfillment. If your actual revenue runs on subscriptions with complex entitlements, marketplace economics with split payouts, B2B quoting and PO workflows, usage-based billing, or an internal operations tool that customers also touch, you're paying the Shopify tax to hold a shape that no longer fits. Plugins can paper over one of these. Not three.

2. Your unit economics are getting eaten by app fees. Run the number. Add up every recurring app you depend on: subscription billing, B2B portal, custom pricing, advanced search, reviews that actually work, ERP sync, the loyalty plugin nobody can remove. When the monthly app bill plus Plus fees plus per-transaction costs is more than a senior engineer's loaded cost, you're funding someone else's product to avoid building your own.

3. You can't ship the thing that would actually move the business. You know the feature. You've sketched it. Every quote from an agency comes back as "you'd need to leave Shopify to do that properly," or the workaround needs three apps, two webhooks, and a Zap. The roadmap that would change your trajectory is the one Shopify won't let you build.

4. The data model fights you every quarter. You're storing critical business state in metafields, tag soup, or a third-party "headless CMS layer." Reporting is duct tape. Migrations are dangerous because the source of truth is split across four systems and nobody's sure which one wins.

If two or more of these are true, you have a real platform problem. If only one is true, fix it in place first. For early-stage founders weighing the spend before committing, our breakdown of the cost to build a SaaS in 2026 is the right next read.

What You Keep and What You Rebuild

The biggest mistake in any platform migration is rebuilding what already works. Shopify does a lot of things well, and the version you'd build yourself in year one will be worse than the version Shopify gives you out of the box.

Keep using Shopify (or Stripe-led equivalents) for:

Checkout. Their conversion rate is the product of a decade of optimization you can't replicate cheaply.
Payments, tax, and fraud rails. Don't reinvent any of this in year one.
Inventory and fulfillment if you ship physical goods.
The storefront itself, if your problem is in the back-of-house and the front-end is fine.

Rebuild custom for:

The thing that's actually broken. The workflow, the data model, the customer-facing feature Shopify won't let you ship.
Anything where you need to own the data model: subscriptions with complex states, B2B accounts, marketplace ledgers.
Internal tools your operations team lives in. These are usually the highest ROI part of a custom build, and the part founders forget to scope.

The cleanest pattern: keep Shopify (or just Stripe Checkout) as the payment surface, build the custom app around it, and let the two systems talk over webhooks. You get the conversion rate of a mature checkout and the flexibility of an owned application. You do not need to migrate everything to claim the win.

If you haven't priced this kind of split before, the cost to start a SaaS company post walks through realistic ranges for the "custom app plus hosted payments" shape specifically.

The Migration That Does Not Lose Data or Rankings

The two ways migrations destroy businesses: customer data goes sideways, or organic traffic disappears overnight. Both are preventable. Neither is automatic.

Data: dual-write before you cut over. Don't migrate by export-import. Stand up the new system, write to both Shopify and the new app for at least 30 days, reconcile nightly, and only flip the read path once you've matched a full cycle of orders, refunds, and edge cases. If your reconciliation script can't explain every diff, you are not ready to cut over.

Rankings: the URL map is the whole job. Every URL Google has ranked is an asset. Before launch, export your top 500 ranking pages from Search Console, map each one to its new URL, and 301 every old URL to the new one. Not a 302. Not a JS redirect. A real 301 on day one. Keep your sitemap honest. Resubmit it the day you cut over.

I've watched two migrations lose 40% of organic traffic in a week because the team treated the redirect map as a nice-to-have. The recovery took six months. The redirect map would have taken three days.

Cut over on a Tuesday, not a Friday. Give yourself a full business week of daylight to catch what breaks. Migrations always break something. You want your team awake and your customers in their inboxes when they hit it.

Timeline and Cost, Realistically

For a serious migration off Shopify Plus to a custom application, with the payment surface kept intact:

Discovery and architecture: 2 to 4 weeks. Map the data model, define the keep/rebuild split, write the migration plan.
Build: 3 to 6 months for the first usable version, depending on how much custom workflow you're actually rebuilding. Anyone quoting six weeks for a real migration is selling you a CMS reskin.
Dual-write and reconciliation: 4 to 8 weeks running in parallel with build.
Cutover and stabilization: 2 to 4 weeks of close watching.

Cost ranges widely with scope. A focused custom app that wraps Stripe and handles one core workflow Shopify couldn't: $80k to $150k done well. A full operations rebuild with custom B2B portal, ERP integration, and a customer-facing app: $200k to $400k. Anything quoted at $30k is going to cost you the original $30k plus the rescue project that comes after.

The honest framing: a custom build is not cheaper than Shopify in year one. It's cheaper in year three, and only if the four signals at the top were actually true when you started.

The Same Logic for Lovable and Bolt Apps That Hit the Wall

This is the same conversation founders are having about AI-built apps, just with the timeline compressed.

A Lovable or Bolt app gets you to a demo in a weekend. The demo is real. It runs. It looks good. Founders ship them to friendly customers and get genuine interest. Then the first paying customer hits a real edge case, and the cracks show: no auth model that survives contact with reality, a database schema that can't handle the second use case, no migration story, secrets in the client bundle, no error handling, no tests, no observability.

You haven't outgrown Lovable. You've hit the production wall every prototype hits, just faster than you would have with a hand-coded MVP. The fix is the same as the Shopify version of this story: keep what works, rebuild what doesn't, do not throw the whole thing out.

What you keep: the UX. The flows your customers already validated. The product shape you found.

What you rebuild: the data model, the auth, the backend, the parts that need to survive ten thousand users instead of ten.

If your AI-built app has paying customers and is starting to concern you, that's the moment to get a second pair of eyes on it before you keep stacking features on a foundation that won't hold. Two ways we help with that:

Ship Check: a free 30-minute teardown of your current build, focused on what will break first under real load. No commitment.
Rebuild: when the Ship Check confirms the foundation needs work, this is the keep-the-product-shape, rebuild-the-engine service.

For founders whose AI-built app has security or stability issues right now, the Rescue service is the faster path.

Not sure if you've actually outgrown your stack?

A 30-minute Ship Check will tell you whether you have a platform problem or an operations problem. Most founders find out they don't need to migrate. The ones who do leave with a clear plan.