A homepage people
scroll through, not past.
A real three-dimensional scene in the browser, lit and animated, that responds to the scroll. Built from a conversation and deployed to your own domain, on the same stack as any other site you would ship.
WebGL in the browser, no plugin, no app
What the scene is actually made of
Describe the scene. Watch it compile.
The hard parts of 3D on the web are the version mismatch and the client boundary. Both are handled before the code is written.
Describe the site and the scene
What the product is, and what should be moving on the homepage. A floating object, a camera that travels, a model that turns as you scroll.
The model gets made
Generate the 3D object from a prompt or an image, or bring your own. It lands in the scene rather than in a folder you have to wire up.
The scroll drives it
Scroll position becomes camera position, rotation, and reveal timing, so the page reads as one continuous move instead of a series of jumps.
Deploy to your domain
The scene compiles, the build is verified, and the site goes to your own Vercel account with SSL. Same deploy as any other site here.
Built by people who have seen this build break
Real 3D, and the guardrails that keep it shippable
A spinning cube is easy. A 3D site that builds, loads on a phone, and does not blow up on deploy is the actual work.
Motion, not a still render
The camera moves, objects animate every frame, and the scroll drives the whole sequence. That is what separates a 3D site from a 3D picture.
Models from a prompt
Describe the object or hand it an image and get a real 3D model in the scene. No marketplace hunting and no license to read.
Configure it, and pull it apart
Swap colours and materials, explode the product into its parts, and turn it as you scroll. Built as one path with its own rules, because the obvious version of each of those ships code that runs and quietly does the wrong thing.
The version check comes first
WebGL libraries break hard across major versions. The builder reads your project's React version before writing code, because a wrong guess is a failed build.
The client boundary is handled
WebGL cannot render on a server. Getting that wrong fails the build in a way that reads as nonsense, so the rule is applied when the component is written.
It compiles before you pay
Your actual scene is built and checked before a paid deploy, not after. A dependency mistake costs you a retry rather than a deploy.
Still a normal website
Auth, a database, billing, and the rest of the stack are all there. The 3D is the hero, not the whole architecture.
The same builder, pointed at a scene
This is the SaaS website builder with a 3D playbook, not a second product to learn. The stack, the deploy, and the pricing are identical. What changes is that the hero is a real WebGL scene that reacts to the scroll instead of a picture of one.
3D is the case that adds a dependency, and a new dependency is the most common way a build breaks. So the builder reads your package.json for the React version before it writes a line, pushes your files before verification runs, and compiles the real scene before a paid deploy rather than after it.
Ready when you are
Give people something to scroll through
Describe the product and the scene. Get a real 3D homepage on your own domain, built on a stack you could hand to any developer.