DEV Community: Sneh

I Can Tell If Code Is Bad Without Reading It. Here's My Trick.

Sneh — Fri, 04 Sep 2026 05:01:38 +0000

People usually guess wrong when I tell them this.

Most people think I check the tests first, since no tests is supposed to mean bad code. Some think I read the README to see if anyone bothered explaining the project. Others guess I check the git history, looking for one huge, messy commit at the end.

Those are all good guesses, and they're all wrong.

Here's what I actually do. Before I read any code, I look for one file. Most of the time, it's missing. That file is called .env.example.

What that file actually is

You've probably never heard of it, and that's fine. Here's what it does.

Every app needs a few secret settings to run, things like a link to its database, a password, or a key for sending emails and taking payments. These are secrets, so they can't just sit out in the open in the code, where anyone could find them.

That's why most real projects keep those secrets in a separate file called .env. That file stays hidden. Nobody shares it, and nobody uploads it to GitHub.

But smart teams also keep a second file, called .env.example. It lists what secrets the app needs, without giving away the real values, something like this:

DATABASE_URL=
STRIPE_SECRET_KEY=
SMTP_HOST=

No real passwords, just the shape of what's needed. Think of it like a packing list for a trip. It doesn't pack your bag for you, it just tells the next person what to bring.

That sounds like a small thing, but it isn't. It's the single best clue I've found for how seriously a codebase was actually built.

Why one boring file tells you this much

To write that list, someone had to stop and think about what the app truly needs to run, and then write it down clearly enough for someone else to follow. You only do that when you expect someone else to need it, whether that's a teammate or your own future self on a different laptop.

That expectation is the whole signal. A project with a real .env.example has been run somewhere other than the original coder's own machine, at least once, by a second person.

A project without one has usually only ever run in one place, set up by one person, who never had to explain it to anyone else. So before I read a single line of logic, I already know a few things: nobody has checked that this app truly runs from scratch, the secrets probably aren't handled the safe way, and I'm about to spend my first hour untangling a setup that was never really planned, just pieced together over time.

What's usually sitting there instead

When that file is missing, the secrets don't just disappear, they show up somewhere worse.

I've opened files with a Stripe secret key typed straight into the code. I've found a database password sitting in a settings file like it's nothing special. More than once, I've found real, working secret keys buried in old GitHub commits, because nobody added .env to the ignore list in time. Even if that file got deleted a few commits later, those old keys are still sitting there in the history, and every one of them should be treated as already leaked.

None of that shows up if you're just skimming the business logic. It shows up in about five seconds, once you know which file to check first.

This is almost always missing from AI-built apps too

A lot of apps get built today by typing one sentence into a tool like Lovable, Bolt, Replit, v0, or Base44. These tools are fast, and genuinely good at what they do, but I've almost never seen a real .env.example come out of one.

That's not really their fault. The app only ever runs inside that tool's own hosting, so nobody ever had to hand it to a second developer or explain what it needs. The one thing that usually forces a project to grow this file, a second person needing to run it, just never happens.

That matters if you're planning to take one of these apps further, onto your own hosting, in front of real users, with real money attached. The gap between what these tools show off and what they quietly skip tends to follow this same shape. It stays invisible until someone other than the person who wrote the prompt actually tries to run it.

A few more quick checks, if you want more than one

Check whether .env is actually in the ignore list, and whether it got added on day one or three commits too late. That tells you if secrets were a real decision or an afterthought.

Check the database folder too. One giant file at the start and nothing since usually means the database has been changed by hand, live, with no record of what changed or when.

And check whether the list of installed packages actually matches what the code uses. If it doesn't, "it works on my machine" is doing a lot of heavy lifting in that sentence.

Each of these checks takes less time than opening a single code file, and none of them require you to understand what the app even does.

Why this beats reading the code first

Reading the code shows you what a developer meant to build. These small, boring files show you how they actually worked, when nobody was checking their homework, and I trust the second one more.

This is close to the very first thing we check at EnactOn, before we open a single file in a codebase someone hands us, whether it came from a freelancer, an agency, or a prompt. Most real projects go through this same growing-up process eventually, the only question is whether it happened before you inherited the app, or is about to happen on your watch.

Next time you open code you didn't write, try this first. Look for the file that isn't there. It usually tells you more, faster, than the code ever will.

What's the one thing you check first in code that isn't yours?

I Asked 5 AI App Builders to Build a Login System. 4 of Them Forgot That Users Forget Passwords.

Sneh — Thu, 03 Sep 2026 05:28:56 +0000

Every AI app builder I've tried can spin up a login screen before you've finished your coffee. Clean form, nice validation, a satisfying little loading spinner. What I wanted to know was whether any of them would also remember the part that never shows up in a demo: the moment, weeks later, when a real user forgets their password and needs a way back in.

So I ran an experiment. Same prompt, same day, five different AI app builders, zero follow-up messages. I wanted to see what each tool considered "done" when nobody was there to ask for more.

The Setup

