DEV Community: DevToolsPicks

Tauri vs Electron for Indie Hackers in 2026 (Honest Comparison)

DevToolsPicks — Fri, 03 Jul 2026 04:15:09 +0000

Every few months someone declares Electron dead, points at Tauri's tiny bundles, and moves on. The truth is more useful than the headline. Both frameworks are shipping real software at scale in 2026, and the right choice comes down to one tradeoff that most hot takes skip past.

Here's the short version. For a new desktop app, start with Tauri. The bundle size, memory, security, and mobile wins are real and measurable. Reach for Electron when your UI must render identically everywhere, when you lean hard on the Node ecosystem, or when your team is JavaScript-only with no room to touch Rust. And if you already have a working Electron app, the honest answer is usually to stay put, because migrating is closer to a rewrite than a refactor.

Let me break down why, with real numbers.

Quick verdict

Tool	Best for	Bundle size	Idle memory	Rating
Tauri	New, lean apps and mobile reach	2 to 10 MB	~30 to 50 MB	4.5/5
Electron	Complex, render-heavy apps	80 to 200 MB	~120 to 400 MB	4/5

Tauri: the lightweight modern default

Tauri flipped the desktop model. Instead of shipping a whole browser with your app, it uses the WebView the operating system already has (WebView2 on Windows, WKWebView on macOS, WebKitGTK on Linux) and runs your backend logic in Rust. Version 2, stable since late 2024 and now on the 2.11 line, is the release that turned Tauri from a promising challenger into a real platform decision. Momentum backs that up: Tauri's GitHub repositories have grown around 55% year over year while Electron's growth has plateaued, and a 2025 Stack Overflow survey found 72% of desktop developers had considered switching frameworks in the past year, mostly over performance and bundle size.

The numbers are the headline, and the gap is enormous. Tauri apps typically ship at 2 to 10 MB, against Electron's 80 to 200 MB. Idle memory sits around 30 to 50 MB, roughly 50 to 75% lower than Electron. Startup is consistently under half a second, where Electron takes one to two. On a cheap laptop running six apps at once, that's the difference between a machine that breathes and one that swaps to disk.

The other big shift in v2 is mobile. Tauri now targets iOS and Android from the same codebase, which Electron cannot do at all. Security is also better by default: Tauri uses a capability-based permission system where everything starts disabled and you opt into what you need, rather than Electron's model where you harden the renderer yourself. You keep your web frontend too, React, Vue, Svelte, or vanilla, so the UI code barely changes.

The honest cons: initial builds are slower because of Rust compilation, adding maybe 20 to 25 seconds to a cold build. Because it uses each platform's native WebView, rendering can differ slightly across operating systems, and WebKitGTK on Linux has known performance quirks on some distributions. Deep native work means writing Rust, and the ecosystem, while growing fast, is thinner than Electron's. The auto-updater downloads a full binary rather than a diff, though for a 5 MB app that hardly matters.

Who should not use Tauri: teams that need pixel-identical rendering on every platform, anyone with zero capacity to touch Rust for native features, or apps that depend on a specific Node-only library with no Rust equivalent.

Electron: the mature, proven heavyweight

Electron is the established standard, and it earned that position. It bundles Chromium and Node.js with every app, which is exactly why it's heavy and exactly why it's reliable. Every user runs the same browser engine regardless of their OS, so your UI renders identically everywhere. For a rendering-heavy app where consistency is non-negotiable, that's a genuine advantage, not just bloat. The 2026 releases (Electron 34.x, on Chromium 132 and Node 22) trimmed baseline memory a little, but the core architecture is unchanged.

The ecosystem is the real moat. Electron has a mature, battle-tested toolchain: electron-updater handles differential updates, staged rollouts, and code signing, including the macOS notarization and Windows signing that are mandatory for user trust in 2026. There's a documented solution for nearly every edge case, and the talent pool is deep because it's all JavaScript. VS Code, Slack, Discord, Figma, and 1Password all run on it. That's not an accident, it's what happens when a complex product needs proven distribution. Since the main process runs on Node, your whole team can work across frontend and backend without learning a second language. If you want to understand that runtime layer better, I covered it in Bun vs Node vs Deno.

The honest cons: the weight is real and structural. That bundled Chromium adds 80 to 120 MB before your own code, and each window you open spawns its own renderer process, effectively a mini-Chromium with the memory bill to match. Idle memory routinely lands in the hundreds of megabytes. Security is opt-in rather than default, so you have to correctly configure context isolation, disable Node integration in renderers, use preload scripts, and set a content security policy. Get that wrong and you've shipped a vulnerability.

Who should not use Electron: teams building lean utilities or menu-bar tools where install size and memory are product requirements, anyone who needs mobile from the same codebase, or security-sensitive apps that benefit from a smaller attack surface.

How do they compare head to head?

Five dimensions decide it.

Size and memory. Tauri wins decisively. Bundles are roughly 10 to 25x smaller and memory runs 50 to 75% lower. For consumer apps, utilities, and anything users keep open all day, that's a real user-experience win, smaller downloads, cooler laptops, longer battery life.

Rendering consistency. Electron wins. Because it ships its own Chromium, your app looks identical on every platform. Tauri uses each OS's native WebView, so CSS and fonts can render slightly differently, and you'll spend more time testing across platforms.

Ecosystem and distribution. Electron wins. The auto-update, signing, and packaging story is more mature, and there's a library or Stack Overflow answer for almost everything. Tauri's tooling is good and improving, but you'll hit more rough edges.

Language and team fit. Depends on your team. Electron is JavaScript end to end, so any web dev can own the whole stack. Tauri keeps the frontend in JavaScript but puts native logic in Rust, which is a real onboarding cost if nobody knows it.

Mobile reach. Tauri wins by default, because Electron doesn't compete here at all. If one codebase across desktop and mobile matters to you, the decision is basically made.

Build speed. Electron wins this one. Its JavaScript toolchain compiles fast, often packaging in around 15 seconds, while Tauri's Rust step adds roughly 20 to 25 seconds to a cold build. Later builds are quicker thanks to caching, but in a rapid edit-and-rebuild cycle that initial compile is a real, if minor, tax on your day.

Here's the decision in one view:

Final recommendation

For a new desktop app in 2026, start with Tauri. It produces dramatically smaller, lighter, faster apps, ships with better security defaults, and reaches mobile from the same codebase. For most indie hacker projects, developer utilities, menu-bar tools, local-first apps, lightweight editors, that profile fits perfectly, and the Rust requirement stays small because most of your code lives in the frontend.

Choose Electron when your app is genuinely complex and render-heavy, when identical cross-platform rendering is a hard requirement, when you depend on its mature update and signing pipeline, or when your team is JavaScript-only and Rust is off the table. It's the safer pick for a large web-heavy product, and it is absolutely not obsolete.

And if you already ship an Electron app that works and nobody is complaining about its size, leave it alone. The migration cost almost never beats the pain it removes. Pick based on what your users actually feel, not on a benchmark chart.

Shipped a desktop app on one of these and learned something the benchmarks miss? Tell me on Twitter @devtoolpicks.

Best Auth0 Alternatives for Indie Hackers in 2026 (Honest Picks)

DevToolsPicks — Thu, 02 Jul 2026 04:05:10 +0000

Auth0 is excellent technology with a pricing model that punishes you for succeeding. The free tier looks generous at 25,000 monthly active users, but the moment you need real production features or cross a usage tier, the bill moves fast.

Here's the part that catches founders. The per-user overage rate is $0.07, raised 300% from the old rate, so a B2C app with 50,000 active users on the Essentials plan lands around $3,500 a month, not the $35 sticker. One company reported its bill jumping from $240 to $3,729 a month after growing users just 1.67x. B2B plans cap enterprise SSO connections too, so your sixth enterprise customer can force you into a custom contract that often starts in five figures. Auth0 is owned by Okta now, and the pricing reflects an enterprise mindset, not an indie one.

So here's the short version. For most indie hackers, switch to Clerk. If you're already on Supabase, use Supabase Auth. If you want to own your auth and pay nothing, self-host Better Auth. Below is the honest breakdown of all five, with real pricing and who each one is wrong for.

Quick verdict

Tool	Best for	Free tier	Paid from	Rating
Clerk	Best React/Next.js experience	50,000 MRU	$25/mo	4.5/5
Supabase Auth	Teams already on Supabase	50,000 MAU	$25/mo	4/5
Better Auth	Owning your auth, no per-user fees	Free, open source	Self-host cost	4.5/5
Kinde	Auth plus billing and feature flags	10,500 MAU	$25/mo	4/5
WorkOS	The most generous free tier	1,000,000 MAU	Per connection	4/5

Clerk: the best developer experience

Clerk is what most React and Next.js teams move to when they leave Auth0, and it's earned that. The pre-built components, <SignIn />, <UserButton />, <OrganizationSwitcher />, plus hooks like useUser and useAuth, let you ship production auth in an afternoon instead of a week. Organization and multi-tenancy support is built in, not gated behind an enterprise tier.

The pricing got dramatically better in early 2026. The free tier now covers 50,000 monthly retained users, up from 10,000. Clerk bills on retained users, not raw signups, so anyone who signs up and never returns within 24 hours doesn't count toward your bill. Above the free tier, Pro is $25 a month and overages run $0.02 per retained user. At 100,000 users that's roughly $1,025 a month, which sounds steep until you price the same scale on Auth0.

The honest cons: Clerk is React-first, so if you're not in the React or Next.js ecosystem, the experience is noticeably less polished. Enterprise SSO connections are now metered on Pro rather than unlimited, so B2B apps selling to many enterprises will see that line item grow. And SMS for MFA passes through Twilio costs as a separate charge. I compared it directly against the incumbent in Clerk vs Auth0 vs Supabase Auth.

Who should not use Clerk: teams outside the React ecosystem, or very low-ARPU consumer apps with huge free user counts where per-user billing eventually bites.

Supabase Auth: free if you're already on Supabase

If your backend is already Supabase, you have auth built in and you're probably underusing it. Supabase Auth handles email and password, magic links, phone auth, and social providers, and it ties directly into Postgres row-level security, so your access rules live in the database next to your data.

The cost story is the best part. Auth is bundled into the Supabase free plan, which covers 50,000 monthly active users alongside your database, storage, and edge functions. The Pro plan is $25 a month and includes 100,000 MAUs, with overages at just $0.00325 per user after that. That's roughly one twentieth of Auth0's overage rate. For a SaaS already paying for Supabase, the marginal cost of auth is close to nothing. If you're weighing the broader backend choice, I broke it down in Convex vs Supabase vs Firebase.

The honest cons: this only makes sense if you're committed to Supabase. The free tier pauses your project after one week of inactivity, which is a dealbreaker for anything user-facing on the free plan. And the components are less polished than Clerk's, so you'll build more of the UI yourself. It's also open source and self-hostable via Docker if you want full control.

Who should not use Supabase Auth: teams not using Supabase for their backend, or anyone who wants drop-in UI components rather than building auth screens.

Better Auth: own your auth, pay nothing per user

Better Auth is the open-source pick, and it's become the default in 2026. It's TypeScript-first, framework-agnostic, and runs entirely in your own stack. There are no per-user fees, ever, because you host it yourself. It's grown fast enough that Auth.js, the long-time open-source standard, is now in maintenance mode under the Better Auth umbrella.

What you get is full control. Sessions, accounts, and user data live in your database, you own every line of the flow, and there's no vendor pricing curve to outrun. For a cost-sensitive indie hacker who expects to scale users faster than revenue, that's a real edge. It supports the things you actually need: email and password, social login, two-factor, organizations, and a plugin system for the rest. I compared it against the hosted options in Better Auth vs Clerk vs Auth.js.

The honest cons: you run it. That means owning the database, session storage, email delivery, and security updates yourself. There's no hosted dashboard, no managed uptime, and no support line when something breaks at 2am. It's more code than a drop-in service, and the responsibility is yours. The freedom from per-user fees comes with the cost of operational ownership.

Who should not use Better Auth: teams with no appetite for running and securing their own auth infrastructure, or anyone who values a managed dashboard and support over zero per-user cost.

Kinde: auth, billing, and feature flags in one

Kinde takes a different angle. Instead of just auth, it bundles authentication, subscription billing, and feature flags into one platform. For an indie hacker building a SaaS from scratch, that's three tools you'd otherwise stitch together, available behind a single integration.

The free tier covers 10,500 monthly active users with no credit card, and paid plans start at $25 a month. A nice touch: paying customers on your own plans don't count toward your MAU allowance, so you're not billed twice for the same user. Organizations, RBAC, MFA, passkeys, and social login are all included rather than gated, and setup genuinely takes minutes. For B2B SaaS that needs orgs and roles from day one, the price-to-feature ratio is the best on this list.

The honest cons: Kinde launched in 2023, so it's the youngest commercial platform here. The catalog of edge-case integrations and the depth of community support are still building compared to Auth0 or Clerk. For a mission-critical deployment, check the support SLA before committing. The all-in-one approach is great until you want best-in-class billing specifically, where a dedicated tool may go deeper.

