I'm not a developer. I've never written a function by hand. Over about seven weeks I built pixelrealestate.homes: one shared map of 30,000 plots where every plot someone claims turns into a building in a three.js city you can fly around. The owner's picture goes on a billboard on the roof.
All the code was written by Claude. My job was describing what I wanted, clicking through the result, and saying "no, that's wrong" a lot. This post is the honest version: what the thing is, what went wrong, and what I learned about building with AI when you can't read the code.
Preview render: the city once all 30,000 plots are taken. Today there are 8 houses.
What it is
- A 202×202 grid. Minus roads, parks and civic buildings, that leaves exactly 30,000 plots.
- 5 districts in rings, from Outer Ring to Core District. Edge plots start at $50, the centre goes up to a few thousand.
- Prices aren't set by hand. One formula: distance from the centre plus how much of the district is already taken.
- Claim a plot and you get a building, a card with your name/link/description, a certificate with a QR code at a permanent URL, a share image, and a view/click counter. Edits are free.
- You can try your picture on a roof for free first. Nothing gets uploaded, no sign-up.
Trying a picture: the camera flies to a free plot and puts it on the roof. Only you see it.
Stack: three.js, Netlify functions, Supabase (Postgres + auth), Resend for email, Dodo Payments for checkout.
The 3D part
The city is one three.js scene sized for all 30,000 plots. Buildings are instanced (one InstancedMesh per material and shape), so even the fully built preview is a few dozen draw calls. Each district has a height band, and the random spread is skewed low, so most buildings sit near the bottom of their band and only a few reach the top. That's what makes a skyline instead of an even carpet. There are 10 building shapes (courtyard, cross, L-shape, setback and so on), and empty plots get one of 8 ground types picked by noise.
Things that broke along the way:
Shadows. One directional light with a shadow camera covering the whole city. Zoomed out it looked fine. Zoomed in, every shadow edge was a staircase, because one shadow texel covered about 3 screen pixels. The fix: the shadow box follows the camera in a few fixed sizes and snaps to texels, so edges don't crawl when you move. Phones get no real-time shadows at all.
The first-frame freeze. Opening the 3D view froze the page for seconds. The cause: shader compilation (~4 s) and the bloom post-processing pass on the very first frame. On top of that, the city was rendering at 60 fps underneath the hero video, which is why the video stuttered. Main-thread time went from about 20 s to 7 s once the city only renders when it's actually visible and warms up in idle time.
Windows. At one point I noticed every building had exactly 32 rows of windows, whatever its height. A two-storey house at the edge looked like a ten-storey tower with a little hat on top. The window texture just didn't know how tall the building was.
Now the windows follow each building's height.
The bugs that actually cost me
The 3D bugs were visible. The expensive ones weren't.
The waitlist nobody could reach. Before payments were live, I had a waitlist. 755 visits, 1 signup. I assumed nobody cared. Then we found the real reason: a visitor who clicked "Buy" got a login form. The waitlist panel sat behind a check that only logged-in users ever passed. The server side was fine the whole time. The button just never led there.
Drag-and-drop deploys. Uploading files to GitHub by dragging them into Chrome on Windows once mixed up names and contents. The URL for city3d.js was serving the contents of admin.html. I only caught it by comparing checksums of every file.
Images. Owners' pictures were loading at full size: about 1.75 MB per visitor, on a free database plan with 5 GB of monthly traffic. Serving resized thumbnails through Netlify's image CDN cut that to about 0.23 MB.
What I learned about building with AI
- The model is confidently wrong in ways I can't catch by reading code. I can't read code. So I learned to check results instead: open the live page, click through it on my phone, ask for the actual server response, not a summary.
- Even the checking can lie. Once Claude told me the image CDN was broken. It turned out only its own fetch tool was getting a 400. Real browsers were fine. Now every live check happens in a real browser.
- Stale copies are dangerous. Once a whole code review was done on an old copy of the files, and it reported bugs that were already fixed. Now every change starts by comparing against what's actually deployed.
- A second pair of eyes, every time. Before each deploy a separate AI agent with no context reviews the change. It catches something almost every time.
- Ask "is this already there?" before building. I asked for a feature that had already existed for days, and got it built twice.
Where it is now
Honestly: 8 houses on the map, and all 8 are plots I gave away so people could test the whole flow. Nobody I don't know has bought one yet. Getting a payment provider to approve a solo project took weeks, and the first one said no.
So I'd love blunt feedback. Does the 3D run OK on your machine? Is "flat map to buy, 3D city to look at" clear? What would make you want a plot, and what puts you off?
You can fly straight to a house with a link like pixelrealestate.homes/#fly-69-113.
Disclosure: Claude drafted this post from our work log, and I approved it before posting.
Top comments (1)
tr.ee/dev-to