The prompt was exactly twelve words, and I counted them on purpose so nobody could argue I'd buried a hint in there: "Build a simple app where users can sign up and log in."

That's it. No mention of password reset, no mention of email verification, no mention of sessions or security. Just the sentence any non-technical founder would actually type into one of these tools on day one, because "sign up and log in" is how most people describe "basic auth" without knowing the term.

I tested five tools that all sell the same pitch: describe your app, get a working product. Lovable, Bolt, Replit's Agent, v0, and Base44. For each one, I pasted the prompt once, let it finish generating, and then tried to actually use what it built. I clicked every visible button, checked whether a "forgot password" link existed anywhere, and where I could see the generated code, I searched it for anything resembling a reset token, a reset endpoint, or an email-sending step.

Four out of five had nothing. Not a broken attempt at password reset. Not a placeholder. It simply never occurred to the tool that a login screen might need one.

What each one actually shipped

Lovable was fast and it was pretty. Under two minutes and I had a signup form and a login form with real client-side validation, animated error states, and a dashboard shell waiting behind the login. I looked everywhere a "forgot password?" link is conventionally supposed to live, under the password field, next to the submit button, in the footer. Nothing. Lock yourself out here and there is no way back in except signing up again with a different email.

Bolt produced something in the same spirit, arguably tighter on the styling side, with a slightly more convincing dashboard mockup behind the auth wall. Same story underneath. Working signup, working login, and the account recovery path simply doesn't exist. I opened the generated source to double check I hadn't missed a hidden route. There wasn't one.

Replit's Agent was the most ambitious of the four. It actually wired up a real database table for users instead of faking the auth state client-side, which is a meaningfully more production-shaped choice than what Lovable or Bolt did. Sign up worked, log in worked, sessions persisted properly on refresh. And still, nothing for reset. The closest it came was a generic "contact support" line sitting in the footer, which is not a password reset flow, it's a promise that a human will eventually deal with the problem the software should have handled.

Base44 was the fastest of the five, and the least surprising. A working auth screen showed up almost instantly, no reset flow, no email verification step either. It optimized hard for "looks finished the second you land on it," and on that specific metric, it won.

v0 was the one that broke the pattern. Instead of hand-rolling a custom auth UI, it scaffolded a proper Next.js project with NextAuth wired underneath, and the reset flow was actually there: a "forgot password" link, a token-based reset route, and a mocked email step that would send a real reset link once you dropped in actual SMTP credentials. It wasn't polished. The reset page had zero styling and looked like it had wandered in from 2015. But it was structurally complete in a way none of the other four attempted.

The scorecard

Lovable — Signup + login ✅ · Password reset ❌ · Email verification ❌ · Real DB-backed users ❌

Bolt — Signup + login ✅ · Password reset ❌ · Email verification ❌ · Real DB-backed users ❌

Replit Agent — Signup + login ✅ · Password reset ❌ · Email verification ❌ · Real DB-backed users ✅

Base44 — Signup + login ✅ · Password reset ❌ · Email verification ❌ · Real DB-backed users ❌

v0 — Signup + login ✅ · Password reset ✅ · Email verification ❌ · Real DB-backed users ✅

Why four out of five missed it, and it isn't really a bug

None of these tools are broken. Each one did exactly what it's optimized to do, which is turn a short sentence into something that looks finished on the first two screens a person actually sees. A signup form and a login form are the entire demo. Nobody records a screencast of clicking "forgot password" to show off a new app builder, so there's no pressure, competitive or otherwise, for that screen to exist.

There's a second, more structural reason underneath that one. Password reset isn't just a UI screen, it's a small distributed system: a token that expires, a database write to invalidate the old password, and an email that has to actually leave the building through a real SMTP provider or transactional email service. That last part requires credentials the AI builder doesn't have and can't invent. Signup and login can be faked entirely client-side if a tool wants to cut corners, which is exactly what Lovable, Bolt, and Base44 did. Password reset can't be faked the same way, because at some point a real email has to go somewhere. My guess is that's a meaningful part of why it gets skipped rather than half-built: there's no convincing way to fake it, so it's easier to just not mention it.

v0 sidestepped the problem by not trying to invent the wheel. Scaffolding a known library like NextAuth means inheriting whatever that library's maintainers already decided a complete auth system needs, reset flow included, even in a rough, unstyled, "you still have to plug in your own email provider" state. The other four built something closer to a bespoke UI kit than an actual auth system, and bespoke is exactly where the corners get cut.

None of this is really about the prompt being too short. A real build usually moves through discovery, scoping, and a hardening pass before anything reaches a user, and that's roughly the shape most production MVPs actually take, even the ones that come together fast. A single twelve-word sentence was never going to carry all of that on its own, which is exactly why it's worth checking what got left behind.

The part that should actually worry you

Password reset is just the gap that's easy to catch, because everyone already has an intuition for what a login screen is supposed to include. It's the visible tip of a much less visible problem.