Who should not use Kinde: teams that need a long track record and a deep integration ecosystem, or those who already have billing and feature flags solved and only want auth.

WorkOS: the most generous free tier

WorkOS built its name on enterprise SSO, but its AuthKit product turned it into a full user-management platform, and the free tier is unmatched. AuthKit is free for up to 1,000,000 monthly active users, including social login, MFA, RBAC, and passkeys. For an indie hacker who expects a large free user base, that ceiling removes upgrade anxiety entirely.

The model is modular. User management is free to that 1M ceiling, then $2,500 per additional million users. Enterprise SSO is priced per connection, which is the real variable: it's cheap when you have a handful of enterprise customers and expensive when you have dozens. That structure is ideal if you plan to charge enterprise customers a premium for SSO, since the cost maps directly to revenue.

The honest cons: the per-connection SSO pricing can balloon for SSO-heavy B2B businesses, roughly $6,600 a month at 75 connections, so model your enterprise customer count before committing. WorkOS is also more enterprise-flavored than Clerk or Kinde, so the developer experience is clean but less consumer-app focused.

Who should not use WorkOS: small B2C apps that will never need enterprise SSO, where the enterprise orientation is overkill, or SSO-heavy businesses that haven't priced the per-connection cost.

How do you choose?

It comes down to where you are and what you're building.

Want the fastest, most polished path and you're on React? Pick Clerk. It's the safe default for most indie hackers and the one I'd reach for first.

Already running Supabase? Use Supabase Auth. The marginal cost is near zero and the database integration is genuinely useful.

Cost-sensitive or privacy-minded, and comfortable running infrastructure? Self-host Better Auth and never pay per user again.

Building a SaaS that needs billing and feature flags too? Kinde gives you all three in one integration at a fair price. And if you expect a massive free user base or sell SSO to enterprises, WorkOS and its 1M free MAU ceiling is hard to argue with.

Final recommendation

For most indie hackers leaving Auth0, switch to Clerk. The free tier is generous at 50,000 retained users, the React experience is the best in the category, and the pricing is predictable as you grow.

If you're already on Supabase, there's no reason to add a separate auth vendor, use Supabase Auth. If you want to own your stack and eliminate per-user fees, self-host Better Auth. Choose Kinde if you want auth, billing, and feature flags bundled, and WorkOS if a huge free tier or enterprise SSO sales motion is your priority.

The one thing not to do is stay on Auth0 by default while it quietly taxes your growth. Every option here is cheaper as you scale, and migrating is usually a weekend job thanks to bcrypt hash imports. Pick the one that matches your stack and move before the next tier jump.

Switched off Auth0 to something not on this list? Tell me what you picked on Twitter @devtoolpicks.

Claude Sonnet 5 Review: Near-Opus Quality at a Sonnet Price

DevToolsPicks — Wed, 01 Jul 2026 06:10:58 +0000

Anthropic shipped Claude Sonnet 5 on June 30, and unlike the last couple of model launches everyone got excited about, you can actually use this one right now. No waitlist, no preview gate, no "coming weeks." It's the default model on Free and Pro, it's in Claude Code, and developers can call claude-sonnet-5 on the API today.

The pitch is simple and, for once, mostly true: near-Opus 4.8 quality at a Sonnet price. Sonnet 5 gets close to Opus 4.8 on agentic coding and computer use, slightly beats it on knowledge work, and costs a fraction of what Opus does to run. For a solo dev or a small SaaS team watching an API bill, that's the interesting part, not the benchmark bragging.

Here's the short version. If you're on Sonnet 4.6, switch. If you're paying for Opus 4.8 on work that doesn't truly need it, Sonnet 5 will cut your bill hard. If you're doing the genuinely hard stuff, gnarly reasoning, high-stakes accuracy, stay on Opus 4.8. Below is the real pricing, the actual monthly cost math, and the honest benchmark picture.

What's actually new in Sonnet 5?

Anthropic is calling this "the most agentic Sonnet model yet," and for once the marketing lines up with what testers are reporting. The headline behavioral change is autonomy: Sonnet 5 finishes multi-step tasks that earlier Sonnets would stall halfway through, and it checks its own output without being told to. A Zapier engineer described handing it a two-part job, update Salesforce tiers then send a launch announcement, and watching it run end to end where the old model would have stopped.

On paper, the gains over Sonnet 4.6 are real across reasoning, tool use, coding, and knowledge work. It ships with a 1M token context window and up to 128,000 output tokens. It also hallucinates less, is less sycophantic, and refuses malicious requests more consistently than Sonnet 4.6, which matters if you're running it as an agent with access to real systems.

One thing to keep honest: most of the benchmark numbers so far come from Anthropic itself. They're plausible and they match early tester reports, but I'd treat the exact figures as directional until independent evals land. That's true of every model launch, not just this one.

How much does Claude Sonnet 5 cost?

This is where it gets good for indie hackers. Sonnet 5 launched with introductory pricing of $2 per million input tokens and $10 per million output tokens, running through August 31, 2026. After that, it moves to $3 per million input and $15 per million output.

That later rate is exactly what Sonnet 4.6 charged. So the way to read this: during the intro window you get a real discount, and after it, you get a much better model at the same price you were already paying.

Here's how that plays out on a realistic workload. Take a solo SaaS running about 1,000 API calls a day at 1,500 input and 800 output tokens each, roughly 45 million input and 24 million output tokens a month.

Model	Input rate	Output rate	Monthly cost
Claude Sonnet 5 (intro)	$2/M	$10/M	~$330
Claude Sonnet 5 (after Aug 31)	$3/M	$15/M	~$495
Claude Sonnet 4.6	$3/M	$15/M	~$495
Claude Opus 4.8	$5/M	$25/M	~$825

At intro pricing, that workload runs about $330 a month on Sonnet 5 versus $825 on Opus 4.8. That's roughly 60% cheaper for work where Sonnet 5 is close enough in quality to not matter. Against Sonnet 4.6, you're saving a third during the intro window for a better model.

One honest caveat that most launch coverage is skipping: Sonnet 5 uses a new tokenizer that counts tokens higher than before, by anywhere from 1x to about 1.35x depending on your content. So the same text costs more tokens than it did on Sonnet 4.6. Anthropic says the intro pricing accounts for this, which is likely why the discount window exists at all. The practical takeaway: run your own workload for a day and check the real token counts before you trust the sticker math exactly. This is the kind of thing that quietly erodes a "60% cheaper" claim into "45% cheaper."

How does Sonnet 5 compare to Opus 4.8?

This is the decision most people actually care about, and the honest answer has nuance.

On agentic coding, Sonnet 5 scores meaningfully below Opus 4.8 but well above Sonnet 4.6. On knowledge work, it edges slightly ahead of Opus 4.8. On computer use and browser tasks, it lands close. Push Sonnet 5 to its maximum reasoning effort and it can roughly match Opus 4.8's mid-to-high setting on some benchmarks, but at that effort level it also gets expensive to run, sometimes more than Opus 4.8 at a comparable setting. So maxing out Sonnet 5 to chase Opus-level results is usually the wrong move. If you need Opus-level output, just use Opus.

Anthropic is refreshingly direct about this: Opus 4.8 is still the model of choice for higher accuracy on hard tasks, and Sonnet 5 is the lower-priced option that's much better than what was there before. That maps cleanly onto how you should actually pick. I broke the up-tier down in the Claude Opus 4.8 review, and the full tier logic is in when to use Sonnet vs Opus vs Haiku.

Against the wider field, Sonnet 5 undercuts Opus 4.8, GPT-5.5, and Gemini 3.1 Pro on price while landing in a similar quality band for agentic work. It's still pricier than Gemini 3.5 Flash, which remains the budget option if raw cost is all you care about. The Gemini 3.5 Flash vs Sonnet 4.6 comparison covers that end of the market.

Who should switch to Sonnet 5?

Clear picks by situation.

On Sonnet 4.6 right now: switch. There's no real downside. It's cheaper during the intro window, matches your old price after, and it's a better model on every axis Anthropic measured. Update your model string to claude-sonnet-5 and move on.

Paying for Opus 4.8 on everyday work: switch most of it. If you've been running Opus as your default because it was the best, audit which tasks actually need that accuracy. Most day-to-day coding, drafting, summarizing, and tool-calling runs fine on Sonnet 5 at a fraction of the cost. Keep Opus for the hard 10%.

Doing genuinely hard, high-stakes work: stay on Opus 4.8. Complex multi-repo refactors, tricky root-cause debugging, anything where a wrong answer costs real money, Opus still has the edge on the hardest reasoning. Sonnet 5 narrows the gap, it doesn't close it.

Just using Claude in Claude Code or the chat app: you're already on it. Sonnet 5 is the new default, and you can switch models with /model if you want Opus for a specific session. If you're new to the workflow, the Claude Code guide for solo devs walks through it.

What else shipped alongside it?

Two things landed the same day, worth a line each. Anthropic also launched Claude Science, a research workbench for scientists, which is niche for most indie hackers. And Claude Code and Claude Design now sync both ways through a /design-sync command, so you can push design components between your repo and the Claude Design canvas. If you build UI, that one's worth a look on its own.

The bottom line

Claude Sonnet 5 is the rare launch that's both genuinely good and genuinely available on day one. For most indie hackers, it's the new default Claude model: close enough to Opus 4.8 on the work you do all day, cheaper than the Sonnet you were already using, and live everywhere right now.

Switch from Sonnet 4.6 without thinking twice. Move your non-critical Opus workloads over and watch the bill drop. Keep Opus 4.8 for the genuinely hard stuff. And test your real token usage during the intro window, because the tokenizer change means the savings are real but slightly smaller than the headline numbers suggest.

Running Sonnet 5 on something interesting? Tell me what you're building on Twitter @devtoolpicks.

Astro vs Next.js vs Eleventy for Content Sites in 2026

DevToolsPicks — Tue, 30 Jun 2026 04:35:10 +0000

Picking a framework for a content site in 2026 is easier than it looks, because the three real contenders barely overlap. Astro, Next.js, and Eleventy each win a different job, and most of the agonizing online is people comparing tools that were never meant for the same use case.

Here's the short version. If you're building a blog, docs, or a marketing site, use Astro. It's the default for content now, and for good reason. If you want the absolute simplest static setup with no framework at all, use Eleventy. And reach for Next.js only when your "content site" is really a React app wearing a blog as a hat.

That's the verdict. Below is why, with the real tradeoffs in performance, complexity, and cost, written from the perspective of someone who ships content sites rather than benchmarks them for sport.

Quick verdict

Tool	Best for	Client JS	Cost	Rating
Astro	Content sites that need a little interactivity	Zero by default	Free, host free on Cloudflare/Netlify/Vercel	4.5/5
Eleventy	The simplest possible static site	Zero, always	Free, host free anywhere static	4/5
Next.js	Content sites that grow into apps	Ships a React runtime	Free, hosting varies with server use	4/5

Astro: the default for content sites

Astro won the content tier, and it wasn't close. The current release is Astro 6, the project sits north of 59,000 GitHub stars, and in January 2026 Cloudflare acquired the Astro team. It stays MIT-licensed and open source, but it now has a serious infrastructure company behind it, which matters if you're betting a site on it for the next five years.

The core idea is islands. Astro ships zero JavaScript by default and renders everything to plain HTML. When you need an interactive piece, a search box, a carousel, a comment widget, you mark that one component as an island and only it hydrates. Everything else stays static. The result is Lighthouse scores in the high 90s without you doing anything clever, which is exactly what you want when SEO is your traffic channel.

It's also genuinely pleasant to build with. You author components in plain Astro syntax or bring React, Vue, Svelte, or Solid, and mix them on the same page. Content Collections give you type-safe Markdown and MDX with schema validation, so your blog posts stop silently breaking when you typo a frontmatter field. Astro 6 added Live Content Collections for data that updates without a rebuild, plus built-in CSP support.

The build speed is a real selling point too. Astro 6's Markdown pipeline rebuilds a 100-post site in roughly 200 milliseconds, a 5x jump over Astro 5. That tight feedback loop matters when you're writing and previewing all day. Migrations are quick as well: most blog and marketing moves off WordPress, Gatsby, or 11ty land in one to three days, since the MDX pipeline is largely compatible and Content Collections replace your old data layer.

The honest cons: Astro 6 requires Node 22, and the upgrade from v5 had real breaking changes (Zod 4, dropped legacy APIs). Sharing state across islands needs an external store like Nano Stores, which adds friction. And it's the wrong tool for a genuinely app-heavy product, dashboards and authenticated flows fight the model.

Who should not use Astro: anyone building a real web app rather than a content site. If most of your pages are interactive and stateful, you're swimming upstream.

Eleventy: the simplest static site you can build

Eleventy, often written 11ty, is the minimalist's pick, and it's aged beautifully. It's been downloaded over 19 million times, runs on 82,000-plus repos, and the current v3 line is ESM-based and fast. The project rebranded to "Build Awesome" in early 2026, though the npm package is still @11ty/eleventy and everyone still calls it Eleventy.

