NekoCAD

Every maker who outgrows Tinkercad runs into the same three doors. Fusion wants an account and caps what its free tier can do. SolidWorks and Onshape want a subscription or your files on their servers. FreeCAD is free and open and takes a weekend to learn how to fillet an edge without breaking the model. None of them are bad, they are just built for somebody else.

NekoCAD is built for the maker. It takes the SolidWorks way of working, a sketch, constraints, a feature tree you can roll back, and drops the parts a person with a 3D printer in the garage does not need: no PDM, no drawings-first workflow, no subscription wall. You buy it once, it works without an internet connection, and the files are on your disk.

A proof of concept in a day

The first version took a day. A Rust engine compiled to WebAssembly, a React front end, a Tauri shell, and by the next day assemblies with mates and in-context part editing. That was enough to prove the idea was not crazy, and not enough to ship, so I started the platform over as one monorepo and kept the design.

The rebuild is where the LLMs came in. Agents write most of the code. My job moved to the parts they are bad at: deciding what gets built and in what order, writing the plan as numbered task batches small enough to check, and reading what comes back. Every merge gets a line in a history log, every commit goes through a gate script, and every worktree gets its own Docker stack so two agents can work on two features without fighting over one database. The result is 2,184 commits and roughly 480,000 lines of Rust, TypeScript and PHP, tests included, which is not a number I could have typed by hand in the time it took.

One engine, two shells

The geometry is OpenCascade, the same kernel FreeCAD uses, compiled to WebAssembly and run in a Web Worker. Around it sits a set of Rust crates, also compiled to WebAssembly: the sketch constraint solver, the document engine with the assembly and mate solver and undo history, DXF and SVG reading, licensing, and the 3D-print supports. The TypeScript types are generated out of the Rust, so the two sides cannot quietly disagree.

That engine runs unchanged in the Electron desktop app and in the browser. One UI, one kernel, one file format, with a frozen corpus of .nko files that every change has to open the same way.

Past 4 GB in a browser tab

WebAssembly gets 4 GB of memory by default, and a real board file blows through that. The test case is the Raspberry Pi 5 STEP model: 142 MB, 3,469 solids. So I forked occt-wasm and added a Memory64 build, then threaded builds on top of that. It ships four variants now, 32 and 64 bit each with and without threads, and the loader falls back from one to the next when a build will not start.

Threads make large rebuilds about twice as fast, and they cost cross-origin isolation, which means the right COOP and COEP headers in Electron, in the Vite dev server and on Cloudflare Pages. The .wasm is loaded by URL rather than bundled, because OpenCascade is LGPL and a user has to be able to swap in their own build. The Pi 5 board still takes 59 seconds to read in WebAssembly, which is why a native OpenCascade build for the desktop app is the next big question on the list.

References that survive a rebuild

The hardest problem in parametric CAD is not making geometry. It is knowing, after you change a sketch, which face is still "the top face" that the fillet was attached to. Those rules started in TypeScript and moved into Rust for speed. The catch is that a rule which picks a different face is a broken model, so the port has to match the TypeScript to the last bit.

JavaScript numbers and Rust f64 are both IEEE doubles, so the formulas keep the TypeScript's order of operations. Where V8 and Rust compute a function differently (hypot, atan2, cbrt, min, max) the Rust carries a port of V8's own code. An oracle test rebuilds the demo and corpus files both ways, and 293 of 295 come out the same.

Made for the print

A maker does not stop at the model, so the slicer prep is in the app. Auto orient, resin and FDM supports, eleven raft types, hollowing with drain holes and suction-cup detection, and a one-click setup for when you just want it to work. The output has to read as manifold in PrusaSlicer, and the support behavior was tuned by measuring what Lychee exports.

A company of one

NekoCAD is the first business I've set up from nothing. NekoCAD LLC has its own bank account, EIN and D-U-N-S number, kept apart from everything else I do, because a product people pay for should not share a checking account with my side projects.

• Hosting. nekocad.com and a locked-down staging copy run as Docker Compose projects on one dedicated server for $39 a month. The browser app is on Cloudflare Pages, downloads come out of a Worker, and database backups go to R2 on a timer.
• Build. GitHub's free runners ran out of disk, so CI runs on my own machine. It builds the Linux AppImage, deb and Flatpak, builds and signs the Windows installer from Linux, installs each package and opens a file through its file association, and fails the release if startup gets slower.
• Selling it. A Laravel site with passkeys and Discord, Google and GitHub sign-in, Stripe for checkout, Ed25519-signed license files the app checks offline, and Discord roles that show your founder number.

Where it is

The app is in early access and the site is in waitlist mode. Sketching, solids, the feature tree, assemblies with mates, STEP and SOLIDWORKS part import, STEP, STL and 3MF export, the hole wizard, the supports, licensing and the release pipeline are all built. Launch is December 2, 2026, on a $6,000 budget, with a $49 founders license capped at 1,000 seats. Live collaboration and the native kernel are planned and not started.

The mascot in the corner of the viewport is Moe, the same cat neko was named after. Moe did not help with any of it.