None of the four also handled account enumeration, meaning I could tell from the signup error message alone whether a given email was already registered, which is a small but real information leak. None of them had rate limiting on the login form, so nothing was stopping an unlimited number of password guesses against any account. Only one reset a user's other active sessions after a password change, which matters a lot if the reason someone's changing their password is that they think their account's been compromised in the first place.

None of that shows up in a ninety-second demo either. It only shows up when you go looking for it, which is precisely the problem: most people don't go looking, they ship what the tool handed them.

This is close to what we keep running into at EnactOn whenever a founder hands us a prototype from one of these builders and asks us to take it into production. The parts that impressed them in the demo are reliably fine. The parts nobody clicked on are where the actual work is waiting. If you're leaning on one of these tools for something you intend to charge real users for, it's worth understanding where the genuine trade-offs sit before assuming "it worked when I clicked through it" means "it's ready for someone else to click through it too."

What to actually check before you trust the output

Don't just test the two flows the tool showed you. Go find the third one it didn't.

Forget your password on purpose and see what actually happens when you click through the flow, not just whether a link exists. Sign up with an email that's already registered and read the error message closely, since a message that confirms the account exists is a small gift to anyone running a credential-stuffing attack. Log in, change your password, and check whether a session you opened before the change still works somewhere else. Hammer the login form with wrong passwords a dozen times in a row and see if anything stops you, because in four out of five tools here, nothing did.

None of this takes more than twenty minutes to check by hand, and doing it before a real user finds the gap is a lot cheaper than doing it after. The broader shape of what these tools are actually good at, and where that speed runs out, is worth reading before you decide how far to trust the output of any single prompt. This is close to the actual checklist we run at EnactOn before we'll tell a founder their AI-built app is ready for a real user, and none of it is exotic, it's just the stuff a demo never forces you to check.

Every SaaS product that survives past its first hundred real users ends up going back and building this exact list eventually. The ones that made it look obvious in hindsight mostly just did it before launch instead of scrambling to do it after.

Has anyone else run one of these builders through a flow it didn't bother showing off, and found something missing?

He was raising money for a product nobody had ever paid for.

Sneh — Mon, 24 Aug 2026 12:54:35 +0000

The product had been live for three months. The founder had run the playbook properly: posting in the right communities, reaching out directly to people who matched his ideal customer, a public launch that landed better than he expected.

Signups climbed steadily off the back of it, and as the free trial numbers grew, he built his seed-round math around a standard assumption for an early SaaS product, something close to one in five trial users eventually converting to paid.

Three months and a few hundred free trial signups later, not one had converted. Not below plan, not slower than hoped. Zero.

He hired us a few weeks before his pitch to find out why, and to fix whatever could still be fixed before he stood in front of investors.

We ran the technical checks first

We put the product through the kind of pass we run at EnactOn before telling any founder they're investor-ready: automated QA, a full audit of the codebase, the works. It came back clean. No crashes, no security holes, nothing sitting anywhere in the product that would make a user hesitate. If code quality alone decided who pays, this thing would have had customers in its first week.

A flawless product with zero paying customers is its own kind of puzzle, and it's one we've learned to recognize quickly: when the build is solid but nobody's buying, the problem is rarely the product itself. It's who the product was built for.

So we asked him something simple: who is this actually for?

He started listing people. Freelancers, small agencies, solo founders, teams inside bigger companies, maybe students eventually, possibly enterprise down the line. Almost everyone, in other words.

That answer was the real finding. He'd built something that could plausibly help a lot of different people, and he'd marketed it the same way, casting one wide net instead of aiming at anyone specific. A net that wide pulls in attention. It doesn't pull in customers, because nobody in that crowd ever feels like the product was built with them in mind, and "could be useful to almost anyone" has never gotten a single person to pull out a card.

What the signup data confirmed

To check whether that held up, we looked past who'd signed up and at who'd actually stuck around. Most of the volume behind his one-in-five assumption had come straight from the public launch: people curious about a tool built for "almost everyone," who tried it for a session or two and quietly drifted off. A much smaller group, people who'd come in through his direct outreach to one specific type of team, kept coming back week after week, using it the way someone uses a tool they actually depend on. That group was less than a tenth of total signups, and it was the only place a real business was hiding.

He'd been throwing the net wide because wide nets feel like less risk. But that's exactly what was sinking the launch: casting for everyone meant landing nobody in particular. Sizing the actual audience before scaling acquisition is the step that would have caught this early, and it's the one most founders skip because the broad numbers already feel like progress.

What we changed with two weeks left

We pulled together the users who matched that narrow, high-engagement profile: eighteen people, out of a few hundred signups. He rewrote his messaging to speak to that one specific team, not the broad pitch that had worked for the launch crowd, and reached out to each of them personally with real pricing attached.

Six paid before he ever opened his pitch deck.

Six isn't a big number, and we told him that plainly. But it's six people who match exactly the kind of customer he'd be describing to investors, not an average pulled from a crowd that was never going to buy in the first place. That's a very different story to walk into a pitch with.

Why this happens more than founders expect

