DEV Community: Tech Analysis & Insights

Free AI Landing Page Builders: Which Ones Actually Let You Keep the Code

Tech Analysis & Insights — Tue, 10 Nov 2026 09:30:25 +0000

Most "free AI website builder" content is written for marketers. This one's for the people who get asked to evaluate these tools technically — because "it's free" and "it's actually usable for a real project" are very different questions once you look at export options, lock-in, and what happens to the backend once you go past a landing page.

After testing 15+ tools against the same brief, here's the breakdown that matters if you're the one deciding whether a no-code tool is a fine answer or just technical debt with a deadline.

Free publishing vs. free design — not the same thing

A lot of these tools let you build for free and then gate publishing behind a paywall. The ones that actually let you ship a live page on the free tier:

Tool	Free Publishing	Custom Domain (free)	Code Access
Wix AI	Yes	No	No export
Dorik AI	Yes	Yes	No export
Manus	Yes	Yes	Clean code output
Framer	Yes	No	No export
Mixo.io	Yes	No	No export
Base44	Yes	Yes	Full-stack, AI reasoning visible
Landingsite.ai	No (preview only)	No	No export

Only three tools — Dorik AI, Manus, and Base44 — let you attach your own domain without paying. That's the detail that actually matters for anything meant to outlive a demo.

Manus: the closest thing to "production-ready" on this list

Manus is Claude-powered and explicitly built around production-quality output rather than template assembly — clean layout logic, strong UX copy, and genuine code access, not just an export button bolted onto a visual builder. Free tier gives roughly 300 daily AI credits. If the landing page is meant to become part of a real codebase eventually, this is the one built for that path.

Base44: not a landing page tool, a full-stack generator

This is the one worth flagging specifically for engineers evaluating "AI website builders" as a category, because it's not really in that category. Base44 generates auth, a database, and Stripe integration alongside the marketing page, and shows its reasoning as it generates code — which is unusually transparent for this class of tool. Free tier ships with 25 AI credits, which burns fast on anything beyond a simple page, so budget for that before committing a team to it.

v0 by Vercel deserves a mention even though it's not a "landing page builder"

It's not on the primary comparison list because it's positioned differently — it generates React and Tailwind components rather than a hosted site — but for teams already in a modern frontend stack, it's a more natural fit than any no-code tool here, since the output drops directly into an existing codebase instead of living on a vendor's platform.

What this means practically

If someone on your team says "let's just use an AI website builder" for something that's supposed to grow into a real product, the free-tier code-access column is the one to push back on. Dorik AI and Manus are the two genuinely defensible choices if there's any chance this outlives a landing page — everything else on the free-tier list is fine for what it is, but it's a dead end the moment you need to own the code.

Full comparison of all 7 tools that passed the free-publishing bar, including the ones evaluated and rejected: Varmeta's writeup on the best free AI landing page generators. Condensed comparison tables (no narrative) are also up as a GitHub reference repo.

Onboarding Instrumentation: What to Actually Log Before You Redesign the Flow

Tech Analysis & Insights — Mon, 02 Nov 2026 08:40:41 +0000

Most "redesign the onboarding" tickets start with opinions and end with a flow that's shorter but unmeasured, nobody can say if the new version converts better because nobody logged the old one in a way that answers the question. Before touching copy or screen order, the instrumentation needs to exist. Here's the minimum set that makes a before/after comparison possible.

Define "first value" as an analytics event, not a UI state

"Onboarding complete" is a UI state, it fires when the last screen closes, whether or not the user got anything out of it. First value is different: it's the first time the product actually does something useful for this specific user. A photo app's first value event is library_cleaned, not onboarding_dismissed. A budgeting app's is transaction_categorized, not account_created. If you can't name the event, you haven't found it yet, go compare retained users against churned users from the first few days and find the action that separates them.

The three metrics that matter, and why completion rate isn't one of them

Activation rate - percent of new users firing the first-value event within a defined window (7 days is common). This is the real top-line number.
Time to value - median time from first open to first-value event. Read it alongside activation rate; a shorter median among a smaller activated cohort is a trap, not a win.
Step-level drop-off - where people actually leave the flow, step by step. This is what tells you whether a step is disposable or load-bearing.

Completion rate (did they finish the flow) tells you almost nothing on its own. A 90% completion rate with a 40% activation rate means your flow is good at getting people through screens and bad at getting them to the thing that matters.

Sort every step with one question, logged against real data

