renderlet

What do they actually do

Renderlet is building a way to package GPU-accelerated visuals as portable WebAssembly modules and run them inside other apps. Their open‑source runtime, wander, embeds into host applications and executes these “renderlets” in a sandbox, so teams can add high‑performance graphics without wiring platform‑specific rendering code for each OS or framework (wander on GitHub, v0.1.0 release).

Today, developers describe their graphics pipeline at a higher level (via code or a visual playground), compile it into a self‑contained Wasm module, and load it through the wander runtime in a desktop, native, or web app. In the current V1 model, host apps still bind some GPU details; the team is working toward WebGPU/WASI‑GPU so modules can draw directly to a canvas with less host‑side plumbing (playground, architecture/roadmap in repo, company site).

The company is early and focused on developer adopters and platform integrators. They’ve shared public demos/talks and list a small founding team in YC’s Winter 2024 batch (WasmAssembly talk, YC profile).

Who are their target customer(s)

• Engineers building desktop, web, or native apps that need custom, high‑performance visuals.: They have to write and rework platform‑specific graphics plumbing for every app, and must wire host GPU details themselves instead of dropping in reusable render modules (wander repo, renderlet.com).
• Game, CAD, and product‑visualization teams embedding real‑time render pieces into larger tools.: Integrating third‑party rendering logic forces per‑host changes and slows iteration, so teams either duplicate effort or avoid modular, reusable visuals (wander docs/examples, YC profile).
• Platform integrators and SDK maintainers who want plugins or extensions that draw inside their apps.: They worry about safety, performance, and the cost of supporting many shader/graphics implementations across OSes and runtimes; a sandboxed, portable approach lowers support burden (wander architecture/roadmap).
• Small studios and indie devs without dedicated graphics engineers.: Specialist GPU work is expensive, so creating polished, high‑performance visuals is slow or out of reach unless tooling raises the abstraction level (renderlet’s visual compiler/playground targets this gap — playground).
• Designers and artists who want editable, reusable visual building blocks rather than static assets.: Existing workflows often export flattened geometry that’s hard to tweak or reuse across platforms, reducing control once art is handed off to engineers (renderlet.com).

How would they acquire their first 10, 50, and 100 customers

• First 10: Run hands‑on pilots with teams already exploring Wasm/GPU by watching the open‑source repo and outreach; co‑implement one renderlet in their app, fix initial host plumbing, and convert pilots to short paid engagements and public case studies (wander GitHub, playground).
• First 50: Turn pilot patterns into templates, one‑page guides, and sample renderlets for verticals (e.g., product viz, CAD, simple game UI) and use them in direct outreach and workshops; amplify with deep‑dive demo videos showing real integrations (talk/demo).
• First 100: Publish lightweight plugins/SDKs for common host platforms (desktop frameworks, game engines, web) with a clear paid support path; grow community channels and tutorials for self‑serve adoption, and highlight the roadmap toward full WebGPU/WASI‑GPU rendering (site, wander roadmap/docs).

What is the rough total addressable market

Top-down context:

The 3D rendering/visualization software market is estimated in the low single‑digit billions and growing quickly; for example, Fortune Business Insights cites ~$2.7B in 2023 growing to ~$9.6B by 2030, while Global Market Insights estimates ~$4.4B in 2023 (Fortune Business Insights, Global Market Insights).

Bottom-up calculation:

If 5,000 organizations that embed custom GPU visuals adopt a commercial package (support, integrations, and tooling) at $10k–$20k per year, that implies a $50M–$100M TAM for an initial wedge; expanding to 25,000 orgs yields $250M–$500M.

Assumptions:

• Pricing averages $10k–$20k annually per org for support/tooling, with higher tiers for platform partners.
• 2,500–10,000 target orgs immediately addressable across game, CAD, product viz, and platform SDKs; longer‑term 25,000+.
• Adoption is driven by portability/sandboxing (Wasm/WebGPU) reducing per‑platform GPU work in host apps.

Who are some of their notable competitors

• bgfx: Cross‑platform, graphics‑API‑agnostic rendering library used to build custom engines; teams might choose bgfx to hand‑roll an embeddable renderer instead of packaging Wasm modules (bgfx repo, docs).
• Google Filament: A lightweight, embeddable PBR rendering engine for Android, iOS, desktop, and WebGL; an alternative for apps needing a small, high‑quality renderer (Filament site, GitHub).
• Unity as a Library: Lets developers embed the Unity runtime inside native apps to render 3D/AR features, offering another path to integrate graphics into host applications (Unity page, docs).
• Rive: Cross‑platform runtimes for interactive vector animations used in apps, games, and the web; relevant for the UI/animation building‑blocks use case (Rive Runtimes, GitHub runtime).
• Babylon.js: A mature, web‑first 3D engine with WebGPU/WebGL support; web apps might use Babylon directly for cross‑platform graphics without Wasm render modules (site, docs).