What makes it special is what it doesn't do. Eleventy takes a directory of templates and data and turns it into static HTML. That's it. No UI framework, no client runtime, zero JavaScript shipped to the browser unless you add it yourself by hand. It produces the smallest output of any major static generator, often a fraction of the equivalent Astro or Next.js build. For a pure blog or docs site, that's a real edge.

It's also stable in a way modern JavaScript tooling rarely is. The maintainers point out that across 224 releases since 2017, only three required developer changes. People report sites running untouched for years. If you hate dependency churn, Eleventy is a balm. It still holds roughly a quarter of the new static-generator share for content sites under 2,000 pages, trailing only Astro in the JavaScript category, so it's far from a niche relic.

The honest cons: there's no component model and no islands. The moment you need interactivity, you're wiring up vanilla JavaScript or bolting on a separate tool, and the elegance fades. It also leans on templating languages like Nunjucks and Liquid rather than components, which feels dated if you're coming from React. Documentation is good but the ecosystem is thinner than Astro's.

Who should not use Eleventy: anyone who needs more than occasional interactivity, or who wants a component-based authoring experience. It's a static HTML machine, and that focus is both its strength and its ceiling.

Next.js: the heavyweight that can do content too

Next.js is the giant in the room, around 140,000 GitHub stars, and the current 16.2 line ships React 19.2 with Turbopack as the default bundler and the App Router as the default. It's a full-stack React framework, and it's superb at what it's built for: application-style sites with dashboards, auth, server actions, and dynamic data.

Can it build a content site? Absolutely. It supports static export and Incremental Static Regeneration, so a Next.js blog or marketing site works fine and deploys statically. If your team already lives in React, there's a real argument for keeping everything in one framework rather than learning Astro just for the marketing pages. I broke down the broader framework field in Next.js vs Nuxt vs SvelteKit if you're weighing the app-framework options.

The honest cons for content specifically: weight. Because Next.js is built on React, it ships a client runtime even for largely static pages. A Next.js static export typically sends several times more JavaScript than the same site in Astro, and many times more than Eleventy. For a content site where Core Web Vitals drive your SEO, that's a tax you're paying for flexibility you may not need. The caching model is also famously fiddly, and the framework moves fast enough that six-month-old tutorials often break on a fresh install.

Who should not use Next.js for content: anyone whose site is purely content and isn't already in the React ecosystem. You'd be carrying a full application framework to publish blog posts.

How do the three actually compare?

The real decision comes down to three dimensions.

JavaScript shipped, which drives performance and SEO. Eleventy ships zero, full stop. Astro ships zero by default and only adds JavaScript for the islands you opt into. Next.js ships a React runtime regardless. The gap is bigger than it sounds: on paired builds, a typical Astro site runs around 1.5x heavier than the same site in Eleventy, while a Next.js static export runs roughly 8 to 12x heavier than Eleventy. For a content site where speed is the SEO lever, that ordering matters, and it's why Astro and Eleventy dominate the content tier.

Interactivity, when you need more than static pages. This flips the order. Next.js handles rich interactivity natively because it's an app framework. Astro handles selective interactivity cleanly through islands. Eleventy handles none of it for you, you build it yourself. Match the tool to how dynamic your site actually is, not how dynamic you imagine it might become.

Where it's heading. If there's a real chance your content site becomes a product, with logins, billing, a dashboard, starting in Next.js saves a future migration. If it's going to stay content, that future-proofing is just weight you carry today for a tomorrow that may never arrive.

All three are free and open source, so cost is really a hosting question. Every one of them deploys to a free tier on Cloudflare Pages, Netlify, or Vercel, with static output that's cheap or free to serve. Next.js only starts costing real money when you lean on server-side features at scale. If you're weighing where to put any of them, I compared the options in the best Vercel alternatives and the best Netlify alternatives.

Final recommendation

For most indie hackers building a content site in 2026, use Astro. It's the right default: fast, modern, content-first, and flexible enough to add the occasional interactive piece without dragging a whole app framework along. The Cloudflare backing makes it a safe long-term bet too.

Choose Eleventy if your site is pure content and you value simplicity and stability over features. A personal blog, a docs site, a landing page, Eleventy will build it smaller and faster than anything else and then leave you alone for years.

Choose Next.js only if your content site is really an application, or if your whole stack is already React and consistency beats raw performance. For a pure blog, it's the wrong tool, and you'll feel the extra JavaScript in your Core Web Vitals.

Most teams I know end up using two of these, Astro or Eleventy for the marketing site and blog, Next.js for the app. That's not indecision. It's using each tool for the job it's actually good at.

Building a content site and landed on a different pick? Tell me what you chose on Twitter @devtoolpicks.

Best Jira Alternatives for Indie Hackers in 2026 (Honest Picks)

DevToolsPicks — Mon, 29 Jun 2026 04:40:11 +0000

Jira is the project tracker everyone uses and almost nobody loves. If you've ever opened a ticket, gotten lost in three layers of nested epics, and closed the tab to go do literally anything else, you know the feeling.

For a solo dev or a small team, Jira is overkill. The free plan caps at 10 users. The paid plans look cheap at $7.91 per user until you add the Marketplace apps, Atlassian Guard, and Confluence that the workflow quietly assumes, and the real bill lands at two to three times the sticker price. Atlassian also stopped selling new self-hosted Data Center licenses in March 2026, so that escape hatch is closed for new teams.

Here's the short version. For most indie hackers, Linear is the switch. If you want to own your data and pay nothing, self-host Plane. If your code already lives on GitHub, GitHub Projects costs you zero. Below is the honest breakdown of all five, with real pricing and who each one is wrong for.

Quick verdict

Tool	Best for	Starting price	Rating
Linear	Dev teams that want speed	Free, then $10/user/mo	4.5/5
Plane	Owning your data, self-hosting	Free self-host, cloud $8/user/mo	4/5
GitHub Projects	Teams already on GitHub	Free	4/5
Shortcut	Small software teams	Free up to 10 users, then $8.50/user/mo	4/5
ClickUp	All-in-one beyond issue tracking	Free, then $7/user/mo	3.5/5

Why are people leaving Jira?

It's worth naming the actual pain before the alternatives, because it tells you what to look for.

Jira is slow to navigate and slow to set up. It's built for large orgs with dedicated admins who enjoy configuring workflows. The per-user pricing is fine on paper, but the Linear vs Jira vs ClickUp comparison showed how fast the total cost grows once you bolt on the rest of the Atlassian stack. And in 2026, monthly billing charges your peak headcount during the cycle, so hiring three contractors for a two-week sprint bumps your bill with no refund when they leave.

None of that matters at enterprise scale. All of it matters when you're one person shipping a SaaS on weekends.

Linear: the default switch for dev teams

Linear is what most teams move to when they leave Jira, and for good reason. It's fast, opinionated, and gets out of your way. The whole thing is keyboard-driven, the workflows are built around cycles and projects instead of infinite custom fields, and you're productive on day one rather than day seven. More than 33,000 companies run on it now, including Vercel and Ramp.

The free plan gives you unlimited members but caps at 250 active issues and 2 teams, which a busy team hits within a few weeks. Paid plans are Basic at $10 per user per month and Business at $16 per user per month, both billed annually. AI agents are included on every tier at no extra charge.

The honest cons: billing is annual-only, so there's no monthly option to fall back on, and you don't get a refund if your headcount drops mid-contract. SAML and SCIM are locked to the Enterprise tier. And there's no free read-only seat, so every stakeholder who needs to peek at progress costs a full seat. That last one is exactly where Jira's free viewer licenses still win.

Who should not use Linear: teams with lots of non-technical stakeholders who only need visibility, or anyone who needs month-to-month flexibility. If Linear is close but not quite right, I went deeper on the field in the best Linear alternatives.

Plane: the open-source pick if you want to own your data

Plane is the one I'd point any self-hosting indie hacker toward first. It's open source under AGPL-3.0, it has roughly 40,000 GitHub stars, and the Community Edition runs on your own server with no user limits at all. The model borrows heavily from Linear: cycles for sprints, modules for epics, issues with priority and status, multiple views. It also bundles a wiki, so your docs and your tickets live in one place.

Pricing is the best part. Self-hosted Community Edition is free, so your only cost is the box it runs on, usually $5 to $20 a month on a small VM. If you'd rather not run infrastructure, the cloud free tier covers up to 12 members, then Pro is $8 per member per month and Business is $16. It also ships importers for Jira, so migrating off isn't a manual slog.

The honest cons: self-hosting means you own the Postgres and Redis upkeep, and a Kubernetes deployment needs real DevOps comfort, though the Docker Compose path genuinely takes about ten minutes. The UI is clean but still a step behind Linear on polish and keyboard speed, and the integration library is thinner.

Who should not use Plane: teams with no appetite for running their own infrastructure, or anyone who needs a deep ecosystem of third-party integrations on day one.

GitHub Projects: free, and already in your repo

If your code lives on GitHub, you already have a project tracker and you might not realize it. GitHub Projects is built into every account, it's free, and it sits right next to your issues and pull requests. For a solo dev or a tiny team, that tight loop between code and tasks is hard to beat. You link an issue to a PR, the board updates itself, and there's no second tool to pay for or context-switch into.

The price is the headline: $0. GitHub Free includes unlimited public and private repos plus Projects, issues, and milestones. You only pay if you need org-level controls like required reviewers on private repos, and even then Team is just $4 per user per month.

The honest cons: it's a tracker, not a full project management suite. There are no burndown charts, no native time tracking, no resource planning, and reporting is basic. The board views are flexible but you'll outgrow them if you need sprint analytics or cross-team roadmaps.

Who should not use GitHub Projects: teams that need real reporting, capacity planning, or anyone whose non-engineering side needs a polished PM experience. It's a developer's tool, full stop.

Shortcut: the middle ground built for software teams

Shortcut (formerly Clubhouse) sits nicely between Linear's speed and Jira's structure. It's purpose-built for software teams, organized around Stories, Epics, and Objectives, with solid GitHub, GitLab, and Slack integrations and a clean API. It's less rigid than Jira and more structured than a bare GitHub board.

The free plan is genuinely useful: full features for teams of up to 10 people, which covers a lot of indie projects outright. Above that, Team is $8.50 per user per month billed annually ($10 monthly) and Business is $12 per user per month annually ($16 monthly). Startups under 50 employees can get 12 months free, which is a real perk if you're early. It imports directly from Jira and Trello too.

The honest cons: permissions only work at the workspace level, so fine-grained access control means spinning up separate workspaces. There's no rich text in story descriptions, and a few people find the reporting and tagging less flexible than they'd like. Support quality gets mixed reviews.

Who should not use Shortcut: teams that need granular per-project permissions, or non-software teams. It's tuned for engineers, and that focus is the point.

ClickUp: the all-in-one if you want more than tickets

ClickUp is the opposite philosophy from Linear. Where Linear does one thing fast, ClickUp tries to do everything: tasks, docs, goals, time tracking, dashboards, whiteboards. If you want a single tool to replace three, it's the most feature-dense option here, and it's cheap for what you get.

The Free Forever plan has unlimited members but caps total storage at 100MB across the whole team, which fills fast. Unlimited is $7 per user per month (annual) and unlocks unlimited storage and Gantt charts. Business is $12 per user per month and adds workload management, time tracking, and heavier automation. One catch worth flagging: ClickUp Brain, the AI layer, is a separate $9 per member add-on, so an AI-enabled Business seat is really $21.

The honest cons: the flexibility is also the curse. Setup takes real time, the feature density is overwhelming, and you can spend more hours configuring ClickUp than you save using it. For pure issue tracking it's heavier than you need. If documentation is the main draw, I'd weigh it against dedicated options in the best Notion alternatives and the Notion vs Obsidian vs Anytype breakdown before committing.

Who should not use ClickUp: anyone who just wants to track tickets and ship. The all-in-one promise costs you in setup complexity, and a solo dev rarely needs that much surface area.

How do you pick the right one?

It comes down to four questions.

Do you want the fastest path with the least fuss? Pick Linear. It's the safe default and the one I'd recommend to most indie hackers without a second thought.

Do you want to pay nothing and own your data? Self-host Plane. You trade a bit of DevOps time for zero per-seat fees and full control.

Is your whole world already on GitHub? Use GitHub Projects. There's no reason to add a tool when the one in your repo is free and good enough for a small team.

Do you need more than issue tracking, like docs, goals, and time tracking in one place? ClickUp, with eyes open about the setup tax. And if you want a software-specific tracker with a generous free tier, Shortcut is the comfortable middle.

Final recommendation

For most indie hackers leaving Jira, switch to Linear and don't overthink it. It's fast, it's priced fairly at $10 per user, and you'll be shipping within an hour.

If you're cost-sensitive or privacy-minded, self-host Plane for the price of a cheap VM. If you already live on GitHub, GitHub Projects is the no-brainer free option. Pick ClickUp only if you genuinely need an all-in-one and accept the setup cost, and reach for Shortcut if you want a dev-focused tracker that's free up to 10 people.

