SolidJS for Entrepreneurs: When Tiny+Fast Beats Mainstream (and When It Doesn't) in 2026

SolidJS is the JavaScript framework solo founders should reach for when bundle size, time-to-interactive, and Core Web Vitals are the binding constraint on the business, and the one they should explicitly avoid when the binding constraint is hiring speed, enterprise SDK coverage, or the size of the talent pool in their city. The trade is real: SolidJS ships a ~7KB gzipped runtime with no virtual DOM and fine-grained reactivity that consistently lands in the top three of the JS Framework Benchmark, but it costs you a hiring pool roughly one hundred times smaller than React and an ecosystem that is a year or two behind on enterprise B2B SDK coverage. This page is the founder-decision wrapper around that trade. You will leave knowing whether to pick SolidJS today, when to use it as part of a hybrid stack, how to ship your first landing page in a weekend once you've decided, what the bundle-size math actually means for your marketing funnel, and what to tell investors and future hires when they ask why you picked the framework with 5,000 LinkedIn engineers instead of the one with 600,000.

SolidJS for entrepreneurs: when it earns vs when it drags

The founder math: SolidJS is a stack decision that costs you a smaller hiring pool today and repays you in Web Vitals, in customer-perceived speed, and in marginal CDN bandwidth at scale. The wrong moment to make that trade is when you are pre-PMF, hiring contractors weekly, and shipping a complex dashboard your team has never built before. The right moment is when you have a marketing surface where speed is part of the brand, or a post-PMF SPA where the perf budget is starting to show up in churn data. Most founders make this decision twice: once badly (picking SolidJS for the whole stack because it's beautiful) and once well (picking SolidJS for the surface where 7KB matters and staying on the boring framework everywhere else).

Who this page is for (and who it isn't)

This page is written for three specific founder types, in order:

1. The technical co-founder of a two-to-five-person team. You write the code and you also do customer calls. Your time is the company's most expensive resource. Every framework decision is also a time-budget decision. You have heard SolidJS is fast, you have heard the runtime is tiny, and you want to know whether either of those facts is actually relevant to the business you are building this quarter.

2. The bootstrapped solo founder optimizing for Core Web Vitals. You are one person, you are shipping a marketing site or a small SaaS, and you have noticed that organic traffic is your cheapest channel. Google's Core Web Vitals are now a ranking signal, your bounce rate on mobile is high, and you are wondering whether a different frontend framework actually buys you back a few percentage points of organic CTR. The honest answer is yes, sometimes, on the right surfaces.

3. The senior engineer about to start a company. You know React. You have shipped Next.js to production five times. You are now asking a different question: not "is SolidJS faster than React" (you know it is) but "is the perf delta worth giving up the React job market, the React SDK ecosystem, and the React contractor pool for the next two years?" This page treats that question with the seriousness it deserves.

This page is not for:

• Engineers evaluating SolidJS on technical merit. For the framework-vs-framework deep dive go to our SolidJS alternatives roundup, which compares Solid against React, Vue, Svelte, Qwik, Astro, Preact, Lit, Alpine, Marko, Stencil, and Mithril on bundle size, reactivity model, SSR, ecosystem, and hiring. This page deliberately does not duplicate that material.

• Teams running an Angular shop deciding whether to migrate. The Angular head-to-head lives in our Angular vs SolidJS comparison, with real JS Framework Benchmark numbers, the RxJS vs signals reactivity story, and the Angular Universal vs SolidStart SSR comparison. The short version for entrepreneurs is below in the FAQ; the long version is the sibling page.

• Office workers evaluating SolidJS for an internal tool. That framing (the "should we use Retool instead" honest disclosure for an office team) lives in our SolidJS for office workers guide. Different persona, different decision, different answer.

• Solo remote developers building solo projects. That persona has its own guide at SolidJS for remote workers; we cross-link in the footer.

The page is structured so a founder can skim the H2 list, jump first to "When SolidJS is NOT the right pick" (the contrarian framing nobody else on the SERP offers), and decide whether the rest of the page is worth reading. If you decide it isn't, the time saved is the page's job.

When SolidJS IS the right pick for an entrepreneur

The honest section first: three founder situations where SolidJS earns its keep, and one bonus where it is the surprising-but-correct pick.

Marketing sites and landing pages where Web Vitals affect CAC

This is the textbook case. You are running a paid acquisition campaign at a $5 CPM. You are also competing for organic rankings on a half-dozen long-tail queries. Both channels punish a slow site: paid ads have higher quality-score costs when the landing page LCP is over 2.5 seconds, and organic rankings now incorporate Core Web Vitals (LCP, INP, CLS) as a confirmed ranking signal as of Google's 2024 page-experience refresh.

SolidJS ships ~7 KB gzipped of runtime. A React landing page ships ~45 KB minimum (react + react-dom) plus the framework hydration overhead. On a 3G mobile connection with 400ms RTT, that 38 KB delta is roughly 250-400ms of additional script-parse + hydration time, on top of the network transfer. In Lighthouse, that is the difference between a 75 and a 92 on Performance. In Web Vitals, it is the difference between LCP 2.8s and LCP 1.9s on the median mobile visit.

Translate to dollars: if your marketing site converts at 3% and you ship 10,000 paid visitors per month at a $2 CPC, that is $20K of paid traffic and $600 of revenue at $20 average ticket. Improving Web Vitals to "Good" tier typically lifts CTR on organic by 5-15% and improves conversion by 2-5% across the cohort that landed slowly. Even the low end of that range pays for the framework decision inside a quarter.

The same math holds for SEO-driven content sites, founder-led blogs, comparison hubs, lead magnets, and any other marketing surface where the page is shipped to a cold visitor and every millisecond of LCP is competing with the back-button.

Post-PMF SaaS with a known-shape SPA and a real performance budget

The second textbook case. You have paying customers, the application UI shape is roughly stable, and your APM tool is starting to show that the largest contributor to perceived slowness is not the API (you fixed that last quarter) but the frontend bundle + JavaScript execution on mid-range Android devices. Your support inbox carries the phrase "the app is sluggish on my phone" more than once a week.

SolidJS's fine-grained reactivity does not allocate a virtual DOM tree on every state change. It compiles your JSX into direct DOM updates against the specific signals that changed. For a dashboard with 200 reactive cells that update on every tick of a websocket feed, the difference between React's reconciliation and Solid's direct-update path is measurable in single-digit milliseconds per render, which compounds into noticeable smoothness over a 10-minute session.

This is not a marketing benchmark. You can measure it yourself with the JS Framework Benchmark by krausest, which has been running since 2017. SolidJS sits at or near the top of the create / update / swap rows. React sits mid-pack. The delta is small for trivial UIs and meaningful for dashboard-style applications with many reactive subscriptions.

The migration is not all-or-nothing. The pattern that works for entrepreneurs: rewrite the single hottest screen first (the dashboard, the editor, the realtime feed, whichever your APM shows as 60% of frontend CPU), measure the perceived-speed delta over two weeks of customer usage, and decide whether to continue. Most founders find one of two outcomes: either the single rewrite paid for the entire migration and the rest is budget-positive, or the savings were smaller than expected and the right call is to stop and put the energy elsewhere. Both outcomes are useful information.

Micro-frontends and embeddable widgets where every KB ships on every load

If your business model includes embedding a widget on customer sites (a live-chat box, an embeddable booking form, a tip jar, an analytics overlay, an opt-in form, a comments thread), the framework choice is no longer about your site. It is about every site your widget ships on. Every KB of runtime is multiplied by every page view on every customer's site.

A React-based widget that ships 45 KB of runtime on 10,000 customer sites at 100K page views per month each = 45 TB of CDN bandwidth per month spent on framework code that does nothing the user sees. A SolidJS widget at 7 KB ships 7 TB. The CDN bill delta is real money, and the customer-perceived speed of your widget (the only impression your customers' customers have of your product) is dramatically better.

This is the case where SolidJS is the obvious pick and where switching costs are low (widgets are usually self-contained, the team only has to be productive in Solid on one small surface). Founders in the embed business should bias hard toward SolidJS or Preact for this category of work.

The hybrid stack: React on the app, SolidJS on the marketing site

This is the surprising-but-correct pick that most senior founders converge on by year two. The dashboard and the customer-facing app live on React because the team can hire React engineers, the SDKs (Stripe, Auth0, Segment, Sentry, Algolia) ship React SDKs first, and the ecosystem of admin templates, design systems, and component libraries is unbeatable. The marketing site, the landing pages, the docs, the changelog, the blog (every public surface where speed is the brand) live on SolidJS or SolidStart.

This is not architectural sophistication for its own sake. It is two teams of two with different objectives. The app team optimizes for customer feature velocity. The marketing team optimizes for organic CTR and LCP. Each team picks the framework that matches its objective. The boundary is the URL: app.example.com runs React, example.com runs SolidStart. They share a design system through CSS variables and a shared component-library token file, not through a single framework runtime.

The honest tradeoff: two stacks doubles the operational surface. You need to maintain two build pipelines, two CI configurations, two deploy targets, two error-monitoring integrations. If your team is one engineer, do not do this. If your team is three or more, the cost is manageable and the perf wins on the marketing side typically pay for the doubled overhead inside two quarters.

When SolidJS is NOT the right pick for an entrepreneur

The honest section, second. Most pages selling a framework save the caveats for paragraph 47. This one leads with them because the wrong pick costs you the company, and the right pick at the wrong moment costs you the launch.

The hiring pool is genuinely one hundred times smaller than React's

Let's name the numbers honestly. As of mid-2026:

• LinkedIn US, "React" skill filter: ~600,000+ engineers with React on their profile.
• LinkedIn US, "SolidJS" skill filter: under 5,000 engineers. The actual number fluctuates around 3,000-4,500 depending on the day.
• Stack Overflow tag question counts: reactjs ~480,000 questions; solid-js ~2,000 questions. That's a ~240x ratio.
• NPM weekly downloads (2025-2026): react ~30+ million; solid-js ~250-300 thousand. Roughly a 100x ratio.
• State of JS 2024: React retention ~83%, awareness ~99%; SolidJS retention ~88% (higher!), awareness ~57%, usage ~7%.

Two things are true at once. SolidJS has the highest retention of any modern JS framework (engineers who use it tend to love it), and SolidJS has a hiring pool that is roughly one to two percent the size of React's. For a founder, only the second fact actually constrains the calendar.

If you are hiring your first three engineers, the practical question is: can you fill three SolidJS roles in your city or in your remote market in under 90 days at a salary you can actually pay? For most cities, the answer in 2026 is no, or only with senior engineers willing to learn on the job (which works, but adds two weeks of ramp). For React, the same three hires close in 30-45 days at a wider salary band.

The mitigation is the "we hire React engineers and teach them Solid" pattern. This works. A senior React engineer who has done their own side projects in Vue or Svelte typically ramps on Solid in a week of focused work. The cost is the week of ramp plus the friction of recruiters not knowing how to source for "React engineer interested in Solid"; you will write the screening questions yourself.

Enterprise B2B SDK coverage lags by one to two years

When you sell into enterprise B2B, you integrate. You integrate with Auth0, Okta, Stripe, Segment, Snowflake, Salesforce, Hubspot, Intercom, Zendesk, Sentry, Datadog, Algolia, Pendo, FullStory, and twenty more. Each of those vendors ships an SDK. Almost all of them ship a React SDK first, a Vue SDK second, and a vanilla-JS SDK eventually. SolidJS support is either community-maintained, behind in version, or non-existent.

This is not a SolidJS criticism. It is a market-position fact. When you build a B2B SaaS that integrates with twelve enterprise tools, every integration written against a community-maintained SDK is a maintenance cost you carry forever. For a founder, that cost is hidden until you scale. It shows up as a half-day of engineering time every time one of those vendors ships a breaking change and the community SDK has not been updated.

If your product is integration-heavy (an MDM tool, a CRM, an observability platform, a security tool, a data integration platform), the SDK reality is a binding constraint. React on the app, SolidJS on the marketing site is the right hybrid. SolidJS on the whole stack is not.

The library ecosystem is a year or two behind

There is no SolidJS equivalent of Material UI at full parity. There is no SolidJS equivalent of react-hook-form's footprint. There is no Storybook-native plugin ecosystem at React's depth. There are excellent SolidJS libraries (solid-primitives, solid-aria, kobalte, solid-headless, solid-router, @modular-forms/solid) and they cover the common cases well. But "common cases well" is not the same as "every case with seventeen options for every common case."

For a founder, this matters most when you need to ship a specific feature in a specific week and you do not have time to build the abstraction from scratch. React has a library for every five-minute feature. SolidJS has a library for every twenty-minute feature. The delta is real time on your calendar.

Two-week MVP with a complex dashboard your team has never built

If your runway requires you to ship a working dashboard in two weeks, do not introduce a framework your team has never used. The Solid mental model is genuinely different from React's. The signal/effect/derived-signal/store reactivity model is cleaner once you internalize it, but the first week is friction. The error messages are good but unfamiliar. The dev tooling is fine but smaller. The Discord community is excellent and small.

A React team ships the same dashboard in two weeks because they know the patterns. The SolidJS dashboard ships in three weeks because the team learned for one. That third week is the difference between making your demo and missing it. Pick the boring framework for the deadline-bound work. Save the new framework for the next greenfield surface where the calendar is not the constraint.

The bundle-size math: what 7KB actually buys you as a founder

Bundle size is not an abstract engineering concern. It is a marketing-funnel cost. Translate.

Runtime sizes, gzipped, as shipped to production in 2025-2026:

A real production landing page is more than the runtime; you ship your own components, Tailwind output, fonts, images, an analytics snippet. The framework runtime is a floor under all of that. On a 5 KB-of-your-own-code landing page, switching from React (45 KB framework + 5 KB yours = 50 KB) to SolidJS (7 KB framework + 5 KB yours = 12 KB) is a 4x reduction in total JS shipped. On a 100 KB-of-your-own-code application, the same switch is 12% less JS, not 75% less. The framework choice matters most on the lightweight surfaces.

Translate to Web Vitals. Google's Core Web Vitals thresholds for "Good" tier as of 2026:

• LCP (Largest Contentful Paint): under 2.5 seconds
• INP (Interaction to Next Paint): under 200 ms
• CLS (Cumulative Layout Shift): under 0.1

LCP is the metric most directly affected by JS bundle size, because the main thread is blocked parsing and executing JS before the largest content element renders. On a median 3G mobile connection with 400 ms RTT and 1.6 Mbps throughput, the 38 KB delta between React and Solid runtime costs roughly 300 ms of network time + 50-150 ms of parse/compile time + variable hydration time. That is the difference between LCP 2.6 (Needs Improvement tier) and LCP 2.1 (Good tier) on a real-world mobile visit.

Translate to organic CTR. Google has confirmed page-experience signals (Web Vitals "Good" status) as a ranking factor since 2021, with the weight increasing through subsequent core updates. Pages in the "Good" tier vs the "Needs Improvement" tier on LCP typically see 4-10% better organic CTR on the same query at the same average position, controlling for title-tag and meta-description quality. The exact lift varies by query competitiveness, but the directional effect is real and documented in case studies across Search Engine Land, Backlinko, and Google's own developers.google.com case studies.

Translate to dollars. For a marketing site doing 50,000 organic visits per month at a 3% conversion rate and $50 ARPU on first conversion: 1,500 conversions × $50 = $75,000/mo. A 7% organic CTR lift compounds into roughly an extra $5,000/mo of revenue, all else equal. That alone funds the framework decision indefinitely.

This is the math the SERP top-3 does not surface. None of the official tutorials, the LogRocket intro, or the This Dot Labs fundamentals post translates the 7 KB number into a marketing-funnel cost. SolidJS for the right surface is one of the highest-ROI technical decisions a founder can make. SolidJS for the wrong surface (a complex internal dashboard your team has never built) burns the same ROI on hiring friction.

Install SolidJS and ship your first landing page in a weekend

Real walkthrough. Real commands. Saturday-Sunday, two evenings.

Saturday morning: scaffold

Open a terminal. You need Node 20 or later.

npm init solid@latest weekend-launch

The CLI walks you through choices. For a marketing landing page, pick:

• Template: with-tailwindcss
• TypeScript: yes (the slight overhead pays back in maintainability)
• SolidStart: yes (you want SSR for SEO; SolidStart is the SolidJS meta-framework, like Next.js for React)

When it finishes:

cd weekend-launch
npm install
npm run dev

You now have a SolidStart dev server at http://localhost:3000 with hot-module reload. Open the project in your editor. The structure:

weekend-launch/
├── src/
│   ├── routes/
│   │   └── index.tsx       # your landing page lives here
│   ├── app.tsx
│   └── entry-client.tsx
├── public/
├── package.json
└── tailwind.config.cjs

Saturday afternoon: hero, value prop, email capture

Edit src/routes/index.tsx. Replace the default content with a three-section landing page:

import { createSignal } from "solid-js";

export default function Home() {
  const [email, setEmail] = createSignal("");
  const [status, setStatus] = createSignal<"idle" | "submitting" | "done">("idle");

  async function submit(e: Event) {
    e.preventDefault();
    setStatus("submitting");
    await fetch("/api/subscribe", {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({ email: email() }),
    });
    setStatus("done");
  }

  return (
    <main class="min-h-screen bg-white text-slate-900">
      <section class="mx-auto max-w-3xl px-6 py-24 text-center">
        <h1 class="text-5xl font-bold tracking-tight">
          Ship faster with a 7KB framework
        </h1>
        <p class="mt-6 text-lg text-slate-600">
          SolidJS for founders who care about Core Web Vitals.
        </p>
      </section>

      <section class="mx-auto max-w-3xl px-6 py-16">
        <h2 class="text-3xl font-semibold">Why founders pick SolidJS</h2>
        <ul class="mt-6 space-y-3 text-slate-700">
          <li>One-tenth the bundle size of React.</li>
          <li>Lighthouse 95+ on the marketing site, day one.</li>
          <li>Real signals reactivity. No virtual DOM tax.</li>
        </ul>
      </section>

      <section class="mx-auto max-w-md px-6 py-16">
        <form onSubmit={submit} class="flex flex-col gap-3">
          <input
            type="email"
            placeholder="[email protected]"
            value={email()}
            onInput={(e) => setEmail(e.currentTarget.value)}
            class="rounded border border-slate-300 px-4 py-2"
            required
          />
          <button
            type="submit"
            disabled={status() === "submitting"}
            class="rounded bg-slate-900 px-4 py-2 text-white"
          >
            {status() === "done" ? "Thanks!" : status() === "submitting" ? "Sending..." : "Get the playbook"}
          </button>
        </form>
      </section>
    </main>
  );
}

What is happening here:

• createSignal is the SolidJS primitive for reactive state. email() is the getter, setEmail(value) is the setter. Calling email() inside JSX is what subscribes that JSX cell to the signal: when setEmail runs, only that cell re-runs. No virtual DOM, no component re-render.
• The <input value={email()}> is a controlled input bound to the signal.
• The onSubmit handler posts to /api/subscribe. We'll wire that up next.

Saturday evening: the API route

SolidStart supports server functions and API routes out of the box. Create src/routes/api/subscribe.ts:

import { APIEvent } from "@solidjs/start/server";

export async function POST(event: APIEvent) {
  const { email } = await event.request.json();
  // pipe to your ESP — Resend, Loops, Mailchimp, or the campaign engine
  await fetch("https://api.resend.com/emails", {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${process.env.RESEND_KEY}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      from: "[email protected]",
      to: email,
      subject: "Thanks for signing up",
      html: "<p>You're on the list.</p>",
    }),
  });
  return new Response(JSON.stringify({ ok: true }), {
    headers: { "Content-Type": "application/json" },
  });
}

Put your Resend key in .env:

Restart npm run dev. Submit the form. Inbox.

A note for any reader running campaign infrastructure: every real email send (including the welcome message above) should go through your campaign engine, not a raw transactional endpoint. The example uses Resend's transactional API for clarity in a docs context. In production, you would post to your Listmonk campaign, your n8n workflow, or whatever orchestrator owns rate-limiting and webhook tracking for your sends.

Sunday morning: SSR + meta tags + favicon

Edit src/app.tsx to add the meta tags that drive SEO and social shares:

import { MetaProvider, Title, Meta } from "@solidjs/meta";
import { Router } from "@solidjs/router";
import { FileRoutes } from "@solidjs/start/router";
import { Suspense } from "solid-js";
import "./app.css";

export default function App() {
  return (
    <Router
      root={(props) => (
        <MetaProvider>
          <Title>Ship faster with a 7KB framework</Title>
          <Meta name="description" content="SolidJS for founders. Lighthouse 95+, day one." />
          <Meta property="og:title" content="Ship faster with a 7KB framework" />
          <Meta property="og:description" content="SolidJS for founders. Lighthouse 95+, day one." />
          <Meta property="og:image" content="https://yourdomain.com/og.png" />
          <Suspense>{props.children}</Suspense>
        </MetaProvider>
      )}
    >
      <FileRoutes />
    </Router>
  );
}

Sunday afternoon: deploy to Vercel

npm install -g vercel
vercel

The CLI walks you through linking a project. SolidStart's Vercel adapter is automatic in modern versions. The first deploy takes about a minute. You get a *.vercel.app URL.

Test it on PageSpeed Insights. You should see Performance 95+, LCP under 1.8 s on the mobile profile, INP under 100 ms. That score is what you would have spent the weekend trying to claw out of a React + Next.js scaffold by removing client-side JS, configuring next/image carefully, and deferring third-party scripts. SolidStart gives it to you out of the box because the runtime is one-sixth the size.

Buy your domain on Cloudflare or Porkbun. Add it in the Vercel project settings. Done. You have a real marketing site live on the internet by Sunday evening.

Real SolidJS code for founder use cases

Beyond the landing page, the patterns you actually need for an early-stage company.

createEffect for analytics + side effects

import { createSignal, createEffect } from "solid-js";

const [user, setUser] = createSignal<{ id: string; email: string } | null>(null);

createEffect(() => {
  const u = user();
  if (u) {
    // pipe to your analytics — PostHog, Plausible, or your own pipeline
    fetch("/api/analytics/identify", {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({ userId: u.id, traits: { email: u.email } }),
    });
  }
});

createEffect runs once on creation and re-runs every time any signal it reads changes. The dependency tracking is automatic. There is no equivalent of React's useEffect([deps]) array; SolidJS infers the deps from the actual reads.

createResource for async data with Suspense

import { createResource, Suspense, ErrorBoundary } from "solid-js";

function CustomerCount() { const [count] = createResource(async () => { const r = await fetch("/api/customer-count"); if (!r.ok) throw new Error("count fetch failed"); return r.json() as Promise<{ count: number }>; });

return ( <ErrorBoundary fallback={(err) => <span>Couldn't load count.</span>}> <Suspense fallback={<span>Loading...</span>}> <span>{count()?.count.toLocaleString()} happy customers</span> </Suspense> </ErrorBoundary> ); }

`createResource` is the SolidJS primitive for async data fetching. It integrates with `Suspense` for streaming SSR (SolidStart streams the resource result to the client as it resolves) and `ErrorBoundary` for error UX. This is the pattern you use for any signed-out marketing data (logos, testimonials, counters, blog posts) and any signed-in dashboard data (account profile, billing status, usage).

### Stripe checkout status with `createResource` + polling

```tsx
import { createResource, createSignal, onCleanup } from "solid-js";

function CheckoutStatus(props: { sessionId: string }) {
  const [tick, setTick] = createSignal(0);
  const interval = setInterval(() => setTick((t) => t + 1), 2000);
  onCleanup(() => clearInterval(interval));

  const [status] = createResource(tick, async () => {
    const r = await fetch(`/api/checkout/${props.sessionId}`);
    return (await r.json()) as { paid: boolean; receipt_url?: string };
  });

  return (
    <div>
      {status()?.paid ? (
        <a href={status()?.receipt_url}>View receipt</a>
      ) : (
        <p>Waiting for payment confirmation...</p>
      )}
    </div>
  );
}

This is the post-Stripe-checkout pattern every SaaS needs. The customer comes back from Stripe Checkout with a session_id in the URL. You poll /api/checkout/:id every two seconds until the Stripe webhook updates the server-side status to paid. The pattern uses tick as the resource's source signal: every time tick changes, the resource re-runs. onCleanup (the SolidJS equivalent of a teardown hook) clears the interval when the component unmounts.

SolidStart server functions for the "Saturday demo" pattern

"use server";

import { db } from "~/lib/db";

export async function getDashboardStats(userId: string) {
  const rows = await db.query(
    "SELECT count(*)::int as total, sum(amount)::int as revenue FROM events WHERE user_id = $1",
    [userId],
  );
  return rows[0];
}

A SolidStart server function lives in a file with "use server" at the top. You import it directly into a client component and call it like a regular async function; SolidStart handles the RPC plumbing. This is the pattern that gets a solo founder from "I want a dashboard" to "I have a dashboard" in an afternoon, without standing up a separate backend.

Hiring SolidJS engineers in 2026: the honest numbers

This section is the one nobody else on the SERP writes. Names, numbers, sourcing channels, the realistic 90-day hire plan.

The pool, sized

• LinkedIn US "SolidJS" skill: ~3,000-4,500 engineers. The number fluctuates because LinkedIn's skill matcher is imperfect; the true pool of engineers who can write production SolidJS in 2026 is likely closer to 8,000-15,000 globally.
• Stack Overflow solid-js tag: ~2,000 questions cumulatively. By contrast, reactjs has ~480,000.
• NPM weekly downloads, solid-js: ~250,000-300,000 per week. By contrast, react ~30+ million.
• GitHub stars, solidjs/solid: ~33,000+ (steadily climbing since 2022).
• State of JS 2024: SolidJS retention 88% (highest of any framework), awareness 57%, usage 7%. The retention is real: engineers who try Solid tend to keep using it.

Where to actually source

• Solid Discord (linked from solidjs.com). The most concentrated source of Solid engineers willing to take a contract or full-time role. Post a focused, well-described role in the #jobs channel. Expect 3-8 quality replies within a week.
• Solid Twitter/X community. Ryan Carniato, the framework author, is active and engaged. The community follows him; tagging him on a tasteful hire post often surfaces signal-boost from the maintainer cohort.
• GitHub. Search "language:TypeScript created:>2024-01-01" and filter by repos that depend on solid-js. Reach out cold to authors of well-starred small Solid projects.
• Solid Hack participants. The annual Solid hackathon ships projects publicly; the participant list is your best founder-aligned candidate pool.

The "React engineer who learns Solid" pattern

This is the realistic plan for most founders. The hire is a senior React engineer with 5+ years of JS framework experience, comfort with TypeScript, demonstrated curiosity about non-React frameworks (Vue, Svelte, Solid side projects in their GitHub history), and willingness to ramp on Solid for one week of paid learning.

The ramp takes one focused week. The official tutorial at solidjs.com/tutorial is two evenings. Building the weekend-landing-page above is the third evening. Reading the SolidStart docs is the fourth. Shipping one real component into production is the fifth. By week two the new hire is productive on real features.

Sourcing this candidate is easier than sourcing a "five-year SolidJS engineer" by an order of magnitude. The screening question that filters correctly: "What is the most interesting non-React framework you have used, and what did you learn from it?" Engineers who have an actual answer (Svelte's compiler, Solid's signals, Vue's composition API, Qwik's resumability) ramp faster.

The contractor / fractional path

If you do not want to hire full-time, the contractor pool is also small but viable. Toptal lists fewer than 50 SolidJS engineers globally (as of 2026). Independent contractors are sourced through the Discord, through Twitter, or through Solid Hack alumni networks. Day rates run $600-$1,200 USD for senior engineers (broadly in line with senior React contractor rates; the SolidJS specialization commands neither a premium nor a discount in the current market).

Fractional CTO arrangements with a Solid specialist are rare but available. Three to five fractional CTOs in the US market take Solid-shop engagements as of 2026; reach out through the Discord with a specific scope and expect a four-to-six-week engagement minimum.

The founder-economics framework

Every framework decision is a $/customer decision. Name the variables explicitly.

Dev time. The first SolidJS project is 20-40% slower than the equivalent React project because the team is ramping. The third SolidJS project is roughly the same velocity as React, sometimes faster because the mental model is cleaner. If you are shipping 30 projects, the ramp amortizes. If you are shipping three, it doesn't.

Runtime cost. SolidJS uses less CPU per render than React because it skips the virtual-DOM diff. On a typical dashboard, the delta is 10-30% lower CPU during high-frequency state changes. For most early-stage founders, this is invisible (your traffic is too small for runtime cost to matter). For post-PMF founders at 10K+ DAU, it shows up as a marginal cloud bill reduction.

CDN bandwidth. The 38 KB framework runtime delta times your page views = real bandwidth. At 10 million page views per month, the delta is 380 GB of CDN egress. On Vercel Pro at $40/100 GB after the first 1 TB free, this is roughly $150/month saved. Not a fortune. Not nothing.

Web Vitals → organic CTR → CAC. Already covered above. The most important economic input on the marketing surface. A 5-10% lift in organic CTR is the difference between profitable and unprofitable on a content-led growth motion.

Hiring marginal cost. The cost of the next engineer. React: $0 incremental (the pool is huge). SolidJS: roughly two weeks of recruiter time plus an extra $5-10K in retained-recruiter or job-board spend per hire. Multiplied by your hiring plan, this is real money. A 5-engineer team built on SolidJS-only carries a ~$25-50K excess hiring cost over the same team built on React. Worth it if the perf advantage maps to revenue. Not worth it if the perf advantage is on a surface that doesn't move the funnel.

Ecosystem coverage. Already covered above. The B2B SDK reality and the library reality.

The framework decision is a portfolio of these inputs. There is no universal answer. The founders who reason about these inputs explicitly make better picks than the founders who copy the framework choice of the last podcast they listened to.

For the framework-vs-framework comparisons, defer to the dedicated pages: Angular vs SolidJS covers Angular shops considering the switch with real JS Framework Benchmark numbers and the RxJS vs signals reactivity comparison; SolidJS alternatives covers the 12-framework directory including React, Vue, Svelte, Qwik, Astro, Preact, Lit, Alpine, Marko, Stencil, and Mithril with hiring data and migration paths for each; SolidJS for office workers covers the office-internal-tool framing with the honest Retool/Glide disclosure; SolidJS for remote workers covers the solo-remote-developer persona. This page owns the founder-decision frame and routes to those siblings for the tool-vs-tool diligence.

FAQs

Is SolidJS production-ready for a startup in 2026?

Yes. SolidJS hit 1.0 in 2022 and the 1.x line has been stable through 1.9 (September 2024) with no breaking changes that touch the public API. Production users include Cloudflare (internal admin tooling), Wattpad (frontend surfaces), and dozens of mid-sized SaaS companies. The framework is MIT-licensed, free, maintained by a small but active core team led by Ryan Carniato, and shipped on production sites continuously since 2020. The hiring pool is the binding constraint, not the framework's maturity.

SolidJS vs React for a founder: which one wins?

It depends on the surface. On the marketing site, landing pages, and any public surface where Core Web Vitals affects CAC, SolidJS wins. On the dashboard, the app interior, and any surface where SDK coverage and hiring speed dominate, React wins. The smartest founders in 2026 are running both: React on app.example.com, SolidJS on example.com. If you can only run one, default to React for breadth unless your specific business model (embedded widget, content-led growth, performance-critical SaaS) makes the Solid advantage decisive.

SolidJS vs Vue vs Svelte: short comparison

Vue (~34 KB) sits between React and Solid on bundle size and has the second-largest hiring pool. It is a fine pick for a founder who wants a smaller framework than React without the SolidJS hiring tradeoff. Svelte compiles components out, so trivial components ship near-zero runtime, but a real Svelte app with SvelteKit ends up shipping a runtime comparable to SolidJS in practice. The hiring pool is smaller than React's, larger than SolidJS's. The right pick among these three is workload-dependent and team-experience-dependent; for the full head-to-head, our SolidJS alternatives page goes line-by-line.

Can I build a real SaaS app in SolidJS, or is it only for landing pages?

You can build a real SaaS in SolidJS end-to-end. The framework supports everything a React app supports: routing (SolidRouter), forms (@modular-forms/solid), state management (signals + stores, no Redux needed), data fetching (createResource), SSR + SSG (SolidStart), authentication (community libs + your auth provider's vanilla SDK), styling (Tailwind, CSS modules, CSS-in-JS), testing (Vitest, Solid Testing Library). The constraints are real but not fundamental: ecosystem coverage is thinner, enterprise SDK support lags, and you will write more from scratch than on React. For most founders, the right answer is "yes you can, and you probably should not unless the perf advantage maps directly to your business model."

Is the SolidJS hiring market a deal-breaker for a Series A company?

Mostly no, partially yes. For a 3-5 engineer team in a major city, hiring 1-2 SolidJS engineers is feasible inside 90 days. For a 20+ engineer team that needs to hire 5 in a quarter, the pool is genuinely too small. The path that works at Series A is hybrid: keep React for the app, use SolidJS strategically on marketing + embeddable surfaces, hire React engineers and teach the few who need to work on the Solid surfaces. Most Series A founders do not need to commit the entire frontend stack to one framework; the hybrid stack lets you have both the React hiring pool and the SolidJS performance wins.

What is SolidStart and do I need it for my landing page?

SolidStart is the SolidJS meta-framework, equivalent to Next.js for React. It provides server-side rendering, file-based routing, server functions, and the deploy adapters for Vercel, Netlify, Cloudflare Pages, and Node. For a marketing site that needs SEO (where the page must be server-rendered so Google reads the content), SolidStart is the right choice. For a pure client-rendered SPA (the post-login app interior where SEO does not matter), plain SolidJS without SolidStart is lighter. Most founders end up using SolidStart for everything because the SSR cost is small and the routing/server-functions ergonomics are excellent.

Related reading

• Angular vs SolidJS: comparison head-to-head
• SolidJS alternatives: 12-framework directory
• SolidJS for office workers
• SolidJS for remote workers
• Official SolidJS site
• SolidStart docs