Keep: would the product be unsafe, non-compliant, or non-functional without this step? -> identity verification, required consent, payment auth.
Defer: useful later, not required for first value? -> profile photo, notification prefs, invites.
Remove: serves the team more than the user? -> unused feature tours, duplicate confirmations, long surveys.

This only works if you can see step-level drop-off per cohort, don't sort from a whiteboard, sort from the funnel.

Permission requests: timing is an engineering decision, not a copy decision

Request permissions at the moment they're needed, not in a batch during onboarding, camera access when the user starts their first scan, notification permission after they've seen a reason to want alerts, not before. This isn't just better UX, it measurably changes grant rates, because the system prompt appears with context instead of as an abstract ask. If your onboarding flow currently front-loads permission requests, that's usually an easy first fix with a clear before/after in your grant-rate logs.

Deferred registration needs a technical answer to "what happens to this session if they bounce?"

Letting users try the product before creating an account (Duolingo's well-known move, worth roughly a 20% DAU lift in an early internal test, per the company's own account) means you need anonymous-session state that can later merge into a real account without data loss. If your backend can't cleanly convert an anonymous session into an authenticated one, deferred registration will cost you more in support tickets and lost progress than it gains in completion.

Regulated flows: the identity-check step isn't a UX problem, don't instrument it like one

If you're in fintech or insurance, step-level drop-off at an identity-verification gate will look terrible compared to everything else in the funnel, and that's often expected, not a bug. Signicat's 2022 survey across 14 European countries put financial-app abandonment at 68% in the prior year, with 21% citing excessive personal-data requests specifically. The fix there isn't removing the step, it's reducing abandonment around it: save-and-resume state, clear in-flow explanations of why each field is required, and collecting only what's legally mandated at account creation rather than front-loading optional fields into the same gate.

Varmeta's longer write-up on separating load-bearing onboarding steps from the ones that just add screens covers the product-and-design side of this in more depth. The condensed table version is on GitHub if you want the keep/defer/remove criteria and cited numbers without the narrative, closer to something you'd paste into an internal doc.

Discussion: if you've instrumented an onboarding flow properly, what ended up being your actual first-value event, was it the one the product team originally assumed?

The Hard Part of a Web2App Funnel Isn't the Paywall. It's the Handoff.

Tech Analysis & Insights — Wed, 28 Oct 2026 05:05:28 +0000

Everyone building a web2app funnel (quiz → paywall → web checkout → open the app) talks about conversion rate on the quiz and paywall. Almost nobody talks about the step right after checkout, where the app has to recognize a user who just paid on a completely different surface - and that's the step that actually determines whether the funnel was worth building.

Why this is the hard part

The web checkout and the native app are, from an engineering standpoint, two different clients with two different identity contexts. The web session knows an email, a payment method, and whatever the quiz collected. The app, on first open, knows nothing. Bridging that gap with a deep link or a login screen sounds trivial until you actually have to handle:

The app isn't installed yet. A deep link to an uninstalled app has to survive a trip through the App Store and still carry the purchase context on first open - this is what deferred deep linking exists to solve, and it's the single most common place these funnels silently lose paying users.
The user already has the app installed under a different account, or isn't logged in at all when the deep link fires.
Timing. Webhook-driven entitlement sync (payment provider → your backend → app) can lag behind the user opening the app, so the app has to handle "payment confirmed, entitlement not synced yet" as a real state, not an edge case.
Platform identity vs. payment identity. The email used at checkout and the identifier the app uses internally (device ID, social login, phone number) aren't guaranteed to be the same thing, and reconciling them after the fact is a support ticket waiting to happen.

Why this matters more than it looks like it should

A person who already paid has a very low tolerance for friction. If the app can't recognize them cleanly on first open, you've converted them on the web and then lost them at literally the last step - and because they already paid, that failure mode generates refund requests and support load, not just a bounced funnel metric.

The fee context driving teams to build this anyway

The reason this pattern is worth the engineering investment at all: Apple's standard in-app commission is 30% (15% for developers under the Small Business Program's $1M threshold), and in the US specifically, link-out purchases are currently at 0% commission because of an active contempt order against Apple - though that's mid-litigation, not settled. Apple has proposed 15% / 10% / 5% rates depending on app type, which Epic is contesting, and a Ninth Circuit ruling from December 2025 left room for the district court to set an actual number. Japan already has a settled rate: 15%, or 10% for qualifying developers and renewal-year subscriptions, announced in December 2025 - with an explicit no-refunds policy on web-linked purchases, which pushes even more of the handoff and support burden onto the publisher's own stack.