The one thing I'd avoid is staying on Jira out of habit. For a small team in 2026, it costs more, moves slower, and asks more of you than any of these five. Switching is a weekend job, and every one of these makes Monday morning a little less painful.

Found a Jira alternative I missed? Let me know on Twitter @devtoolpicks.

Playwright vs Cypress vs Selenium for Indie Hackers in 2026

DevToolsPicks — Sun, 28 Jun 2026 04:35:08 +0000

Here's a thing that surprises people: choosing an end-to-end testing framework in 2026 is way less of a debate than the internet makes it sound. For a solo founder building a web app on a JavaScript, TypeScript, or Python stack, running tests in GitHub Actions, watching CI minutes, the answer is mostly settled. But the comparison articles haven't caught up, so you'll read endless three-way debates that matter for a 50-person enterprise QA org and not for you.

Let me cut through it. All three of these are free and open source. So stop comparing license fees, because there aren't any. The real cost of end-to-end testing is CI minutes, the hours you'll burn debugging flaky tests, and whether you can actually test Safari. That's the lens that matters for an indie hacker, and through that lens the picture is clear.

Playwright has become the default for new projects, and the data backs it up: it pulls far more weekly npm downloads than Cypress and Selenium combined, sits around 88,000 GitHub stars, and topped the latest State of JS satisfaction survey by the widest margin yet. But "most popular" isn't a reason on its own. Here's what each one actually does well, what it costs you in practice, and who should still pick the other two.

The Quick Verdict

Tool	Best for	Real cost	Browsers
Playwright	The default for new web projects	CI minutes only, free parallel	Chromium, Firefox, WebKit (Safari)
Cypress	Frontend DX on single-domain apps	Free, but parallel pushes you to paid Cloud	Chromium, Edge, Firefox (experimental)
Selenium	Legacy suites, polyglot, native mobile	Grid infrastructure	All, including legacy via WebDriver

Short version: start new projects on Playwright. Use Cypress only if its developer experience is the thing you care about most and you live within its limits. Reach for Selenium if you already run it, your team isn't on JS or Python, or you need real mobile-device testing.

They're All Free, So What Actually Costs You?

This is the section nobody leads with. Since none of the three charge a license fee, your spend is downstream: CI compute, maintenance time, and any dashboard subscription.

Playwright's parallelization is free and built in. You split a suite across runners with a single --shard flag, no extra service required. Independent estimates put a 500-to-1,000-test suite on GitHub Actions around $150 to $300 a month in CI minutes with Playwright.

Cypress is where it gets subtle. The framework is free, but its parallel execution and the reporting dashboard run through Cypress Cloud, which is paid. After Cypress was acquired in 2025, the free Cloud tier was capped (roughly 30-day data retention and a yearly test-result limit), with the Team plan landing around $67 a month beyond that. So a Cypress suite can cost meaningfully more to run at the same scale, both in CI minutes and the Cloud subscription you drift into.

Selenium has no subscription, but parallel runs need a Grid, either self-hosted (real infrastructure to maintain) or through a paid service like BrowserStack. That's the most operational overhead of the three.

The other hidden cost is flakiness. A flaky test you re-run three times burns CI minutes and, worse, your trust in the suite. Playwright's auto-wait engine retries actions intelligently, and independent benchmarks show it producing dramatically fewer flaky failures than Selenium's manual waits. For a solo dev, fewer 11pm "why did CI fail again" sessions is worth more than any benchmark.

Playwright

Playwright is the one I'd start any new project on. Microsoft released it in 2020, built by the team that originally created Puppeteer, and it talks to browsers directly through their native debugging protocols rather than through a middleman driver. That architecture is why it's fast and why it auto-waits for elements instead of making you write manual waits.

The practical wins stack up. It drives Chromium, Firefox, and a real WebKit engine, so you test actual Safari behavior on any OS, including a Linux CI runner, with zero setup. It handles multi-tab, multi-origin, and iframe flows natively, which matters the moment you test an OAuth login or a Stripe checkout popup. It supports TypeScript, JavaScript, Python, Java, and C#, ships a codegen recorder, traces, and screenshots, and parallelizes for free. It even tests API routes and server components directly, which pairs well if you're building on Next.js, Nuxt, or SvelteKit, and it overlaps neatly with the API-layer tools I covered in the best API testing tools.

For an indie hacker leaning on AI, Playwright also has the best agent story: a Playwright MCP server, a recorder that generates tests, and "Fix with AI" in the VS Code extension. If you already pair with an AI coding tool, this is the framework that plugs into that workflow most cleanly. It's also what Checkly uses under the hood for synthetic monitoring, which I touched on in the best uptime monitoring tools.

Who should skip it? If you need to automate native iOS or Android apps, Playwright only emulates mobile browsers, so you'll want Appium instead. Its plugin ecosystem is younger than Selenium's two-decade base, though it has replicated most of that functionality with built-in APIs. And if your team genuinely lives and dies by Cypress's interactive runner, the switch is a real adjustment.

Cypress

Cypress earned a devoted following for one reason: developer experience. It launched in 2017 with a genuinely novel idea, running your test code inside the browser in the same event loop as your app. That gives you the time-travel debugger, the interactive test runner where you watch each command replay, and deep access to your app's internals. For a frontend developer who wants tight, visual feedback while writing tests, nothing else feels as good. Its component-testing story is also the most mature of the three, covering the widest range of frontend frameworks. The current line is Cypress 15, which recently added an AI-assisted authoring command in beta.

But the architecture that makes Cypress pleasant also boxes it in, and the limits are exactly the things indie SaaS apps hit. There's no real Safari support: Chromium and Edge are first-class, Firefox has been experimental for years, and WebKit isn't there. With Safari at roughly 18% of browsers, that alone disqualifies Cypress as a sole testing tool for many consumer apps. It also can't do true multi-tab flows, because the runner itself occupies the second browser slot. The cy.origin() command handles some cross-origin OAuth in a single tab, but popups and real multi-tab interactions are out. That multi-tab gap is the single most common reason teams migrate to Playwright in 2026.

Who should skip it? Anyone who needs Safari coverage, multi-tab flows, or a non-JavaScript language, which rules it out for a lot of real apps. And anyone cost-sensitive about CI, since free parallelization isn't part of the picture. If you're a pure JS or TS team on a single-domain SPA and the DX is what keeps you actually writing tests, Cypress is still a legitimate, even excellent, choice. The best framework is the one your team uses consistently.

Selenium

Selenium is the grandparent of browser automation, open source since 2004, and it's still here for good reasons. It has the largest installed base of any framework, the broadest language support (Java, Python, C#, Ruby, PHP, JavaScript, Kotlin), and the widest browser coverage including legacy targets. It's actively maintained, not a museum piece: Selenium 4.43 is current, and Grid 4.41 added native Kubernetes provisioning in early 2026, with expanding WebDriver BiDi support that modernizes how it talks to browsers.

Its real superpower for 2026 is the one thing the other two can't do: paired with Appium, Selenium drives true native mobile apps on real iOS and Android devices, not just mobile browser emulation. If your product is a native app, the Selenium and Appium combination is the industry standard.

Who should skip it? Most new indie web projects, honestly. Selenium uses the WebDriver protocol, which puts a driver process between your test and the browser and adds round-trip latency on every command, so it's the slowest of the three. It has no native auto-wait, so you write explicit waits and fight more flakiness. And parallelizing means standing up a Grid, which is real infrastructure. For a solo founder on a modern JS or Python web stack, that's a lot of overhead to take on Selenium's breadth when you'll use a fraction of it. Pick it for an existing suite, a polyglot team, or native mobile, not for a greenfield web app.

How Do the Three Compare Head to Head?

Strip it to the dimensions that decide a real project.

Dimension	Playwright	Cypress	Selenium
Speed	Fastest	Fast	Slowest
Flakiness	Lowest (auto-wait)	Low	Highest (manual waits)
Safari/WebKit	Yes	No	Yes
Multi-tab flows	Yes	No	Yes
Free parallel	Yes	No (Cloud)	Via Grid
Languages	TS, JS, Python, Java, C#	JS/TS only	Most languages
Native mobile	No	No	Yes (Appium)

The pattern is clear. Playwright covers the things that matter for a modern web app with the least friction. Cypress trades coverage for developer experience. Selenium trades speed and setup for unmatched breadth.

How Do You Choose the Right One?

Start with your stack and what you actually need to test.

Concrete scenarios. Brand-new SaaS on a JS, TS, or Python stack? Playwright, almost every time. Testing a native mobile app? Selenium with Appium. Frontend team on a single-domain SPA that genuinely loves the Cypress runner and doesn't need Safari? Cypress is fine. Big legacy Selenium suite that works? Don't rewrite it for fun, just write new coverage in Playwright alongside it.

The Verdict: Which Should You Use?

For almost every new indie project in 2026, use Playwright. It's free, it's the fastest and least flaky of the three, it tests every browser including Safari, it parallelizes without a paid dashboard, and it has the best AI tooling if you build with coding agents. The popularity is a symptom, not the reason. The reason is that it removes the exact friction (flaky tests, Safari gaps, paid parallelization) that wastes a solo dev's time and money.

Choose Cypress only if its developer experience is genuinely the thing that makes you write tests, your app is single-domain, and you don't need Safari or multi-tab flows. That's a narrower box than it used to be, but inside it, Cypress is still a joy.

Choose Selenium if you already run it and it works, your team isn't on JavaScript or Python, or you need real native mobile testing through Appium. It's not the default for new web projects anymore, but it's far from dead and it's the right tool for those specific jobs.

The honest meta-point is that the framework war that dominates the search results is mostly an enterprise conversation. For a solo founder shipping a web app, the decision compresses to one line: use Playwright unless you have a specific reason rooted in mobile, language, or an existing suite. Spend the time you saved writing actual tests. Running one of these on your project? Tell me how it's going on @devtoolpicks.

OpenAI's GPT-5.6 Sol, Terra, and Luna: What Just Launched (and Why You Can't Use It Yet)

DevToolsPicks — Sat, 27 Jun 2026 08:43:50 +0000

OpenAI just dropped GPT-5.6, and it's the biggest shake-up to its lineup in a while: not one model, but three tiers called Sol, Terra, and Luna. Bigger benchmarks, lower prices on the cheaper tiers, two new reasoning modes. The AI feeds have been on fire since the announcement.

Here's the part most of the breathless coverage buries: you can't use it. Not yet. GPT-5.6 launched on June 26 as a limited preview for roughly 20 hand-picked organizations, through the API and Codex only, coordinated with the US government. It isn't in ChatGPT. There's no waitlist you can join. Individual developers aren't eligible. So before you plan a migration, know that the practical answer for a solo founder today is "nothing you can act on, but here's what's coming."

That said, this launch matters, because broad availability is planned for the coming weeks and the pricing is genuinely interesting for the work indie hackers actually do. Let me break down what the three tiers are, what they cost, what's new, and what to do with this information right now (which is mostly: keep building on what you can already access).

The Quick Verdict

Tier	Best for	Preview price (per 1M tokens)
GPT-5.6 Sol	Hardest jobs: agentic coding, security research	$5 in / $30 out
GPT-5.6 Terra	Everyday work: writing, summaries, routine coding	$2.50 in / $15 out
GPT-5.6 Luna	High-volume, low-stakes: classification, drafts	$1 in / $6 out

Short version: Sol is the flagship, Terra is the value pick at half of GPT-5.5's price, and Luna is the budget workhorse. All three are preview-only right now. For most of us, the useful takeaway is Terra, a near-GPT-5.5-quality model at half the cost, once it actually ships.

What Is GPT-5.6, Exactly?

The headline change is structural. Instead of shipping one model with confusing "mini" and "nano" spinoffs, OpenAI split GPT-5.6 into three named capability tiers. The number tells you the generation. The name tells you the tier. And each tier can move forward on its own cadence from here.

Sol is the flagship, built for the most demanding work: complex reasoning, extended coding sessions, agent-driven workflows, and security research. It's OpenAI's strongest model to date by their account.

Terra is the balanced everyday tier. OpenAI says it matches GPT-5.5 performance while costing roughly half as much, which makes it the one most small teams will care about. Business writing, summarization, internal assistants, routine coding help: Terra is aimed squarely at that.

Luna is the fast, cheapest tier for high-volume, low-stakes tasks: classification, drafting, simple extraction, the things you run thousands of times where cost per call dominates. OpenAI says it performs near GPT-5.5 levels on several tests despite being the budget option.

The naming mirrors how Anthropic and Google already think about tiers, and it's genuinely clearer than "GPT-5.6-mini-high." It turns model choice into a routing decision rather than a single yes-or-no upgrade. This builds directly on the GPT-5.5 launch, which was a single flagship drop.

How Much Does GPT-5.6 Cost?

OpenAI published preview pricing right away, which is useful for planning even though it could change at general availability.