We see versions of this often enough that it's stopped surprising us, and the wider numbers agree: a lot of early products stall not because the product is weak, but because "built for everyone" quietly becomes the go-to-market plan, and a plan with no specific buyer in it never converts one.

A few things worth doing before your own raise, if this sounds close to home. Pick the one type of person you're building for, and if your honest answer sounds like a list instead of a single group, that's worth fixing before you scale anything. Break your signups down by source and by how deep people actually use the product, since an average across a mixed crowd can hide a real business sitting inside a much smaller group. And know what a typical SaaS build actually costs at each stage, so the roadmap decisions you make afterward are based on real numbers instead of a guess.

None of this happened because the founder was careless. He built something solid and marketed it well, it just wasn't aimed anywhere in particular. That's an easy thing to miss from the inside, because a wide net always looks fuller than a narrow one, right up until you check what's actually still in it.

Has anyone else watched a founder build for "everyone" and end up with paying customers from nowhere in particular?

The Complete Astro Migration Checklist Before You Go Live

Sneh — Tue, 11 Aug 2026 11:05:06 +0000

Moving a website to Astro can improve performance and simplify maintenance. But a successful migration involves more than rebuilding the homepage in .astro files. You also need to preserve URLs, content, metadata, forms, analytics, integrations, and the publishing workflow.

Use this as a working checklist. Copy it into your project issue, assign an owner to each phase, and do not approve the launch while a critical item remains unchecked.

Migration rule: The new site is ready only when it preserves the old site's valuable content, discoverability, and business functions not when it merely looks the same.

Phase 1: Decide what you are migrating

Confirm Astro suits the website. It is an excellent fit for marketing sites, blogs, documentation, landing pages, and other content-led websites.

List dynamic pages and interactive islands. Search, filters, calculators, and account widgets may need runtime code; most content does not.

Choose the content model. Decide between Markdown/MDX, Astro content collections, a headless CMS, or the existing CMS used headlessly.

Confirm the editorial workflow. Make sure non-technical editors can create, preview, update, and publish content after migration.

If you are still deciding whether the migration is justified, this Astro vs WordPress comparison explains the trade-offs around performance, plugins, ownership, and editing.

Phase 2: Audit the current website

Crawl the complete website. Use the sitemap and a crawler such as Screaming Frog or Sitebulb.

Export landing pages from Google Search Console and analytics. These sources can reveal important URLs missing from the sitemap.

Identify pages with traffic, conversions, or backlinks. Mark them as priority URLs for manual QA.

Inventory page templates. Include articles, listings, services, author pages, contact pages, archives, and error pages.

Inventory platform features. Record forms, search, comments, memberships, e-commerce, multilingual content, redirects, and scheduled publishing.

Audit third-party scripts. Include analytics, consent tools, chat widgets, schedulers, and advertising pixels.

Create a complete backup. Preserve the database, media, metadata, forms, redirects, DNS records, and deployment settings.

Phase 3: Prepare the Astro architecture

Choose static or on-demand rendering for each route type. Use Astro's static output by default unless a page genuinely needs request-time data.

Select the hosting platform and Astro adapter. Confirm runtime, environment-variable, image-processing, and redirect support.

Define content schemas. Validate titles, descriptions, dates, slugs, canonical URLs, images, and draft states during the build.

Create reusable layouts before individual pages. Build the document head, header, navigation, footer, article layout, and common content sections first.

Confirm the required Node version. Match local, CI, and production environments to the Astro version being used.

Avoid copying an existing React or Vue frontend into Astro and hydrating it entirely. Migrate reusable components where helpful, but add a client:* directive only when a component needs browser-side interaction.

Phase 4: Extract and clean content

Choose the correct extraction method. WordPress may use WXR, REST API, or WPGraphQL; Webflow may use collection exports or its API; Wix often requires crawling and manual reconstruction.

Export custom fields separately. WordPress ACF fields and plugin data may not appear in a standard XML export.

Extract SEO-plugin data. Titles, meta descriptions, canonical settings, and social images stored by Yoast or Rank Math need their own migration path.

Find and replace shortcodes. Convert galleries, forms, embeds, and custom shortcodes into Astro components or replacement services.

Download every image and file. Do not hotlink assets from the old platform's CDN.

Preserve content relationships. Keep authors, categories, breadcrumbs, related posts, dates, and localized versions.

Clean imported markup. Remove editor-specific inline styles, empty headings, spacer paragraphs, obsolete classes, and staging-domain links.

Platform behavior differs considerably. Refer to a platform-specific walkthrough when migrating from WordPress, Webflow, or Wix.

Phase 5: Replace platform functionality

Map every plugin or native feature to a replacement. Mark each one as replace, rebuild, or remove.

Rebuild forms as complete workflows. Test validation, spam protection, consent, email delivery, CRM delivery, and confirmation states.

Preserve campaign data. Ensure UTM parameters survive the form journey.

Restore analytics before cutover. Page views and conversion events must work before production traffic arrives.

Load third-party scripts intentionally. Delay non-critical tools and confirm consent choices control them correctly.

