Okay so — you saw the headline. "GitHub Spark is shutting down." Maybe it came through a newsletter, maybe someone dropped it in a Discord you're in, and your stomach did the thing it does whenever you're mid-decision between two or three tools and one of the contenders just died in public.
You haven't built anything on Spark. You're not the person racing GitHub's export deadline. You're the person with three tabs open — maybe Lovable, maybe Bolt, maybe v0, maybe Replit — trying to pick the one you're going to sink your first real weekend project into, and you just watched proof that "AI app builder" is a category where the ground can move.
Good instinct. Wrong question, though. The question isn't "which one replaces Spark." It's "how would I have known, in advance, that this one was going to happen." Because that check exists, it takes about twenty minutes, and you can run it on your actual shortlist this afternoon, before you write a single line of the thing you're trying to build.
What actually happened to Spark, briefly
GitHub Spark launched July 24, 2025, as a public preview — Copilot Pro+ subscribers could describe an app in plain English and get a deployed, working version back, storage and AI calls and hosting all bundled in.
It never left preview. About a year later, on August 4, 2026, GitHub's changelog announced Spark stops taking new users and stops letting anyone create new apps. Existing users get until August 31, 2026 to export their code. Apps you'd already deployed keep running — but if you want to keep editing one, you need the export, and after that date you don't get it.
Here's the part I think is the actual tell: five days before the shutdown announcement, on July 30, 2026, GitHub Models — the inference service that powered Spark's built-in llm() function — was fully retired. Every Spark app that called llm() without wiring up its own outside AI provider broke that week, before anyone said the word "deprecation" out loud. The shutdown wasn't a single announcement. It was a company quietly pulling the plug on the thing underneath the thing, and the public notice came after.
That sequence — infrastructure dies quietly, announcement follows — is the pattern worth learning, not the specific tool. So here's the check, run against whatever you're actually choosing between right now.
Check 1: export it today, not the week you need it
Go to the builder you're leaning toward. Build the smallest possible thing — a single page is fine. Hit export or download. Unzip it on your own machine and try to run it without the platform.
unzip my-export.zip -d my-export cd my-export cat package.json grep -rniE '@?[a-z0-9/-]*(sdk|client|runtime)' package.json
You're looking for two things. First, does it even boot with 'npm install' and 'npm run dev' against a database and auth setup you control — or does every meaningful feature route through a package that only talks to the vendor's own servers? Second, that grep line is a first pass, not a verdict — it will surface names built from the words sdk, client, and runtime, scoped or not, but a vendor can call its lock-in package whatever it wants, so open package.json afterward and read every dependency name yourself. Still, a grep is a flashlight, not a guarantee, and the dependency that actually locks you in might not have "sdk" in its name at all — it might just be called '@lovable/core' — so the real check is your own eyes on the full list.
If the export unzips into something that only fully works while still plugged into the vendor — that's not an export. That's a backup copy of your prompt history with extra steps. Run this test on your top candidate before you build anything real on it, not after you're three weekends in.
Check 2: read how the vendor talks about it
Go find the product's own blog post, docs, or "about" page and look for the words they use about themselves. Is it "the future of how you'll build software" — stated plainly, as the main thing? Or is it "preview," "experimental," "labs," "beta," one option among several similar ones the company is trying?
Spark never called itself the main thing. GitHub's own September 2025 changelog post — two months after launch — was still titled "GitHub Spark in public preview." A product a company believes in gets promoted out of preview. A product still wearing the word "preview" more than a year in is a company that hasn't committed to it either, and that ambivalence is visible before the shutdown, not after — you just have to go read the label instead of the demo video.
Check 3: who actually loses money if this dies
This is the one people skip because it feels like it's not your business. It's entirely your business.
Ask: is this builder the whole company — its entire revenue, its entire reason for existing — or is it one feature living inside something bigger? Spark lived inside GitHub, which lives inside Microsoft. Cutting it doesn't threaten anyone's payroll. A standalone builder whose founders' only product is the builder has a different incentive: if it dies, their company dies with it, so keeping it alive is existential, not a line item a reorg can zero out in a planning meeting nobody outside the company ever sees.
You can usually answer this in five minutes on the company's own "about" or "company" page — is this the product, or a product. Neither answer means "don't use it." A standalone bet can also fail for ordinary business reasons. But a feature-inside-a-portfolio needs a second question you should also ask: does the parent company's blog, X account, or investor materials talk about this feature much, or has it gone quiet? Quiet is what a deprioritized feature looks like for months before anyone announces anything.
Check 4: get the portability promise in writing, up front
Not a support article that appears after a shutdown telling you how to migrate — before you commit, check whether the vendor states, in their docs or terms, that your code is yours, exportable at any time, in a standard format, no strings. Search their docs page for "export" and see what comes back. A sentence you can point to later is worth more than a feature you're assuming exists.
If you can't find that sentence anywhere before you've signed up, that's information. It doesn't mean the builder is doomed. It means nobody has bothered to promise you anything about the day you might want to leave, and a company that hasn't thought about your exit hasn't necessarily thought less about staying alive — but it has thought less about you.
Why this matters
Every comparison post about AI app builders is shaped the same way: a feature grid, a pricing table, "choose X if you want Y." That's a fine way to pick a tool for a project you're starting tomorrow. It's useless for the question underneath it, which is whether the tool will still exist in six months, because staying power isn't a feature anyone puts in a grid. It shows up in how a company talks about its own product, who actually loses if it disappears, and whether you can walk out the door with something that still runs. Those are checkable facts sitting in public right now, on every candidate on your shortlist, and none of them require you to guess.
Your next step
Before you write a single feature on the builder you're leaning toward, run today's check: check 2 and check 4, both doable in a browser with zero setup — read how the vendor talks about itself, then search their docs for "export." What you find is real information about your actual candidate — not vibes from a headline about a different company's product. Check 1 is the deeper one; save it for once you've actually picked a builder and started building, then export the smallest thing you make before you're three weekends in.