Tier	Input / Output (per 1M tokens)	Compared to
Sol	$5 / $30	Same as GPT-5.5
Terra	$2.50 / $15	Half of GPT-5.5
Luna	$1 / $6	Cheapest in the family

The standout is Terra. If it really delivers GPT-5.5-class quality at $2.50/$15, that's a meaningful cut for the everyday workloads most indie products run on. GPT-5.6 also reworks prompt caching: cache reads keep the 90% discount, cache writes now cost 1.25x the normal input rate, and there's a 30-minute minimum cache life with explicit cache breakpoints. For chatbots and agents that resend the same context constantly, that caching math is where a lot of real savings live.

What's Actually New Beyond the Tiers?

Two reasoning controls are the real feature story. The first is a new max reasoning effort, which gives Sol more time to think deeply on a single hard problem. The second is ultra mode, where instead of one model grinding alone, the system spins up sub-agents that split a complex task and work it in parallel. Think of max as making one brain think longer, and ultra as putting several brains on the same job.

OpenAI also shipped what it calls its most robust safety stack yet, with hardening around sensitive cyber requests and repeated misuse. Worth noting for anyone in a regulated space: OpenAI classifies all three tiers, not just Sol, at "High" risk for cyber and biological capability, which can carry governance obligations if you use them in security or life-sciences workflows. A faster Cerebras-hosted version of Sol is also coming in July at up to 750 tokens per second, initially for select customers.

The Catch: It's a Limited Preview

This is the part to internalize before you get excited. GPT-5.6 is not a normal launch you can sign up for.

Access right now is restricted to about 20 trusted partner organizations, available only through the API and Codex, and explicitly not in ChatGPT. There's no public application, no waitlist, and individual users aren't eligible. OpenAI says it will contact organizations that qualify. The gating exists because OpenAI coordinated the release with the US government under a June executive order on assessing frontier models' cyber capabilities, and the government asked it to start narrow.

OpenAI wasn't thrilled about it. The company publicly stated it doesn't believe this kind of per-customer government approval should become the long-term default, and framed the limited preview as a short-term step toward a broad release "in the coming weeks." So the door is opening, just not today, and not on a confirmed date.

Where Does GPT-5.6 Sit Against the Field?

Even on preview pricing, you can see how each tier lines up against what you can run today.

Model	Input / Output	Tier
GPT-5.6 Sol	$5 / $30	Flagship
Claude Opus 4.8	$5 / $25	Flagship
GPT-5.6 Terra	$2.50 / $15	Mid
Claude Sonnet 4.6	$3 / $15	Mid
GPT-5.6 Luna	$1 / $6	Budget
Gemini 3.5 Flash	$1.50 / $9	Budget

A few things jump out. At the top, Sol's $5/$30 actually sits a touch above Claude Opus 4.8's $5/$25 on output, so OpenAI isn't undercutting at the flagship tier. The interesting moves are lower down. Terra at $2.50/$15 lands right in Claude Sonnet 4.6 territory, the workhorse tier where most production traffic lives. And Luna at $1/$6 undercuts Gemini 3.5 Flash, though Google's free tier and Chinese models like GLM-5.2 still compete hard at the very bottom. For the head-to-head at the flagship level, I broke down the current matchup in Claude Opus 4.8 vs GPT-5.5, and the budget-tier gap in Gemini 3.5 Flash vs GPT-5.5.

So What Should You Actually Do Now?

You can't run GPT-5.6, so don't rearchitect anything around it yet. Here's the practical play.

Keep building on the models you can access today, like Opus 4.8 for the hard jobs and Sonnet 4.6 or Gemini Flash for everyday volume. Note Terra's pricing for when it ships, because a half-price GPT-5.5-class model is worth testing the day it goes broad. And be skeptical of any "GPT-5.6 beats everything" benchmark thread for now, since those are OpenAI's own numbers and nobody outside the preview can verify real-world quality yet.

The Bottom Line

GPT-5.6 is a real and interesting launch: three clear tiers, a genuinely cheaper mid-tier in Terra, and two new reasoning modes. But the honest status for indie hackers on June 27 is that it's a preview you can't touch, with general availability promised in the coming weeks and no firm date. The smart move is to file the pricing away, keep shipping on what you can run today, and revisit the moment Terra and Luna hit the open API. When they do, this stops being news to read and becomes a model to test. Building something where one of these tiers would fit? Tell me what you'd put it on over on @devtoolpicks.

Better Auth vs Clerk vs Auth.js for Indie Hackers in 2026

DevToolsPicks — Sat, 27 Jun 2026 04:25:11 +0000

Picking auth is one of those decisions that feels small and then quietly shapes your codebase for years. And the choice changed more in the last year than most people realize. If you Google this, half the comparisons you'll find are describing an ecosystem that no longer exists.

Here's the shift. In late 2025, Auth.js (the library formerly known as NextAuth.js) joined forces with Better Auth. The Better Auth team now maintains it, and Auth.js is officially in maintenance mode: security patches only, no new features. So the old "NextAuth vs Better Auth" framing is basically over. They're the same camp now, with Better Auth as the future and Auth.js as the legacy version you keep around if you already use it. Around the same time, Clerk quietly raised its free tier from 10,000 users to 50,000.

That leaves a cleaner question for 2026: do you want to own your auth or rent it? Better Auth (and its predecessor Auth.js) keep your users in your own database and cost nothing per user. Clerk runs auth as a service, ships fastest, and charges per user once you scale. I've wired up auth more times than I'd like to admit, so here's the honest three-way with real pricing.

The Quick Verdict

Tool	Best for	Pricing	Your users live
Better Auth	Owning your auth, new projects	Free (your database)	In your own DB
Clerk	Shipping fastest	Free to 50K users, then $0.02 each	In Clerk's US database
Auth.js (NextAuth)	Existing apps already on it	Free (your database)	In your own DB

Short version: start new projects on Better Auth if you want to own your stack, or Clerk if you want to ship today and you're comfortable renting. Only pick Auth.js if you already run it.

What Actually Changed in 2026?

This is the part that reframes everything. Auth.js had been stuck: version 5 sat in beta for over two years, and its lead maintainer stepped back in early 2025. Rather than let it fade, the Better Auth team took it over. They've committed to keeping Auth.js patched for security, but their guidance is direct: start new projects on Better Auth.

The practical effect is that the field narrowed from three real options to two, plus a legacy. For a new build, you're choosing between a self-hosted library you control (Better Auth) and a hosted service you pay for (Clerk). Auth.js is now the thing you migrate away from, not toward. One security note that applies to all of them: the 2025 Next.js middleware vulnerability (CVE-2025-29927) showed that protecting routes with middleware alone is bypassable, so check auth in the actual server component or route handler regardless of which library you choose.

Better Auth

Better Auth is the one I'd start a new project on today. It's a TypeScript-first, framework-agnostic authentication library, not a service. The auth code lives in your codebase, the sessions live in your Postgres, and there's no external API to call or go down. It launched in 2024, reached v1.0 quickly, and hit v1.6 by May 2026, with around 28,000 GitHub stars and a YC batch behind it. The momentum is real.

It covers the full surface out of the box: email and password, social logins, magic links, passkeys, and two-factor auth. The parts that usually hurt for SaaS, organizations, teams, role-based access control, and admin tooling, ship as official plugins rather than things you bolt on yourself. It's database-agnostic and works cleanly with Prisma or Drizzle, and it recently added stateless sessions without a database, which was the one gap Auth.js used to hold over it.

Cost is the kicker. The library is free under MIT, so you only pay for the Postgres it writes to, roughly $10 to $30 a month, and that number barely moves whether you have 5,000 users or 500,000. There's no per-user meter, ever.

Who should skip it? You're the one running it, so you own hosting, updates, and uptime. There are no pre-built UI components, so you build your own sign-in and account pages, which is real hours compared to Clerk dropping in a component. Enterprise features like SAML SSO you implement yourself. And the ecosystem, while growing fast, is younger, so you'll occasionally hit a thinner doc or a missing integration. If you want auth handled for you today, this asks more of you upfront.

Clerk

Clerk is the one you reach for when you want auth done by lunch. It's a hosted service with the best developer experience in the category: drop in pre-built React components like <SignIn />, <UserButton />, and <OrganizationSwitcher />, wire up the hooks, and you have polished, production-grade auth with social login, MFA, and multi-tenant organizations in minutes instead of days. For a solo founder racing to a first version, that time saving is the whole pitch.

The pricing changed in your favor recently. The free tier now covers 50,000 monthly retained users, up from 10,000, which takes most early products well past launch for free. Pro is $25 a month (or $20 billed annually), includes that same 50,000, then charges $0.02 per retained user above it. The "retained" part matters: Clerk only counts users who come back at least a day after signing up, so a viral burst of one-time signups doesn't spike your bill. Compliance (SOC 2, GDPR) is on every tier, and one enterprise SSO connection is included on Pro. For the managed-provider angle more broadly, I compared it with the others in Clerk vs Auth0 vs Supabase Auth.

Who should skip it? Two reasons. First, cost at scale: past 50,000 users the meter runs, and at 100,000 you're looking at about $1,025 a month for auth alone. Second, lock-in: your users live in Clerk's US-hosted database, not yours, so you're renting both the service and the home for your user data. If data residency matters or you want to own that table, Clerk fits awkwardly. It's a fast on-ramp, not always a long-term home.

Auth.js (NextAuth)

Auth.js is the library a huge slice of the JavaScript world already runs, and if you're one of them, this section is the only one that matters: you can stay. It's free, open source, and now maintained by the Better Auth team for security and critical fixes. Its strengths are still real: 80-plus OAuth providers, database adapters for Prisma, Drizzle, TypeORM, Supabase, and others, and a JWT session strategy that works at the edge without a database call. It pairs naturally with a Next.js app, where it spent its whole life as NextAuth.

But be clear-eyed about the status. Auth.js is in maintenance mode. No new features are coming. It never had built-in two-factor auth, passkeys, role-based access, or multi-tenancy, so those still mean extra libraries or custom code. The v5 split-config pattern trips people up, and the official migration guide to Better Auth exists precisely because the maintainers expect new energy to go there.

Who should skip it? Anyone starting fresh. Building a new 2026 project on Auth.js means starting on a frozen foundation when its own maintainers are pointing you at Better Auth instead. The only good reason to choose it today is that you already have it wired into a working app and there's no pressing need to migrate. If it works, leave it. If you're greenfield, don't start here.

Own It or Rent It: The Cost at Scale

The clearest way to see the tradeoff is to follow the bill as you grow. Better Auth and Auth.js cost only the database they write to, so their line stays flat. Clerk is free for a long time, then climbs per user.

Scale	Better Auth / Auth.js	Clerk
5,000 users	~$15/mo (your Postgres)	Free
50,000 users	~$25/mo (your Postgres)	Free, or $25 for orgs
100,000 users	~$30/mo (your Postgres)	~$1,025/mo

At 100,000 users, the gap is roughly a thousand dollars a month, which is about one engineer-day of cost every month for the auth layer alone. That's not an argument against Clerk. It's an argument for knowing where the line crosses. The common 2026 pattern is to ship on Clerk to reach product-market fit fast, then migrate to Better Auth or Supabase Auth somewhere around the 50,000-user mark when the bill starts catching your accountant's eye.

What's the Migration Actually Like?

Since that ship-then-move path is so common, it's worth knowing the friction before you bank on it. Leaving Clerk means exporting your users, and Clerk supports exporting bcrypt-hashed passwords, so people don't all have to reset, while social-login users just re-authorize on first sign-in. The real work isn't the data, it's swapping Clerk's components and hooks for your own UI and Better Auth's client calls. You can do that incrementally by running both side by side during the cutover rather than in one risky switch.

Moving from Auth.js to Better Auth is the better-trodden route now, with an official migration guide. Developers are honest that it takes real planning, since the two model sessions and accounts differently, so it's a careful port rather than a find-and-replace. The upside is you're moving toward the actively developed library, not away from one. Either way, the lesson teams keep repeating is to pick the auth you can live with at scale earlier than feels necessary, because migrating auth is never the sprint you were hoping to run that week.

How Do You Choose the Right One?

Start with whether you're building new or maintaining old, then weigh speed against ownership.

Concrete scenarios. Brand new SaaS and you want to own your auth, your user data, and a flat cost curve? Better Auth. Racing to validate an idea and you'd rather not build sign-in screens this week? Clerk, and plan to revisit at scale. Already shipped on NextAuth and it's humming? Stay put, it's still patched.

The Verdict: Which Should You Use?

For a new project where you care about control and long-term cost, use Better Auth. It's free, it keeps your users in your own database, it has the modern feature set Auth.js never grew, and it's where the whole ecosystem is now heading. You pay for it in setup time and the UI you build yourself, but you own the result and the bill never surprises you.

Use Clerk when speed is everything and you're early. Nothing ships polished auth faster, the 50,000-user free tier carries you a long way, and the retained-user billing protects you from viral spikes. Just treat it as a fast on-ramp and know that the meter and the data-residency tradeoff are waiting past 50,000 users.