Recreate RSS feeds where required. Redirect legacy routes such as /feed/ to the new Astro feed.

A “Thank you” message does not prove the form worked. Submit a traceable lead and verify the inbox, CRM, and analytics event.

Phase 6: Protect SEO

Keep valuable URLs unchanged wherever possible. A framework change does not require a URL change.

Create one-to-one permanent redirects. Send removed URLs to the closest relevant replacement—not automatically to the homepage.

Test for redirect chains and loops. Each old URL should reach its final destination in one step.

Update internal links. The new site should link directly to final URLs rather than relying on redirects.

Preserve titles and meta descriptions. Compare old and new values automatically where possible.

Verify canonical and robots directives. Ensure they use the production domain and reflect the intended indexing state.

Recreate structured data and hreflang where relevant.

Generate a clean sitemap. Include canonical, indexable pages only.

Check robots.txt. It should reference the production sitemap and must not carry staging restrictions.

Astro redirects can be configured in astro.config.mjs:

`import { defineConfig } from "astro/config";

export default defineConfig({
site: "https://example.com",
redirects: {
"/old-service/": "/services/new-service/",
"/feed/": "/rss.xml",
},
});`

Test redirects on the deployed environment because the final response can depend on the build mode and hosting platform.

Phase 7: Validate on staging

Run npm run build successfully. Fix warnings that indicate missing content or routes.

Test the production build, not only the development server. Build-time data and environment variables can behave differently.

Crawl the staging site. Find broken links, missing pages, incorrect canonicals, and orphaned content.

Spot-check priority pages manually. Compare content, layout, metadata, images, and calls to action.

Test every redirect with its actual status code. Browser navigation alone can hide redirect problems.

**Test forms and integrations end to end. **Include valid, invalid, spam, and failure scenarios.

Run accessibility checks. Test keyboard navigation, focus states, headings, labels, contrast, and reduced motion.

Measure representative templates. Run Lighthouse after analytics, forms, embeds, and consent tools are installed.

Check mobile and major browsers.

Verify the custom 404 page. It should return a real 404 status, not 200.

Phase 8: Launch and monitor

Take a final backup and content export.

Reduce DNS TTL before cutover if DNS will change. Do this early enough for the previous value to expire.

Confirm production environment variables and CMS webhooks.

Verify HTTPS, redirects, canonical URLs, sitemap, and robots.txt immediately after deployment.

Submit the new sitemap in Google Search Console.

Confirm analytics and conversions using live traffic.

Keep the old platform available temporarily. It provides a rollback path and a reference for missing content.

Crawl production on launch day. Do not wait for users or Google to identify errors.

Monitor 404s, indexing, traffic, forms, and logs daily during the first two weeks.

Compare results page by page. Site-wide traffic can hide a problem affecting one valuable template.

The five checks that should block launch

Do not launch if any of these remain incomplete:

Every priority URL is preserved or redirected correctly.

Production pages are indexable and use correct canonicals.

Forms reach their final inbox or CRM destination.

Analytics records primary conversion events once.

The previous version can be restored if a critical failure occurs.

Final thought

Astro provides a strong technical foundation, but the framework cannot decide which URLs matter, whether metadata was lost, or whether a lead reached the sales team. That is why successful migrations depend on disciplined auditing and validation as much as development.

Why Cloudflare Acquired Astro And What It Tells You About Where the Web Is Going

Sneh — Fri, 31 Jul 2026 13:21:18 +0000

Cloudflare is a network infrastructure company. They run DNS, DDoS protection, and CDN services for millions of websites. They are not, historically, a JavaScript framework company.

In January 2026, they bought one.

Not just any framework, the fastest-growing one in the content-driven web space. And the whole Astro team came with it.

This wasn't a charity acquisition. Cloudflare paid to solve a specific problem. Understanding what that problem is tells you more about the future of web development than almost anything else happening in the ecosystem right now.

The Pattern You Need to See First

Vercel built Next.js. Not acquired it built it, owns it, runs it.

Every developer who learns Next.js defaults to deploying on Vercel. Not because Vercel forces them to. Because it's just the easiest path. The framework and the platform are designed to work perfectly together, and the friction of going elsewhere is real.

That's not an accident. It's a deliberate strategy: own the framework, own the developer pipeline, own the deployment decision.

Netlify tried the same thing with Gatsby. They became a major Gatsby sponsor, pushed it hard, built their platform around it. Then Gatsby's adoption stalled, Netlify's bet didn't pay off, and Gatsby was eventually acquired and effectively sunset.

Cloudflare watched all of this. They had the infrastructure. They had the network. They had Workers, Pages, D1, KV a genuinely powerful edge computing platform. What they didn't have was a framework developers were choosing because of them.

Astro fixed that.

Why Astro Specifically

Cloudflare could have acquired any number of frameworks. Why this one?

Three reasons, and they compound.