RevenueCat's 2026 benchmark (115,000+ apps) shows this pattern concentrating among more sophisticated teams: 41% of top-revenue-tier apps report some web revenue, versus 1.3% in the bottom tier. That gap is plausibly as much about handoff engineering quality as it is about marketing spend - a team that can't build a clean account-matching flow is going to see worse numbers from the same funnel design.

What a reasonably solid handoff actually requires

Deferred deep linking that survives the install step and restores purchase context on first app open, not just "open the app to the right screen."
A webhook-driven entitlement check in the app that explicitly handles "payment succeeded, not yet synced" as a loading/pending state, not a silent failure.
A reconciliation path for when the checkout email doesn't match an existing app account - merge, prompt, or create, decided deliberately rather than left as a null case.
Logging on every step of the handoff (deep link fired, app opened, entitlement checked, entitlement confirmed) so a support ticket about "I paid but the app won't unlock" can actually be debugged instead of guessed at.

Varmeta's full writeup on web2app funnels covers the funnel stages, the fee rules by market, and when the model is worth building in the first place.

Discussion: if you've shipped one of these, what actually broke the handoff in practice - the deep link surviving install, the identity match, or the entitlement sync timing?

Before You Build on an AI API, Check Which List the Vendor Is On

Tech Analysis & Insights — Mon, 26 Oct 2026 09:23:32 +0000

Every "top AI companies" ranking you'll see this year is really answering one of two very different questions, and most of them don't tell you which one.

Question one: who raised the most money? Question two: who has the research depth to keep shipping genuinely new capability instead of fast-following whoever's ahead? I pulled both rankings for the same 13+ companies (funding data + research-team profiles) and the overlap is smaller than you'd expect — which matters a lot more than it sounds if you're picking a model provider or AI infra vendor to build production systems on.

Funding leaders (top 7 by funding score)

Rank	Company	Funding Score	Total Funding
1	xAI	100	$42.73B
2	Databricks	98.7	$27.61B
3	OpenAI	97.9	$63.9B
4	Anthropic	94.2	$37.3B
5–7	Lovable, Decagon, Mercor	92.7–89.5	smaller, narrow-scope bets

Research leaders (top 5 by team strength)

Rank	Company	Employees	Research Focus
1	Google AI	~286,696	LLMs, multimodal, CV
2	Meta AI	~10,000	LLMs, CV, RL, multimodal (open models)
3	Nvidia AI	~36,000	GPU architecture, accelerated computing
4	IBM AI	275,000	Enterprise AI, applied research, ethics
5	Microsoft AI	2,260	Cloud AI, NLP, CV (research-first since 2024)

Only five companies clear both bars

OpenAI, Anthropic, Google AI, Nvidia AI, Microsoft AI. That's it. Everyone else is strong on exactly one axis — Databricks and xAI raised enormous rounds without placing in the research-depth top 5; Lovable, Decagon, and Mercor are well-funded but intentionally narrow (no-code app building, support automation, hiring, respectively), not trying to compete on frontier research at all.

Why this is an engineering decision, not just a market-watching one

If you're picking an API or model provider to build production infrastructure on top of, funding and research depth answer two different risk questions:

Funding tells you survivability. Will this vendor still be operating — and still investing in the product — in three years? A company burning cash with no runway is a migration project waiting to happen.
Research depth tells you whether what they ship next is actually new. A vendor with a thin research bench tends to ship incremental catch-up features. A vendor with deep research output is more likely to be the one setting direction that competitors then copy — which matters if you're betting your architecture on their roadmap, not just their current API surface.

For a narrow, well-defined point integration, funding stability might be the only thing that matters. For anything you're treating as core infrastructure — the model layer underneath an agent system, a RAG pipeline, anything hard to rip out later — research depth is the signal that tells you whether you're building on bedrock or on someone else's current lead.

Full ranking data, methodology, and all 13+ companies covered: Varmeta's breakdown. Condensed tables-only version on GitHub.

Discussion: when you're evaluating a model/API vendor for something you can't easily swap out later, do you actually weight research depth — or does funding/stability end up deciding it in practice?

Claude Fable 5.1 vs GPT-6 Astra: The Numbers That Actually Matter for Engineering Teams

Tech Analysis & Insights — Fri, 23 Oct 2026 03:56:56 +0000

Two frontier models shipped within 48 hours of each other in September 2026: Anthropic's Claude Fable 5.1 on September 1st, OpenAI's GPT-6 Astra on September 3rd. Same context-window class, same headline pricing, both pitched as agentic workhorses. On a spec sheet they look almost identical.

They are not identical once you start building against them.

The spec sheet says they're twins