Stick with Auth.js only if you already run it. It's maintained for security, it works, and migrating a working app for no reason is wasted effort. But don't start anything new on it, because its own maintainers are telling you not to.

The honest meta-point is that the question got simpler this year, even if the marketing pages haven't caught up. It's own versus rent. Better Auth if you want to own your auth, Clerk if you'd rather rent it and move fast, and Auth.js only as the legacy you already happen to have. Pick on that axis, not on a benchmark or a logo. Wired up auth on one of these recently? Tell me how it went over on @devtoolpicks.

Best Firebase Alternatives for Indie Hackers in 2026 (Honest Picks)

DevToolsPicks — Fri, 26 Jun 2026 04:05:09 +0000

Firebase is brilliant right up until the invoice arrives. It gets you from zero to a working app faster than almost anything, and then one of three things sends you looking for the door: a surprise bill, a query you can't write, or the slow realization that you're locked into Google with no way out.

The bill is the big one. Firestore charges for every read, write, and delete, and the Blaze plan has no hard spending cap. A viral spike or a single bad loop can turn a $10 month into a few hundred dollars before you notice. Add the NoSQL data model that fights you on relational queries, and the fact that you can't self-host any of it, and the case for an alternative writes itself.

Good news: the options in 2026 are excellent. Here are five real destinations, what each actually costs, and who should skip it. My default recommendation is Supabase for most people, but the right pick depends on whether you need SQL, real-time, or the absolute lowest cost.

The Quick Verdict

Tool	Best for	Starting price	Data model
Supabase	The default move from Firebase	Free, then $25/mo flat	Postgres (SQL)
Convex	Real-time and collaborative apps	Free, then $25/developer/mo	Reactive documents
Appwrite	Closest open-source Firebase clone	Free, self-host free	Documents (MariaDB)
PocketBase	Smallest, cheapest projects	Free, you pay only hosting	SQLite (single binary)
Nhost	GraphQL-first teams	Free, then $25/mo	Postgres + GraphQL

Short version: Supabase for most apps, Convex if real-time is the product, Appwrite or PocketBase if you want to self-host, Nhost if you live in GraphQL.

Supabase

Supabase is the alternative most people land on, and for good reason. It's a real PostgreSQL database with auth, file storage, edge functions, and realtime subscriptions on top, all behind a clean dashboard with auto-generated APIs. Because it's actual Postgres, you escape the NoSQL constraints that pushed you off Firestore: joins, foreign keys, full-text search, and pgvector for AI embeddings all just work. It's open source, so you can self-host the whole stack if you ever want out.

The migration is genuinely smooth. Supabase ships a Firebase auth import tool that brings your users over with their password hashes intact, and both platforms map to a similar mental model. Most teams budget two to four weeks for a moderate app and report cutting their backend bill by 35 to 40% mainly by escaping per-read billing.

Pricing is the headline. Free tier ($0, with the catch that projects pause after 7 days of inactivity), then Pro at a flat $25 a month that never pauses, plus small compute and usage costs. That flat number is the whole point: you can budget against it, unlike Firebase's meter. For the relational Postgres side of the comparison, I went deeper in Supabase vs Firebase.

Who should skip it? If your app is fundamentally real-time and collaborative, Supabase's realtime is bolted onto Postgres rather than the default, so Convex will save you more work. And if you want raw serverless Postgres without the bundled auth and storage, a focused database like Neon or Turso may fit better, which I covered in Turso vs Neon vs Supabase.

Convex

If the reason you're leaving Firebase is that you're building something live, a collaborative editor, a multiplayer tool, a shared dashboard, Convex is the upgrade. It's a reactive backend where your queries and mutations are plain TypeScript functions, and any client subscribed to a query updates automatically when the data changes. No listeners to wire up, no read-counting to babysit. That's a real contrast with Firestore, where real-time listeners are exactly what drives your bill up.

It's fully typed end to end, includes file storage and vector search, and the free tier is generous: roughly 1 million function calls a month and up to 6 people on a team before you pay anything. There's also a startup program offering qualifying teams up to a year of Pro for free.

Pricing is $25 per developer per month on Pro. Read that carefully: a solo founder pays $25, but a three-person team pays $75, since it scales per developer rather than per project. I put it head to head with the incumbents in Convex vs Supabase vs Firebase.

Who should skip it? Anyone who needs SQL. Convex uses a proprietary document model, so there's no Postgres, no standard joins, and no existing ORM. Migrating a relational app to it is a rewrite, and leaving later means re-engineering your sync logic. If real-time isn't core to your product, that's a bad trade.

Appwrite

Appwrite is the closest thing to a true open-source Firebase. It bundles the same pieces you're used to, auth, database, storage, serverless functions, messaging, and realtime, and exposes them through REST, WebSocket, and GraphQL APIs. It runs as a managed cloud service or self-hosted with a single Docker command, which is the part Firebase can never offer. Its function runtimes cover 15-plus languages, and its Flutter and mobile SDK support is excellent, so mobile-first teams feel at home.

The data model is document-based, backed by MariaDB, which means migrating from Firestore's documents maps more cleanly here than to a SQL database. Pricing is where it gets attractive for a bootstrapped founder. Self-hosting costs only your own server. The free Cloud tier is genuinely generous: 75,000 monthly active users, and it never pauses. Paid Cloud plans start at roughly $15 per member per month, with a Scale tier for compliance needs.

Who should skip it? If your data is relational and you need real SQL with joins and complex queries, Appwrite's document model and beta-stage relations will frustrate you, and Supabase is the better home. Self-hosting also means you own uptime, backups, and updates, which is real ongoing work, not a free lunch. And its real-time offline sync isn't as deep as Firestore's, so a heavily offline mobile app may notice the gap.

PocketBase

PocketBase is the answer when you want the smallest possible backend. The entire thing, a realtime SQLite database, auth with OAuth2, file storage, an admin dashboard, and a REST-ish API, compiles into a single Go binary around 15 MB. There's no separate database server, no container orchestration, and basically no configuration. You drop the binary on a cheap VPS, run one command, and you have a backend that idles under 20 MB of RAM. For a side project or an MVP, nothing else is this lean or this cheap.

It's open source under MIT, and the cost is just your hosting. A small Railway or Hetzner instance runs it for a few dollars a month, and you can attach a persistent volume for the SQLite file and uploads. It powers plenty of indie SaaS products and internal tools in production today.

Who should skip it? Two honest cautions. First, it's still pre-1.0, so backward compatibility isn't guaranteed across versions and you'll occasionally apply manual migration steps when you upgrade. Second, it's single-node SQLite, so it scales up (a bigger server) but not out (no horizontal scaling or multi-region clustering). It's also a one-person project with no SLA or enterprise support. For a single-server app under moderate load, none of that bites. For something that needs high availability or massive concurrent writes, look elsewhere.

Nhost

Nhost is the pick for teams who prefer GraphQL. It pairs a PostgreSQL database with Hasura, which auto-generates a GraphQL API over your schema instantly, then adds auth, file storage, and serverless functions on top. If you'd rather query your backend with GraphQL than REST or a client SDK, this is the most direct path, and you still get real Postgres underneath with all the relational power that brings.

Like the others here, it's open source and self-hostable, so you're not locked in. Pricing follows the now-familiar shape: a free tier to start, then Pro around $25 a month as your usage grows.

Who should skip it? If your team doesn't actually want GraphQL, Nhost's main differentiator is wasted on you, and Supabase gives you the same Postgres foundation with a simpler REST and client-SDK workflow. Its ecosystem and community are also smaller than Supabase's, so you'll find fewer tutorials and integrations when you get stuck.

How Hard Is It to Migrate Off Firebase?

This is the question that keeps people stuck on Firebase longer than they should be. The honest answer is that it depends on where you're going, and the document-based options are the easier jump.

Supabase is the smoothest move despite being SQL, because it ships a dedicated Firebase auth import tool that brings your users over with their password hashes intact. Most teams budget two to four weeks for a moderate app. Appwrite and PocketBase use document and record models that map more directly from Firestore, so your data shape carries over with less reshaping, though you'll rewrite client code for the new SDK either way. Convex is the biggest mental shift, since you're rebuilding your backend logic as TypeScript functions rather than just moving data across. Whatever you choose, the real work is usually the client rewrite and re-testing your auth flows, not the data export itself. Export early, run both backends in parallel for a while, and cut over only once the new one is proven.

How Do You Choose the Right One?

Start with your data model and your appetite for managing infrastructure.

A few concrete scenarios. Building a normal SaaS with users, billing, and relational data? Supabase, almost every time. Building something live and collaborative? Convex. Want a Firebase-shaped backend you fully control? Appwrite if you need the full feature set, PocketBase if you want it tiny and cheap. Already standardized on GraphQL across your stack? Nhost.

The Verdict: Where Should You Go?

For most indie hackers leaving Firebase, move to Supabase. You get real Postgres, a flat and predictable $25 a month, a smooth migration with a dedicated auth import tool, and open source so you're never trapped again. It solves the three problems that pushed you off Firebase, the bill, the data model, and the lock-in, in one move.

Pick Convex if real-time is the product, not a feature, and you're happy with a TypeScript-native document model. Pick Appwrite if you want the closest open-source Firebase clone and you're willing to self-host for full control and a generous free tier. Pick PocketBase if you're shipping something small and want the cheapest, simplest backend that exists, just respect the pre-1.0 and single-server caveats. And pick Nhost if GraphQL is genuinely how your team wants to build.

The honest meta-point: the main thing you're buying when you leave Firebase is predictability and an exit. Every option here gives you both, a bill you can forecast and the ability to take your data and run. For more relational options beyond this list, see the best Supabase alternatives. Made the jump off Firebase? Tell me where you landed over on @devtoolpicks.

Bun vs Node vs Deno for Indie Hackers in 2026

DevToolsPicks — Thu, 25 Jun 2026 04:55:11 +0000

Every benchmark post will tell you Bun is four times faster than Node. The charts are real. They're also close to meaningless for the app you're actually building.

Here's the thing nobody leads with: once your request does real work, hitting a database, validating input, running your business logic, the gap between Bun, Node, and Deno mostly disappears. Independent tests of production-style apps put all three within a few percent of each other. The dramatic numbers come from benchmarks that respond to an HTTP request with an empty "Hello World" and nothing else. Your users don't pay you for empty handlers.

So the runtime choice in 2026 isn't really about req/s. It's about ecosystem fit, developer experience, security posture, and where you deploy. All three are genuinely production-ready now. And there's a fresh twist this year worth knowing before you pick: Anthropic bought Bun in December 2025, its first acquisition ever, and Claude Code now ships as a Bun binary. That changes the "is Bun safe to bet on" math in a way it didn't a year ago. Let me break down where each one actually wins, with the hype stripped out.

The Quick Verdict

Runtime	Best for	Engine	The catch
Node.js	Predictable production, deepest ecosystem	V8	Slowest raw speed, you assemble your own toolchain
Bun	Speed, CI, and developer experience	JavaScriptCore	~95% npm compat, rougher debugging, now Anthropic-owned
Deno	Security and edge functions	V8	Smaller ecosystem, permission flags add friction

Short version: Node is the safe default. Bun is the speed and DX upgrade. Deno is the security and edge specialist. Most indie hackers should stay on Node unless they have a specific reason to move.

Do the Benchmarks Even Matter?

This is the part to internalize before you read another comparison. There are two completely different stories depending on what you measure.

Synthetic benchmarks, the empty HTTP handler kind, show big gaps. Bun's startup-optimized JavaScriptCore engine pulls ahead, sometimes by multiples. Real-world benchmarks, where the handler parses a request, queries a database, and serializes a response, show all three converging to nearly the same number. The reason is simple: in a real app, your runtime isn't the bottleneck. Your database query is. A runtime that's "3x faster" at returning a string saves you nothing when 90% of the request time is spent waiting on Postgres.

Where speed differences are real and do matter:

Cold starts. Bun launches in roughly 8 to 15 ms, against Deno's 40 to 60 ms and Node's 60 to 120 ms. On serverless, that's a direct cut to your invocation latency and your bill.

Install and CI speed. Bun installs a fresh dependency tree in about a second where npm takes tens of seconds. Run that across every CI build and the time savings are real money.

So don't pick a runtime for its req/s. Pick it for cold starts if you're serverless, for CI speed if your pipeline is slow, or for ecosystem and stability if you just want to ship. Whatever you build on, it'll likely run one of Next.js, Nuxt, or SvelteKit on top, and those frameworks run on all three now.

Node.js

Node is the one that just works, everywhere, with everything. It's 17 years old, it runs the majority of backend JavaScript in production, and it owns the ecosystem outright. There's no "95% compatible" caveat because npm is Node's ecosystem. All 2 million-plus packages, every tutorial, every Stack Overflow answer, every APM tool. When something breaks at 3am, Node has the deepest pool of tooling and answers to pull from.