First: Astro runs at the edge natively. Astro's "server-first" architecture static output by default, dynamic islands where needed is exactly what edge computing is built for. You don't need a long-running server. You render at build time or at the edge, and the result is fast everywhere. Cloudflare's Workers runtime is a natural home for this model in a way it isn't for something like Next.js, which assumes a more traditional server environment.

Second: Astro owns the content-driven web market. Most of the internet is not interactive apps. Most of it is marketing sites, documentation, blogs, company websites, and editorial content. This is exactly where Astro has been winning and it's a massive part of the market that Vercel, with Next.js, isn't optimally serving. Cloudflare just acquired the dominant framework for that entire segment. The performance delta is measurable Astro vs WordPress and Webflow vs Astro comparisons put real numbers to the gap.

Third: Webflow and Wix already run on Cloudflare. Both platform which together power tens of millions of websites were already built on Cloudflare's infrastructure. Both had started integrating Astro for performance-critical use cases. The acquisition formalized what was already happening organically in the ecosystem. If you're on either platform now, migrating from Webflow to Astro and from Wix to Astro are well-documented paths.

Matthew Prince, Cloudflare's CEO, framed it as protecting open source infrastructure. That's true. But it's also a strategic land grab in the framework wars.

What Actually Changed With Astro 6

The acquisition immediately influenced Astro's technical direction in one very concrete way.

In previous versions, Astro's dev server ran in Node.js. Your production environment on Cloudflare Workers ran in workerd Cloudflare's open-source JavaScript runtime. They're not identical. Which meant you could write code that worked locally and broke in production because of runtime differences.

Astro 6, released in March 2026, fixed this. The dev server now runs locally using the same workerd runtime as production. You can test against Durable Objects, D1, KV, and Cloudflare Agents during local development. What you see locally is what runs in production.

For developers not using Cloudflare: the Vite Environment API underpinning this is runtime-agnostic, so the architecture works for other environments too. Cloudflare just happens to be the first with first-class support.

What It Means If You're Already Using Astro

The honest answer: not much changes day-to-day.

Astro is still MIT-licensed. Fully open source. The team is the same they all moved to Cloudflare. The roadmap is still public. You can still deploy to Vercel, Netlify, Render, Fly.io, or your own VPS. No one is forcing you onto Cloudflare infrastructure.

What does change: Cloudflare is now the path of least resistance. The dev-prod parity with workerd is a real developer experience improvement. The Astro Ecosystem Fund funded by Cloudflare alongside Webflow, Netlify, Wix, and Sentry means the framework has serious financial backing for the first time.

Astro's development pace is about to accelerate. That's good regardless of where you deploy.

What It Means If You're Not Using Astro

This is the more interesting question.

Cloudflare now has a framework answer. Vercel has Next.js. Cloudflare has Astro. The two frameworks target different use cases, highly interactive apps versus content-driven sites so this isn't a direct collision. But it does mean the major infrastructure players have picked their horses.

If you're running a content-heavy site, a marketing site, documentation, or a blog and you're not already on Astro, the question has shifted from "is Astro mature enough?" to "is there a reason I'm not using it?"

The answer used to be ecosystem concerns or team familiarity. Those get harder to justify as the framework's backing grows. Cloudflare uses Astro for their own documentation and marketing now. That's not nothing.

The platform-level comparisons now have clear answers: Astro vs WordPress, Astro vs Wix, Webflow vs Astro. And if budget is the remaining question, what Astro development actually costs is worth reading before you start conversations with agencies.

The Bigger Picture

The web is splitting into two distinct patterns, and the framework wars are reflecting that split.

Complex, interactive applications, dashboards, SaaS products, anything with real-time state, want a framework built around that complexity. Next.js, Remix, and their descendants.

Content-driven sites anything that's mostly text, media, and links want a framework that treats JavaScript as a cost to minimize, not a feature to maximize. Astro.

Cloudflare's acquisition is a bet that the second category is larger, more durable, and more strategically valuable than anyone gave it credit for.

Given that most of the internet is still a webpage with words on it they might be right.

EnactOn is an Astro development and migration agency. We've migrated 15+ sites from WordPress, Webflow, Wix, Gatsby, and Next.js to Astro. If you're evaluating a migration, see our Astro development services.

8 Mistakes to Avoid When Migrating to a GloriaFood Alternative

Sneh — Tue, 12 May 2026 13:01:57 +0000

GloriaFood's shutdown has sent thousands of restaurant owners and resellers scrambling for alternatives. If you've built a business. or a portfolio of restaurant clients. on top of GloriaFood, you already know how much is at stake. The ordering flows, the menu configurations, the customer data, the integrations. all of it needs to move somewhere new, and fast.

But urgency is exactly when costly mistakes happen.
Whether you're a reseller managing dozens of restaurant accounts or an agency looking to lock in a long-term recurring revenue stream, the decisions you make during this migration window will define your business for the next several years. This article walks through the eight most common mistakes people make when switching away from GloriaFood. and how to avoid each one.

8 Mistakes Resellers Make When Switching From GloriaFood

**
**

