MeshKit

Designers who want 3D icons in their work have two options and both of them are bad.

• 01Download a static icon set that was never built for their brand and spend time trying to make it fit.
• 02Learn Blender, a full 3D software with a years-long learning curve, to customise something that should take minutes.

Neither option respects a designer's time. Neither produces a result that actually feels on-brand.

MeshKit fills that gap. It's a browser-native 3D icon customisation tool. Designers get access to a library of high-quality 3D icons they can adjust to their brand without touching any 3D software. Accent colour, material, roughness, light rotation, viewing angle. All adjustable. All rendering in real time in the browser. Export as a production-ready PNG in seconds.

The goal was never to be a lightweight Blender. It was to be the tool that makes Blender unnecessary for this specific use case.

Sesan is a 3D expert. When you understand how 3D assets are created at a deep level, the natural instinct is to expose that depth to the user. Give them control over every variable. Let them get the exact result they want.

That instinct was wrong for our user.

A product designer who has never opened Blender does not think in 3D parameters. Handing them a full suite of 3D controls does not feel like power. It feels like homework. So almost every significant product decision was a negotiation between Sesan's technical expertise and my read on what our user could actually work with.

Sesan's instinct was full lighting control. Saturation, brightness, multiple light sources. I pushed back. The core use case is an icon that looks good across different viewing angles, and light rotation is what makes that possible. When the viewing angle changes, the light source needs to move with it. A single rotation control gives users exactly that without handing them a lighting rig they don't have the context to operate. Meaningful control. Nothing unnecessary.

A 3D icon has multiple surfaces that could each hold a different colour. Sesan saw that as a feature. I saw it as a support ticket waiting to happen. We landed on a single accent colour users could adjust to their brand. The metallic elements stayed fixed. Not because they couldn't be made editable, but because they provided visual richness without requiring a decision from the user.

We gave users two modes. A set of fixed preset angles we defined ourselves (top right, top left, bottom right, bottom left, front, isometric) and a free rotation mode for Pro users. Free rotation was not Pro-gated because it was harder to build. It was Pro-gated because it produces more variable results. Presets give free users something that always looks good. Free rotation gives Pro users creative control alongside the responsibility that comes with it.

We kept roughness as a user-facing control even though it's a technical 3D term most designers wouldn't recognise. The reason: the visual feedback is immediate. Move the slider and the icon visibly shifts from matte to glossy. The label might be unfamiliar. The result is not. Sometimes you make a product decision backed by data. Sometimes you back it with a reasonable bet and ship it.

Three decisions defined how this product got built and how I work with AI as a build partner.

Before Figma was opened or a single line of code was written, I wrote a Product Requirements Document covering what the product does, who it is for, where the freemium line sits, and what is explicitly out of scope for v1. The PRD also became the AI context file for every Claude Code session. Claude has no memory between sessions. Loading the PRD at the start of every build session kept the AI in scope and kept me in scope when decisions got complicated mid-build. Scope creep in an AI-assisted build doesn't just come from the AI. It comes from you. The PRD is what pulls you back.

Once the visual direction was clear in Figma, I used the Figma MCP server to extract every design token directly into the codebase as CSS variables and a Tailwind config. The same system I designed in Figma ran in production code with no manual translation and no approximation.

Before building any page, I extracted each component's structure from Figma using the MCP server and handed that blueprint directly to Claude Code. Because everything was built with auto layout, the responsive structure translated cleanly into code without guesswork.

The key move: I prompted Claude Code to generate a dedicated showcase page inside the codebase where every component and every variant lived together. One place to preview, test interactions, and catch broken states before anything touched real data or a real page.

It caught problems immediately. Bugs that would have been buried under several more components were visible in isolation and fixable with a single prompt. Build components first. Verify on the showcase page. Wire to real data after.

I ran a full security audit on the database with Claude, working through every Row Level Security policy in Supabase and verifying what each one actually allowed versus what it was supposed to allow.

What the audit found was not minor. There was an open UPDATE policy on the users table. Any authenticated user could modify their own subscription tier directly. On a product where the entire business model depends on that gate holding, this would have been a silent revenue leak from day one.

The fix was surgical. The lesson was that assumptions about what is locked down are not the same as actually verifying it.

MeshKit ran a closed beta with 18 hand-selected designers before opening wider. The product held up. The security held up. The workflow delivered what we promised to people who had no reason to be patient with broken things.

It's now on a public waitlist ahead of launch with 25 designers signed up.

The case study doesn't end at beta. MeshKit is a live product with a business model, a paywalled Pro tier, and a launch coming.