The current Long Term Support line is Node 24, released in October 2025, with a 30-month support window under the OpenJS Foundation. Node 24 also finally added native TypeScript execution, so you can run a .ts file directly without tsx or ts-node by stripping the type annotations before execution. That closes one of the few real gaps against Bun and Deno.

Who should skip it? If cold starts or CI speed are your bottleneck, Node is the slowest of the three and you'll feel it. It also leaves you to assemble your own toolchain: a bundler, a test runner, a TypeScript setup. Bun and Deno hand you those in the box. And the historical ESM versus CommonJS module friction, while much improved, can still bite on older packages. But for a normal SaaS where you want zero surprises and maximum hireability, Node is the boring, correct answer. As one developer put it, if you're a bank, use Node.

Bun

Bun is the speed-and-experience play, and in 2026 it's the most interesting of the three. It's built on JavaScriptCore, the engine behind Safari, with a core written in Zig, and it bundles everything into one binary: runtime, package manager, bundler, and test runner. No more gluing five tools together. It also ships built-in clients for Postgres, Redis, and S3, and Bun.serve for a fast HTTP server. Compatibility with Node sits around 95%, so Express, Fastify, NestJS, and ORMs like Prisma and Drizzle generally run unchanged. It runs natively on Windows and ARM64 now too.

The big 2026 development: Anthropic acquired Bun in December 2025. It was Anthropic's first acquisition, and the reason is direct. Claude Code ships as a single Bun executable to millions of developers, so Bun is the infrastructure their billion-dollar product runs on. Bun stays open source and MIT-licensed, the same team keeps building it in public, and Anthropic now has a strong incentive to keep it fast and stable. For anyone who avoided Bun because they worried a small startup might abandon it, that abandonment risk just dropped a lot. If you already lean on Claude Code as a solo developer, you're effectively running Bun already.

Want to try it without betting your production app on it? The low-risk path is to adopt Bun where speed is pure upside. Run bun install instead of npm, bun test instead of your test runner, and your dev scripts through Bun, while keeping Node in production. You get the CI and developer-experience wins right away, and you can switch the production runtime later once you've watched your metrics for a couple of days.

Who should skip it? It's still not Node-perfect. Some native C++ addons need workarounds, and developers report that chasing a memory leak or profiling a service is rougher than it is on Node, where the tooling is more polished. There's also a fair question about whether Bun's roadmap now tilts toward Anthropic's CLI priorities over general-purpose server needs. None of that is a dealbreaker for most apps, but test your full dependency tree before you migrate anything that matters.

Deno

Deno was built by Ryan Dahl, the person who created Node, specifically to fix the things he felt he got wrong the first time. Its headline feature is security by default. A Deno program starts with zero permissions: no file system, no network, no environment variables, until you explicitly grant them with flags like --allow-net. After the npm supply-chain attacks of 2025, that posture stopped looking paranoid and started looking smart. A compromised package can't quietly phone home if you never gave it network access.

Beyond security, Deno is the most complete toolkit out of the box. It runs TypeScript natively, follows web standards closely, and is the only one of the three that ships a built-in formatter and linter alongside its test runner. Deno 2 also fixed the thing that used to kill it for most people: npm compatibility. It now reads package.json, works with node_modules, and runs the large majority of npm packages directly. Pair that with Deno Deploy, its first-party edge platform with built-in KV storage, and you get a genuinely fast path to globally distributed functions.

Who should skip it? The ecosystem is still the smallest of the three. Compatibility is around 95%, so you'll occasionally hit a package that leans on native C++ bindings or obscure Node internals and needs --allow-all or a workaround. Fewer developers know Deno, which matters for hiring and for finding answers. And the permission model, while a security win, adds a little friction to everyday scripting. If security or edge deployment is central to what you're building, those tradeoffs are worth it. If not, the smaller ecosystem is a real cost.

Where Do the Three Actually Differ?

Strip away the marketing and the genuine differences come down to four things.

Dimension	Node.js	Bun	Deno
Cold start	Slowest	Fastest	Middle
Ecosystem	Deepest (100%)	~95% npm	~95% npm
Security model	Opt-in	None by default	Secure by default
Built-in tooling	Assemble yourself	All-in-one	All-in-one plus linter

One more thing has quietly changed the stakes. All three runtimes now implement a shared set of web-standard APIs through WinterCG, the community group standardizing things like fetch, Request, and Response across runtimes. Write a fetch handler today and it runs on Node, Bun, and Deno without changes. That turns runtime choice from a one-way door into an engineering tradeoff. You can develop on Bun for speed, test on Node for compatibility, and deploy a Deno edge function, all from the same codebase. The walls between these runtimes are lower than they've ever been.

How Do You Choose the Right One?

Start with your constraint, not the benchmark chart.

Concrete scenarios. Building a standard SaaS and you want to ship without thinking about your runtime? Node 24 LTS, every time. Starting fresh and you care about fast CI, quick cold starts, and not juggling five tools? Bun is a strong default now, and the Anthropic backing means it's a safer bet than it was. Handling sensitive data, running code you don't fully trust, or going edge-first? Deno's security model earns its keep. And wherever you land, your deployment target matters too, which I broke down in Railway vs Render vs Fly.io.

The Verdict: Which Should You Use?

For most indie hackers, use Node.js. Node 24 LTS is genuinely the best version ever shipped, it has native TypeScript now, and nothing else comes close on ecosystem depth, tooling, and the simple fact that everything works. Boring is a feature when you're a solo founder who needs to sleep.

Reach for Bun when speed and developer experience are worth a small amount of risk. Greenfield projects, performance-sensitive services, slow CI pipelines, and serverless functions where cold starts hit your bill all benefit. The Anthropic acquisition removed the biggest reason people held back, which was abandonment risk. Just test your dependencies first.

Choose Deno when security is a real requirement, not a nice-to-have. Fintech, healthcare, anything running untrusted code, or an edge-first architecture where Deno Deploy fits. The secure-by-default model and the cleanest built-in toolchain are the payoff for accepting a smaller ecosystem.

The honest meta-point is that the runtime war is basically over, and the winner is that you no longer have to pick just one. Thanks to shared web standards, you can develop on the fastest one, deploy on the most compatible one, and reach for the secure one where it counts. For a bootstrapped founder shipping a product, though, the simplest advice still holds: use Node unless you have a reason not to, and let the reason, not the benchmark, make the call. Running something interesting on Bun or Deno? Tell me how it's going over on @devtoolpicks.

Convex vs Supabase vs Firebase for Indie Hackers in 2026

DevToolsPicks — Wed, 24 Jun 2026 04:40:08 +0000

Picking a backend is one of the first real decisions you make on a new project, and it's annoyingly hard to reverse. Switch later and you're rewriting your data layer, your auth, and half your queries. So it's worth getting right the first time.

For most indie hackers in 2026, the choice comes down to three tools. Firebase is the old default from Google. Supabase is the open-source Postgres challenger that ate a huge chunk of Firebase's audience. And Convex is the newer entrant that does something neither giant does by default: real-time sync, baked in, with no WebSocket plumbing.

They look similar from the outside. Database, auth, file storage, serverless functions, all managed for you. But they're built on completely different foundations, and that difference shows up in two places that matter to a bootstrapped founder: how you model your data, and how your bill behaves when things go well. I've shipped on the Postgres side of this fence, so I'll be upfront about my bias and then give each one a fair shake. If you only want the two-way on the incumbents, I went deeper in Supabase vs Firebase. This post adds Convex and the real-time angle.

The Quick Verdict

Tool	Best for	Starting price	Data model
Convex	Real-time and collaborative apps	Free, then $25/developer/mo	Reactive documents (TypeScript)
Supabase	SQL apps and portability	Free, then $25/mo flat	Postgres (real SQL)
Firebase	Fast mobile and web MVPs	Free, then pay-as-you-go	NoSQL documents (Firestore)

Short version: Supabase is the safe, predictable default for most SaaS apps. Convex wins when real-time sync is the product. Firebase ships fastest but its bill is the least predictable of the three.

Convex

Convex is the interesting one because it isn't trying to be a managed database. It's a reactive backend. You write your queries and mutations as plain TypeScript functions that run inside Convex's own runtime, and any UI component that subscribes to a query updates automatically when the underlying data changes. No polling. No WebSocket server. No pub/sub setup. For a collaborative app, that's weeks of engineering you simply don't do.

It's fully typed end to end, includes file storage and vector search, and has built-in scheduling and cron for background jobs. The free tier is genuinely generous: roughly 1 million function calls a month, and you can have up to 6 people on a team before paying anything. There's also a startup program that gives qualifying teams up to a year of Pro for free.

Pricing is where you need to read carefully. The Professional plan is $25 per developer per month. That "per developer" matters. A solo founder pays $25. A three-person team pays $75. On top of that, heavy real-time workloads rack up usage costs: database bandwidth runs around $0.20 per GB and action compute around $0.30 per GB-hour, and EU regions cost 1.3x.

Who should skip it? Anyone who needs SQL. Convex uses a proprietary document model, so there's no Postgres, no joins the way you know them, no existing ORM, and no pgvector or row-level security. Migrating an existing Postgres app to Convex is a full rewrite, not a port. And because the reactive architecture is proprietary, leaving later means re-engineering your client-side sync logic. You're trading portability for a real-time superpower. If real-time isn't core to what you're building, that's a bad trade.

Supabase

Supabase is the one I reach for, and it's the one most indie hackers land on. The pitch is simple: it's a real PostgreSQL database with auth, storage, edge functions, and real-time subscriptions wired on top, all behind a clean dashboard with auto-generated APIs. Because it's actual Postgres, you get standard SQL, foreign keys, row-level security, and pgvector for AI embeddings. Nothing proprietary about the core. And it's open source, so you can self-host the whole thing on your own server if you ever want to.

The free tier is strong: 500 MB database, 50,000 monthly active users for auth, 1 GB file storage, and 2 projects. There's one catch you have to plan around. Free projects pause after 7 days of inactivity. Your data is safe and you can resume it, but anything user-facing can't live on the free plan. That's the nudge to Pro.

Pro is a flat $25 a month per organization, and that flat number is the headline. It includes $10 in compute credits that cover one Micro instance, so a single production app is effectively $25 to $35 all in. Unlike Convex, the base price doesn't climb with your team size. Where it does climb is compute per extra project and usage overages on bandwidth, so most real apps land around $35 to $75 a month once they have traffic. The Team plan jumps to $599 a month, but that's for SOC 2 and HIPAA compliance, not features you'll miss as a solo dev.

Who should skip it? If your app is fundamentally real-time and collaborative, Supabase's real-time is bolted onto Postgres rather than the default, so you'll do more setup than Convex asks for. Edge functions also have a noticeable cold start of a few hundred milliseconds after idle. And if you want raw serverless Postgres without the bundled auth and storage, a focused database like Neon or Turso may fit better. I compared those in Turso vs Neon vs Supabase, and there are more options in the best Supabase alternatives.

Firebase

Firebase is the original "backend without a backend," and it's still the fastest way to get a mobile or web MVP live. Auth, Firestore, hosting, cloud functions, analytics, and crash reporting all snap together, and the SDKs are everywhere. If your goal is to ship something this weekend and you're already in Google's world, nothing gets you to a working app faster.

The pricing model is the opposite of the other two. There are no tiers and no seats, just two plans. Spark is the free plan: 50,000 Firestore reads a day, 20,000 writes, 1 GB storage, and 50,000 monthly active users for auth, with no payment method required. Blaze is pure pay-as-you-go. It includes the same free allowances, then charges for usage above them: Firestore is $0.06 per 100,000 reads, storage runs a few cents per GB, and functions and bandwidth meter separately.

For a small app, that often means a $1 to $10 monthly bill, which is great. The problem is the shape of the model, not the rates.

Who should skip it? Anyone who needs to bound their spend. Firestore bills per operation, and Blaze has no hard spending cap. Budget alerts warn you, but they don't stop charges. Real-time listeners and AI features that re-read the same data amplify your read count fast, so a single user action can fire dozens of billable reads, and a viral day or a runaway loop can turn a $10 bill into hundreds before you notice. On top of that, Firestore's NoSQL model makes relational queries awkward, you can't self-host, and migrating off after a year of production is genuinely painful. The newer Data Connect feature adds a Postgres option, but it's still early. If you're selling a fixed-price subscription, an unbounded backend bill is the wrong foundation. There are calmer relational options in the best PlanetScale alternatives.

How Do the Three Actually Compare?

The marketing pages all promise the same thing. Here's where they genuinely differ.

Dimension	Convex	Supabase	Firebase
Data model	Reactive documents	Postgres (SQL)	NoSQL documents
Real-time	Default, no setup	Available, bolted on	Listeners, drives cost
Pricing model	$25 per developer	$25 flat per org	Pure pay-as-you-go
Self-host	Possible (open source)	Yes (open source)	No
Bill predictability	Medium	High	Low (no cap)