Mistake #1: Choosing Another SaaS Instead of Owning Your Solution

**
This is the single biggest mistake resellers and agencies make, and it deserves the most attention.

When GloriaFood announced its shutdown, the instinct for most people was to find the next Gloriafood alternative SaaS platform. something familiar, something with a slick dashboard and a free trial. It feels safe. But if you're a reseller managing multiple restaurant clients, renting software indefinitely is a financial trap.

Here's the math:

Say you manage 100 restaurants and sign up for a SaaS alternative at $100 per restaurant per month. That's $10,000 every single month. $120,000 per year. going straight to a platform you don't own, can't fully control, and could shut down on you again (just like GloriaFood did).

Now imagine that platform raises prices. Or discontinues a feature your clients depend on. Or gets acquired. You have zero leverage. You've built your entire business on rented land, and the landlord can change the rules at any time.

Contrast this with owning a white-label, self-hosted solution. The upfront investment is higher, but the per-restaurant cost collapses dramatically over time. At 100 restaurants, even a moderately priced owned solution amortizes its cost within months. and from that point forward, your margins grow with every new restaurant you onboard, not shrink.

This is exactly why resellers and agencies migrating away from GloriaFood should seriously consider a white-label GloriaFood clone built for ownership. Unlike SaaS subscriptions, an owned solution means you control the pricing, the branding, the features, and the roadmap. You can charge your restaurant clients whatever makes sense for your market, and the platform cost doesn't scale linearly with your growth.

If owning your infrastructure sounds complex, it doesn't have to be. Modern white-label restaurant ordering solutions come with the backend fully built. customizable based on your specific needs. so you're not starting from scratch. You're buying ownership, not starting a software company.

The bottom line: If you're managing more than 10–15 restaurant accounts, the math almost always favors ownership over SaaS. Do the calculation for your own portfolio before you sign any new subscription.

Mistake #2: Migrating Without Auditing Your Current Setup First

**
Before you move anything, you need to know exactly what you have. Most resellers underestimate how much configuration lives inside their GloriaFood accounts. menu structures, modifier groups, delivery zones, tax settings, printer configurations, and integration webhooks.

Jumping into a new platform without a full audit leads to missing items, broken workflows, and angry restaurant clients on day one. Spend time documenting everything before migration begins.

Get a full migration checklist for resellers here.

Mistake #3: Not Stress-Testing the New Platform Before Going Live

**
A demo environment is not the same as a live environment. Before you migrate a single restaurant client, run real orders through the new system. Test peak-hour scenarios. Test failed payments. Test what happens when a printer goes offline.

Platforms that look polished in demos often reveal gaps under real-world conditions. Discover those gaps on your own test account, not on a client's Saturday dinner rush.

Mistake #4: Ignoring Data Portability and Customer History

Customer order history, loyalty data, saved addresses. this is valuable data your restaurant clients have accumulated over years. Many resellers focus entirely on migrating the menu and forget about the customer database.

Ask any alternative platform directly: Can we import customer data? In what format? What happens to historical orders? If the answer is vague or the format is locked, that's a red flag. Your clients' marketing lists and repeat customer relationships shouldn't disappear because of a platform switch.

Mistake #5: Letting Clients Migrate Themselves Without Guidance

If you're a reseller, don't send your restaurant clients a link to a new platform and wish them luck. Restaurants are busy operations. Owners don't have time to figure out a new system, and if they struggle, they'll blame you. not the platform.

Create a migration playbook. Walk clients through the new interface. Offer onboarding calls. The resellers who retain their client base through this GloriaFood transition will be the ones who provide hands-on support, not just a forwarded email with login credentials.

Mistake #6: Overlooking Integration Requirements

GloriaFood connected to POS systems, delivery aggregators, payment gateways, and accounting tools. Before committing to any alternative, map out every integration your restaurant clients rely on and confirm the new platform supports them natively. or has a clear path to support them.

A platform that handles ordering beautifully but can't connect to a client's existing POS will create more operational headache than it solves. Get integration confirmation in writing, not just from a sales call.

Mistake #7: Choosing a Platform Based on Price Alone

The cheapest alternative is rarely the best alternative. Low-cost SaaS options often cut corners on reliability, support response times, or feature development. When a restaurant's ordering system goes down on a Friday night, the cost of the outage in lost orders and reputation damage far exceeds any savings on the monthly subscription.

Evaluate platforms on uptime history, support quality, and how actively the product is being developed. not just the sticker price. And again, factor in long-term cost trajectory: a "cheap" SaaS that raises prices after your clients are locked in is not actually cheap.

Mistake #8: Not Planning for Customization Needs

Every restaurant business has quirks. Custom fee structures, unique menu layouts, specific notification workflows, regional compliance requirements. GloriaFood, for all its limitations, had years of feature refinement behind it.

When evaluating alternatives, don't just assess what the platform does today. assess how easily it can be customized for what your clients will need tomorrow. A rigid SaaS platform will always say "that's on our roadmap." An owned, customizable solution lets you build what you need, when you need it.