Pull up the numbers side by side and the overlap is suspicious:

	Claude Fable 5.1	GPT-6 Astra
Context window	1,000,000 tokens	1,050,000 tokens
Max output	128,000 tokens	128,000 tokens
Input / output price	$10 / $50 per 1M tokens	$10 / $50 per 1M tokens

If you stopped reading here you'd flip a coin. Don't stop here.

Where the actual bill diverges: cache reads

Nobody runs a single prompt through an agentic workload. You run the same system prompt, the same codebase context, the same tool definitions, over and over, every turn of every task. That's what prompt caching exists for, and it's where the two providers quietly stopped matching each other.

Fable 5.1 cut its cache-read price 75% from Fable 5, down to $0.25 per million tokens. Astra charges $1.00 per million for the same thing. On a single request that's noise. On an agentic loop it compounds fast:

def monthly_cache_cost(cache_read_price_per_million, turns_per_day, cached_tokens_per_turn, days=30):
    tokens_per_month = turns_per_day * cached_tokens_per_turn * days
    return (tokens_per_month / 1_000_000) * cache_read_price_per_million

# A coding agent re-reading a 50k-token repo context, 200 turns/day
fable_cost = monthly_cache_cost(0.25, 200, 50_000)
astra_cost = monthly_cache_cost(1.00, 200, 50_000)

print(f"Fable 5.1: ${fable_cost:,.2f}/mo")
print(f"GPT-6 Astra: ${astra_cost:,.2f}/mo")
# Fable 5.1: $75.00/mo
# GPT-6 Astra: $300.00/mo

Scale that to a team running dozens of agent sessions in parallel against a large codebase, and the "identical pricing" story falls apart. This is specifically why Anthropic is positioning Fable 5.1 for long-horizon, cache-heavy work rather than one-shot queries.

The architecture philosophies are actually opposite

This is the part that doesn't show up in any pricing table.

Anthropic ships one public model (Fable 5.1) with classifiers that route anything touching cybersecurity, bio/chem, or model distillation to the weaker Claude Opus instead. The capable version of those flagged capabilities lives in Mythos 5.1, gated behind a vetted-access program.

OpenAI took the opposite path. Astra itself is the model that meets their "Critical" cybersecurity threshold under its own Preparedness Framework, meaning it can plausibly find and exploit unknown vulnerabilities without hand-holding. They didn't build a separate weaker model and route around it. They built the capable model and restricted the public release of it directly, with full capability going to vetted testers through Daybreak Access.

Same end state (restricted public access to the sharpest edges), completely different engineering decision about where the restriction lives.

What this actually means for picking one

Ignore the marketing and look at what each model is optimized for:

Long-running agentic work against a large, mostly-static codebase (think: autonomous refactors, Web3 contract audits, multi-hour coding sessions): Fable 5.1's cache economics win outright.
Anything that needs to browse live pages, operate a real browser, or drive a UI (agentic commerce, dynamic market research, computer-use workflows): Astra's stated strengths are built for exactly this.
Security research tooling: neither public API covers this well. You're going through a vetted-access program either way (Mythos 5.1 or Daybreak Access), so this isn't actually a deciding factor for most teams.

The honest answer for most engineering orgs is both, not one. Route the cache-heavy, long-horizon coding work to Fable 5.1 and the browsing/computer-use work to Astra, instead of trying to pick a single default model for every agent in your stack.

I wrote up the full comparison, including the complete benchmark numbers and safety framework details, on the Varmeta blog, and there's a stripped-down reference version with just the tables and no narrative on GitHub if that's more useful mid-architecture-review.

Which one is actually in production for you right now, and did the cache pricing difference factor into the decision at all? Curious how many teams caught this before shipping versus after the first invoice.

How is your team actually handling "memory" for AI agents right now?

Tech Analysis & Insights — Wed, 21 Oct 2026 14:00:00 +0000

Every GraphRAG / agent-memory conversation I've had this month ends in a different answer — a graph database, a vector store, or just a bigger context window and letting the model sort it out.

None of the teams I've talked to seem fully happy with what they're running.

What's actually in production for you right now, and what was the first thing that broke once you went past a demo?

Why I'd Think Twice Before Picking Neo4j for a GraphRAG Stack in 2026

Tech Analysis & Insights — Wed, 21 Oct 2026 12:00:00 +0000

If you're sketching out the data layer for an agentic AI app right now, there's a good chance Neo4j is the first name that comes to mind. It's the default answer, the one everybody already knows from the "graph database" search results. But default answers are worth questioning, especially when the workload you're building for didn't exist when the tool did.