Two patterns fall out of that table. On data model, this is really a SQL versus document decision. If your data is relational and you think in tables and joins, Supabase is home. If your data is document-shaped and real-time is central, Convex or Firebase fit better. On cost, predictability runs Supabase, then Convex, then Firebase. The flat $25 is the easiest number to budget against, the per-developer model is predictable but scales with hiring, and the uncapped pay-as-you-go model is the one that can ruin a month.

What Does Each One Actually Cost?

Run the numbers for a real team and the pricing models separate fast. A solo founder pays $25 on any of the three paid paths, so cost isn't the deciding factor at the start. It changes when you add people. Convex charges per developer, so a three-person team is $75 a month and a five-person team is $125, before a byte of usage. Supabase holds its flat $25 base no matter how many people touch the project, with compute added per extra deployment. Firebase has no seats at all, so team size never moves the bill, only usage does, and without a spending cap that's the number you have to babysit.

So the cost story splits by who you are. A solo founder building real-time? The $25 on Convex is a non-issue and you get sync for free. A small team that plans to hire? Supabase's flat base is the cheapest to grow into, since hiring your fourth developer doesn't touch the bill. Shipping a throwaway prototype? Firebase on Spark is genuinely free until you scale, which is exactly when you switch on budget alerts.

How Do You Choose the Right One?

Start with your data, then layer in cost sensitivity and team size.

A few concrete scenarios. Building a collaborative editor, a live dashboard, or a multiplayer tool where state has to stay in sync? Convex saves you the most work, and as a solo founder the $25 is fine. Building a normal SaaS with users, billing, and relational data? Supabase, almost every time, because Postgres and a flat predictable bill are exactly what you want. Throwing together a mobile MVP this weekend to test an idea? Firebase will get you there fastest, just turn on budget alerts before you launch.

The Verdict: Which Should You Use?

For most indie hackers, Supabase is the default pick. Real Postgres, a flat $25 a month, open source so you're never trapped, and a feature set that covers the vast majority of SaaS apps. The 7-day free pause is the only sharp edge, and it disappears the moment you go to Pro. It's the safest long-term bet of the three.

Choose Convex when real-time sync is the product, not a feature. If you'd otherwise spend weeks building WebSocket infrastructure and state synchronization, Convex hands you that for free, and the TypeScript-native model is a genuine pleasure. Just go in knowing you're accepting a proprietary model and per-developer pricing as the cost of that speed.

Choose Firebase when raw speed to a first version matters more than anything else and you're comfortable in Google's ecosystem. It's the fastest on-ramp, and for a prototype that may never need to scale, the free tier is hard to argue with. The day it becomes a real business, set strict budget alerts and start watching your read counts, because the bill won't watch itself.

The honest meta-point: the best backend is the one that stays boring while your app gets interesting. For a bootstrapped founder, boring usually means predictable cost and an exit if you need one. That's why Supabase wins for most people, why Convex wins for real-time, and why Firebase asks for the most caution. Building something with one of these? Tell me which you picked over on @devtoolpicks.

Best Cursor Alternatives for Indie Hackers in 2026 (Honest Picks)

DevToolsPicks — Tue, 23 Jun 2026 04:25:09 +0000

SpaceX just bought Cursor for $60 billion. The deal was announced June 16, 2026, and it closes in Q3 once regulators sign off. If Cursor is your daily editor, nothing breaks tomorrow. The product keeps working. But the reason a lot of us picked Cursor in the first place just got complicated.

Cursor's whole pitch was that it stayed out of the model wars. You could point it at Claude, GPT, Gemini, or a local model and let the best one win. Now its owner is a frontier AI lab. SpaceX said plainly that it's training a model with Cursor to ship inside the editor and inside Grok Build. When the company that owns your editor also sells the model, the incentive to keep every option equal gets weaker over time.

We've watched access fights play out before in this space. So the honest question for a solo founder isn't "is Cursor bad now?" It isn't. The question is "which tools can't be quietly steered toward one lab's model?" That's the lens for this list. Six alternatives, real pricing, and a clear note on how independent each one actually is. I've grouped them so you can find your exit fast, whether you want a polished editor, a terminal agent, or something fully open. For the full breakdown of what the acquisition means, I covered it in the SpaceX and Cursor deal post.

The Quick Verdict

Tool	Best for	Starting price	Model independence
Windsurf (Devin Desktop)	Closest drop-in from Cursor	Free, Pro $20/mo	Model-flexible, Cognition-owned
Zed	Speed and low cost	Free, Pro $10/mo	Full, bring any key
GitHub Copilot	Staying in your current editor	Free, Pro $10/mo	Multi-model, Microsoft-owned
Claude Code	Terminal-first, top quality	Pro $20/mo, no free tier	Anthropic models only
Cline	Open agent inside VS Code	Free, bring any key	Full, bring any key
Aider	Git-clean terminal workflow	Free, bring any key	Full, bring any key

The short version: if you want the least painful switch, go Windsurf. If you want fast, cheap, and independent, go Zed. If model freedom is the whole reason you're leaving, Cline or Aider are the only picks nobody can steer.

Windsurf, Now Devin Desktop

This is the closest thing to a drop-in. Like Cursor, it's a VS Code fork, so your settings.json, keybindings, and extensions carry over with almost no friction. Cognition, the team behind the Devin agent, bought Windsurf and rebranded it to Devin Desktop on June 2, 2026. Same product, new name, and you'll see both labels for a while.

What makes it interesting beyond the move off Cursor: it ships Cognition's own SWE-1.6 coding model for free, and it still lets you reach for Claude, GPT, or Gemini when you want frontier quality. It also covers 40-plus IDEs including JetBrains, Vim, and Xcode, which Cursor never did. The standout feature is the Devin handoff: plan a task locally, click once, and a cloud agent finishes it while you review the result back in the editor.

Pricing matches Cursor now. Free tier, Pro at $20/mo, Max at $200/mo, and Teams at $80/mo base plus $40 per seat. It moved from credits to daily and weekly quotas in March, which most people find easier to reason about.

Who should skip it? If you want a settled, stable product, the constant renaming is a real annoyance, and the old Cascade agent reaches end of life on July 1, 2026, as Devin Local takes over. And remember Cognition trains its own models too, so this is model-flexible, not lab-neutral. I compared it head to head with the others in Cursor vs Windsurf vs Zed.

Zed

Zed is the one I'd hand most people first. It's not a VS Code fork. It's a fresh editor written in Rust with GPU rendering, and the speed is genuinely noticeable on big files. The editor itself is open source and free forever.

The AI is optional and that's the point. The free tier gives you 2,000 edit predictions a month plus unlimited use with your own API key. Pro at $10/mo adds unlimited predictions and some hosted credits. Either way, you can bring your own Anthropic, OpenAI, or Google key and pay the provider directly with no markup, or turn AI off entirely and just use a very fast editor. Through the open Agent Client Protocol, you can run Claude Code, Codex, or other agents right inside Zed.

At $10/mo it's half Cursor's price, and the bring-your-own-key option keeps you fully model-independent. Nobody owns the model you talk to.

The honest cons: the extension ecosystem is smaller, roughly 500 versus VS Code's tens of thousands, so check that the one plugin you can't live without is ported. There's no native Composer-style agent built in, so heavy agentic work runs through those external CLIs. And Windows support is newer than macOS or Linux. If you want the deepest agent baked into the editor, this isn't it. If you want speed, low cost, and control, it's hard to beat. See the full Zed 1.0 review for more.

GitHub Copilot

Copilot is the option people forget because it's been around the longest. It's not a separate app. It installs into VS Code, JetBrains, and Visual Studio, so there's no migration at all. And it grew up: it's now an agent, not just autocomplete, and it runs multiple models including Claude Sonnet, Claude Opus, GPT, and Gemini.

Pricing is the friendliest entry point here. Free covers 2,000 completions and 50 chat messages a month. Pro is $10/mo, Pro+ is $39/mo, Max is $100/mo, and Business is $19 per user. Copilot moved to credit-based billing on June 1, 2026. Plain code completions stay free, while chat, agent mode, and code review draw from a monthly credit pool. Students, teachers, and open-source maintainers get Pro for free.

The cons are real. Microsoft owns it and it leans on an OpenAI partnership, so you're trading one big owner for another, not buying independence. The new credit model means heavy agent users can run past their allowance and pay overage. And agent mode, while much better, still trails Cursor's Composer for big autonomous edits. One scheduling note worth checking: as of June 2026, new self-serve sign-ups for Pro, Pro+, and Max were temporarily paused and being re-enabled gradually. The Free tier and Business were not affected. I put it head to head with the rest in Cursor vs GitHub Copilot vs Claude Code.

Claude Code

If you're happy living in the terminal, Claude Code is the quality pick. It's Anthropic's command-line agent, and it's very good at multi-file work: reading a whole codebase, planning, editing across files, and running commands. There's no editor to learn because it isn't one. It runs in your terminal and plugs into your existing IDE.

The pricing is the best part if you already pay for Claude. There's no separate charge and no free tier. It comes bundled with a Pro plan at $20/mo, or Max at $100/mo and $200/mo for heavier use. Usage runs on a rolling five-hour window with a weekly cap, so a long session can hit a wall and make you wait. You can also pay per token through the API if you'd rather meter it.

The catch is the whole theme of this post. Claude Code only runs Anthropic's models. You can pick between Haiku, Sonnet, and Opus, but you can't bring GPT, Gemini, or a local model. So if your reason for leaving Cursor is "I don't want a model lab owning my tool," understand that you'd be swapping xAI for Anthropic. The quality is excellent and the value is strong if you're already in the Claude ecosystem. Just go in clear-eyed. For more options in this style, see the best Claude Code alternatives.

Cline

Cline is where the model-independence story gets clean. It's an open-source extension that installs into your existing VS Code, not a fork, so there's no migration and no learning curve for shortcuts you already know. It's a full agent: it plans, edits across files, runs terminal commands, and asks for approval at each step.

The economics are the draw. The tool is free under an open license. You bring your own API key for Claude, GPT, Gemini, xAI, DeepSeek, or a local model through Ollama, and you pay the provider directly with no middleman margin. A moderate user spends roughly $30 to $80 a month in API costs, and if you run a local model, the cost drops to zero. Because it's just a VS Code extension, it also works in Codespaces, remote SSH, and WSL.

The downsides come with the freedom. You manage your own keys and watch your own token spend, which the managed tools hide from you. There's no built-in tab completion, so it's an agent, not an autocomplete. Long agentic runs can burn tokens fast, and the agent still needs supervision because it can make wrong edits. If you want a polished, do-everything product, this asks more of you. If you want zero lock-in and any model you like, nothing beats it.

Aider

Aider is the terminal tool for people who love git. Every change it makes becomes a commit with a sensible message, so reviewing is just reading the log and undoing is just git revert. It's open source, free, and works with any model through your own key, including local models via Ollama, across more than 100 languages.

Cost is whatever your model provider charges. Regular use tends to land around $10 to $40 a month, and a local model is free. For a cost-conscious solo dev who already lives in the terminal, that's about as lean as AI coding gets.

There are two honest cons. First, it's terminal only, with no GUI and no diff panel to click through, which some people will hate. Second, development has slowed: the last repository update was May 22, 2026, and the model recommendations in its docs are dated, though you can still point it at any current model with a flag. The workflow is proven and stable, but if you want the most actively developed open tool, Cline or others ship faster. If a clean git history is your priority, Aider is still the gold standard. It pairs naturally with running models locally.

How Do You Choose the Right One?

Start with the form factor, then layer in how much you care about model independence. If you want to keep a polished GUI editor and switch with minimal pain, Windsurf is the drop-in and Zed is the faster, cheaper, more independent pick. If you'd rather drive an agent from the terminal, Claude Code wins on quality while Aider wins on cost and git hygiene. And if you want an open agent inside the editor you already use, Cline is the answer.

One more filter. If the entire reason you're leaving is that you don't want a frontier lab owning your tool, three of these actually solve that: Zed, Cline, and Aider. They let you bring any key, so no owner has a reason to push you toward one model. Everything else trades Cursor's owner for a different one.

The Verdict: Which Should You Switch To?

For most indie hackers who liked Cursor's editor, try Zed first. It's $10/mo or free with your own key, it's the fastest tool here, and it keeps you model-independent. That combination is hard to argue with.

If you want the closest thing to Cursor without relearning anything, install Windsurf, now Devin Desktop. Your settings carry over and the cloud agent handoff is genuinely useful.

If model freedom is the actual point, pick Cline for the VS Code workflow or Aider for the terminal. They're the only options on this list that nobody can quietly steer toward a house model, and both can run free on a local model.

And if you already pay for Claude and you're comfortable in a terminal, Claude Code gives you the best raw coding quality of the bunch. Just remember you're choosing Anthropic as your single lab, which is a fine choice as long as it's a choice you made on purpose.

Cursor isn't dead, and it won't get worse overnight. But the acquisition is a useful nudge to ask which tools in your stack you actually control. The cheapest insurance against the next acquisition is owning the keys to your own model. Switched off Cursor? Tell me what you landed on over on @devtoolpicks.