This is a particularly important consideration for resellers who serve niche verticals. catering operations, cloud kitchens, franchise groups. where out-of-the-box software rarely fits perfectly.

Conclusion

The GloriaFood shutdown is disruptive, but it's also an opportunity. Resellers and agencies who approach this migration thoughtfully. who audit before they move, who stress-test before they launch, and most importantly, who think carefully about ownership versus renting. will come out of this transition stronger than before.

The businesses that will struggle are the ones who simply swap one SaaS for another and repeat the same mistake: building on a foundation they don't control. When you're managing dozens or hundreds of restaurant clients, that dependency is a liability you can't afford.

If you're a reseller looking for a migration path that actually makes business sense. one where you own the platform, set your own pricing, and aren't at the mercy of another shutdown announcement. a white-label, customizable GloriaFood alternative built for resellers is worth a serious look. The backend is ready. The features are configurable. And the unit economics, unlike another SaaS subscription, actually improve as you grow.
Migrate smart. Own your stack.

Connect with our team of experts at EnactOn and avoid mistakes that most resellers make.

GloriaFood Died. Here's What Nobody Tells You About Building a Real Replacement

Sneh — Fri, 08 May 2026 13:20:31 +0000

Everyone's talking about what to replace GloriaFood with. Nobody's talking about what actually makes these systems hard to build.

I get why. The surface looks simple. Restaurant has a menu, customer places an order, kitchen gets a ticket. You could sketch the basic flow in 20 minutes.

But the moment you're not building for one restaurant- the moment you're a reseller managing 50, 80, 100 clients on the same platform the whole thing changes shape.

Here's what I mean.

Multi-tenancy is where most clones quietly fail

The first real decision is how you isolate tenant data. One database per restaurant, shared database with separate schemas, or everything in one schema with a tenant_id column. Each option has a real trade-off.

Separate databases give you clean isolation but turn database migrations into a scripted nightmare across hundreds of instances. Shared schema with tenant IDs is easiest to manage until someone forgets a WHERE tenant_id = ? clause and Restaurant A can suddenly see Restaurant B's order history.

If you're targeting European markets, which GloriaFood served heavily ,you're also dealing with GDPR data residency on top of this. That eliminates the lazy option pretty fast.

Most clones ship with whatever was quickest to implement. It works in demos. It doesn't hold up when you're actually running a reseller business at scale.

The real-time problem nobody fixes until it's too late

This is where I've watched GloriaFood clones fall apart most visibly.

You build the platform, it looks great, a restaurant gets a test order, everything works. Then five restaurants hit peak lunch simultaneously. The kitchen display starts lagging. The driver app shows orders as "pending" that were accepted seven minutes ago. Customers are calling the restaurant to ask where their food is.

The culprit is almost always polling. The frontend keeps asking "any new orders?" on an interval instead of the server pushing updates the moment something changes.

The fix is event-driven order comes in, hits a message queue, triggers pushes to the kitchen display, the customer status page, the driver app, and the reseller monitoring panel all at once. Decoupled, so a spike in orders doesn't cascade into timeout failures across the whole system.

It's not complicated to design. It's just the kind of thing that gets skipped when you're building fast and the demo environment never shows you the problem.

Payments are never as done as they look

I've seen this pattern enough times that it's practically a rule: payment integration looks finished until the first real edge case.

The one that bites most often is the double-charge. Customer hits "Place Order" twice on a slow connection. No idempotency key on the payment request. Gateway processes both. Now you have an angry customer and a manual refund to handle.

The other common one is the unresolved payment state. Gateway call times out, you don't know if it succeeded or failed, and there's no reconciliation job checking on it. That order just sits there forever.

Neither of these show up in testing. Both show up in production within the first week.

What "production-tested" actually means

There's a version of this platform that works in a demo and a version that works on a busy Friday night across 80 restaurants. The difference isn't the feature list. It's the stuff you only discover by running it in real conditions.

The restaurant that updates their menu while a customer has items in their cart. The driver app reconnecting mid-delivery after a tunnel drops the signal. The payment webhook that arrives 40 minutes late because the gateway had a blip.

You can't unit test your way to knowing how your system handles these. You need real load, real edge cases, real markets.

This is the genuine argument for starting from a foundation that's already been through it not a locked-down product you can't modify, but a customizable core where the architectural problems are solved and your energy goes toward your market, your branding, and signing your first clients.

EnactOn Technologies built GloriaFood like platform specifically for resellers, validated it in real deployments in Switzerland and Germany, and has it ready to customize now — which matters because the post-GloriaFood demand window won't stay open forever.

If you're evaluating the build-vs-foundation question, they're worth talking to. The decision framework above is a reasonable way to structure that conversation.

The market gap GloriaFood left behind is real. The engineering problems to fill it are well-understood. What separates platforms that capture it from those that don't is whether the architecture holds up when things get messy.

Most clones find out it doesn't after they've already launched.

Built something in this space? Curious what multi-tenancy model you went with and whether you'd make the same call again.