Neo4j was built for a world of dashboards and analysts running Cypher queries against a system of record - fraud graphs, recommendation engines, IT topology maps. Rock solid for that. What it wasn't built for is an LLM agent that needs to pull a multi-hop context window out of a graph in single-digit milliseconds, fused with a vector similarity search, a few hundred times a minute.

That mismatch is why "Neo4j alternative" has quietly become one of the more searched phrases in AI infra circles this year. Here's what's actually driving it, and the five engines worth putting on your shortlist.

The part that doesn't show up in the pricing page

Cypher is genuinely pleasant to write - the ASCII-art pattern matching makes multi-hop traversals readable in a way SQL joins never manage:

MATCH (agent:Memory)-[:RECALLS]->(fact:Fact)-[:RELATES_TO]->(entity:Entity)
WHERE agent.session = $sessionId
RETURN fact, entity
ORDER BY fact.relevance DESC
LIMIT 10

The problem isn't the query language. It's everything around it. Most teams shipping GraphRAG or agent-memory systems end up running Neo4j for the graph, a vector store like Milvus for embeddings, and a document store for raw context - three systems, three failure modes, one very tired platform engineer maintaining the ETL between them. Add Neo4j's enterprise licensing once you need real horizontal scale, and the "it's free and open source" pitch stops holding up.

None of that is a knock on Neo4j as a product. It's a mismatch between a database designed for stable, structured relationship data and a workload defined by ephemeral, high-velocity, hybrid lookups. Different problem, different tool.

Five engines actually built for this workload

ArcadeDB is the closest thing to a drop-in migration path. Apache 2.0, multi-model (graph + document + vector in one engine), speaks Cypher, SQL, and Gremlin, and ships a built-in MCP server so an agent can query it directly without a middleware layer. Smaller community than Neo4j, but the memory footprint is noticeably lighter.

FalkorDB is the one to reach for if latency is the whole point. It's an in-memory graph database built on Redis and GraphBLAS sparse-matrix math, and the published benchmarks show 10x–100x faster multi-hop traversals than Neo4j. That's the kind of number that matters when a chatbot's "memory lookup" is sitting in the critical path of every response.

TigerGraph is for teams past the "can we fit this in RAM" stage - billions of edges, distributed-first architecture, a Turing-complete query language (GSQL) that lets you run graph algorithms inline instead of round-tripping data to your application layer. Steeper learning curve, but it handles hybrid graph-vector queries in a single pass, which matters a lot if hallucination reduction is part of your retrieval story.

ArangoDB takes the opposite approach from FalkorDB's one-job-done-well philosophy: one engine, four models (graph, document, vector, search), so your knowledge graph and your raw source documents live in the same place instead of two systems you have to keep in sync. Benchmarks put it at roughly 8x faster than Neo4j on multi-model workloads, though pure graph traversal isn't quite as fast as a graph-only engine like FalkorDB.

Memgraph is for anyone who loves Cypher but not the JVM. It's a C++ in-memory graph database that's Bolt-protocol compatible with Neo4j - genuinely close to a drop-in swap — built for real-time streaming workloads and plays well with Kafka pipelines.

	ArcadeDB	FalkorDB	TigerGraph	ArangoDB	Memgraph
Model	Multi-model	Graph (Redis)	Native graph	Multi-model	Native graph
Query language	Cypher / SQL / Gremlin	Cypher	GSQL	AQL	Cypher
Best fit	Multi-model AI apps	Low-latency RAG	Massive-scale enterprise	Unified context store	Real-time streaming
Open source	Yes (Apache 2.0)	Source-available	No (limited free tier)	Yes (community ed.)	Yes

Picking one without overthinking it

The honest framework is simpler than it looks:

Already running Neo4j at scale with a working ETL pipeline? Don't rip it out for the sake of it — the switching cost is real.
Chasing millisecond agent-memory lookups? FalkorDB or Memgraph.
Tired of stitching together a graph store, a vector store, and a document store? ArcadeDB or ArangoDB.
Operating at billions-of-edges, enterprise-scale? TigerGraph.

I put together the longer version of this comparison - full benchmark context, pros and cons for each engine, and the reasoning behind the pricing/latency tradeoffs - over on the Varmeta blog, and a stripped-down quick-reference table (no narrative, just the decision matrix) on GitHub if you just want to skim it mid-architecture-review.

Curious what others are running in production for agent memory right now - still Neo4j, or has your team already jumped to one of these? Drop it in the comments, especially if you've hit a wall any of these didn't warn you about.