Building RootFit: From Weekend Spike to EVE Frontier Fitting Tool

RootFit is a browser-based ship-fitting planner for the EVE Frontier Root hull. You lay out modules on the hull's grid, manage power, watch the stats update, and share the whole fit as a URL — before you spend a single material building it in-game. It lives at fit.ef-map.com, and it was never planned as a product. It started as a question on a free weekend and turned into something useful because we shipped it early and let real players find the edges.

This is the honest version of how that happened: what was quick, what was actually hard, and where the good ideas came from (mostly other people). If you want the EF-Map family precedents, RootFit borrows lessons from the Solar System View build journey and the Blueprint Calculator.

It started as a research question, not a product

There was an older repo that began life as our March 2026 EVE Frontier hackathon planning-and-research workspace. The hackathon was long over, so we did some housekeeping: the hackathon-era planning and strategy material got archived as history, and the repo was reframed as a current research workspace — upstream contract references, feasibility notes, and durable conventions, all kept tidy and read-only.

That cleanup mattered more than it sounds. Because the workspace carries a vendor collection of the upstream EVE Frontier world-contracts and docs, an agent working in it can reason from a real source of truth instead of from memory and vibes. (For the curious, that workspace is public: Sui Playground.)

So the real prompt for the weekend was simple: with a bit of free time and some spare inference, what is the highest-value quick win we could actually ship? The research came back with a concrete recommendation and an engineering brief — a standalone web app at fit.ef-map.com to plan a Cycle 6 Root-hull fit. That brief is the closest thing RootFit had to a spec.

Why a fitting tool, of all things

A few things lined up. The world contracts were relatively static at that moment, so there wasn't a moving target underneath us. Meanwhile, the development cycle was heavily focused on new in-game UI layers and systems — including a brand-new in-game fitting tool. That made fitting the obvious thing for players to reach for and understand immediately: if the game just gave everyone a fitting screen, a fast planner around it is something people will actually use.

The other obvious candidate was overlay work — more plumbing, more moving parts, less immediately legible to a player. A fitting planner looked like the higher-value weekend project: small surface area, instantly recognizable, and genuinely useful to anyone theorycrafting a build. (If you remember the old EVE Online "EFT" theorycrafting culture, that's the spirit.)

The spike was quick. The interactions were the work.

The first spike really was fast — a matter of hours on the Saturday morning. Enough to resemble the in-game layout, render a grid, and let modules be placed. If we'd stopped there and called it done, it would have been a convincing screenshot and a useless tool.

One thing did go better than the research expected. The brief assumed we'd be hand-authoring module footprints from screenshots, because earlier feasibility work guessed the geometry wasn't in extractable static data. It turned out the EVE Frontier client ships a Cycle 6 data domain with the real footprints, hardpoints, powergrid values, stat modifiers, and the Root hull itself. So RootFit pivoted to a fully data-backed catalog — every value matched the operator's in-game screenshots — rather than an estimate. The build beat its own spec on day one, which is a recurring theme: you don't actually know what's true until you try it.

After that, the next stretch was all interaction quality, and it took far longer than the spike:

• Exact grid, not a mockup. We replaced an approximate silhouette with the exact union of the real hull parts — a 478-cell grid composed from the game's own part offsets, rendered to match the in-game fitting screen (thin orange part outlines, a crisp placement grid, modules as bright-outlined shapes).
• Placing and moving. Click-to-place, drag-to-move a placed module, R to rotate (90°, no mirror), Esc to cancel, with a ghost preview that snaps exactly to where a click will commit.
• Honest feedback. A green wash showing where a module can actually go, collision against the hull mask, and the real mustBeInRoot constraint for root-only modules.
• Lifecycle rules. Hardpoint providers and the exterior modules that mount on them, one-per-ship caps, and a default loadout you can hydrate with one click.

Shipping early, and Cunningham's Law

We pushed the MVP public early — merged, deployed, and attached to fit.ef-map.com on the Sunday — knowing it was rough. The reasoning was Cunningham's Law: the fastest way to find what's wrong with your thing is to put it in front of people, because someone will immediately tell you. That's far cheaper than one person trying to manually smoke-test every shape and rule.

It worked almost instantly. Two good examples:

• Irregular footprints had hidden valid spots. A player pointed out that the green "valid placement" wash didn't show everywhere a module could actually fit — the Weapon Receiver was the flagged case. Its footprint is a diamond whose top-left corner is empty, so its anchor can legally sit outside the hull while every occupied cell is inside it. Our highlight only searched anchors on in-hull cells, so it dropped those placements. The fix recovered 57 previously-missing cells in exactly the three regions the player called out.
• A cap we'd guessed wrong. We had capped the Power Generator at one per ship — purely a guess. Live-game feedback confirmed you can fit multiple. So we uncapped it (Propulsion Engine, Command Pod and Weapon Receiver stay one-per-ship, which is correct). That's a fact we'd have taken far longer to discover alone.

The humble caveat: shipping early only helps if the thing is worth clicking in the first place. Feedback is a reward for building something people want to poke at. A broken toy nobody opens generates no edge cases.

Making the wait feel alive

RootFit has an Optimize Space feature that repacks your fitted modules to free up the largest usable open block, proving the result rather than guessing. Done correctly, that search can take several seconds.

The first version was correct but invisible — clicking Optimize Space just… flipped a label a few seconds later. It felt broken. We'd already learned this lesson on EF-Map itself, where route generation animates the hops being explored so a slow solve reads as "working," not "frozen." (If solver visualization is your thing, see A* vs Dijkstra pathfinding.)

So RootFit borrowed the idea. While the optimizer searches, the grid shows a cool-teal "probe" — the layout currently on the workbench — trailing a few fading recent attempts, plus a warm-amber "best so far." A small progress pill shows the live counts. The layout it finally applies is identical; the visualization changes nothing about the answer. But a 10–20 second wait stopped being "is this broken?" and became something you can watch develop. We later reused the exact same overlay for Try Add Modules.

Screenshot import: a good idea that wasn't reliable enough

A tempting feature: let players import an existing fit straight from a screenshot. We genuinely built it — a local, deterministic computer-vision pipeline running in a Web Worker (no cloud, no LLM, no per-use cost): threshold the orange/white/grey, find the part grid, fill the white module outlines into occupied cells, then template-match each blob against the known catalog footprints.

It worked — in limited ways. Isolated, distinctive modules (Power Generator, Propulsion Engine, Weapon Receiver, Fuel Bay, and friends) matched exactly. But the failure modes were real and stubborn:

• Dense, touching modules over-segmented — early on, a "fragment sink" where a cluttered region shredded into a pile of false small modules.
• Different resolutions, crops, full-screen captures versus tight snips, and hull registration all moved the goalposts.
• Large edge-flush modules and the antenna were the worst case; an asymmetric placement could even pick the wrong vertical flip.

We could have shipped it anyway and let it quietly invent modules that weren't there. Instead we were honest about it and pivoted to Trace Fit: put the screenshot behind the grid, scale and align it (with a rough auto-align and fine scale control), and place the modules over the top yourself. It asks the human to do the one thing humans are great at — recognizing shapes — and lets the tool do the part it's reliable at: enforcing the rules. Less magical, more useful, and it never lies to you.

Try Add Modules: straight from Reddit

The next feature came from a single Reddit comment. A player pointed out that Optimize Space only rearranges what's already fitted — it can't answer the question people actually ask: "take my current fit and try adding +6 of this and +2 of that; can you make them fit?"

Rather than overload Optimize Space (the name implies rearranging, and its scorer was carefully tuned and tested), we built a separate workflow: Try Add Modules. You open a basket, pick the extras you want (cap-aware, with a "fits now" readout per row), and the packer tries to fit your current modules plus the requested extras. It runs in three stages — a fast greedy pass for the common "there's room" case, a bounded re-pack for the genuine "rearrange to make space" case, and a best-effort partial otherwise. The same live probe visualization plays while it searches, and you get an amber preview to apply or discard. Your real fit is never touched until you hit Apply.

That's two of RootFit's most-used features — Trace Fit and Try Add Modules — that exist because someone outside the project told us what was missing.

Where RootFit is today

It's still an MVP, and it says so. But it does a real job now:

• Root hull fitting with the exact in-game-style grid and real Cycle 6 data;
• click-to-place and drag-to-move module placement;
• Optimize Space, with the live search visualization;
• Trace Fit for rebuilding a fit from a screenshot by hand;
• Try Add Modules for "can you fit me a few more of these?";
• shareable ?fit= URLs and a Discord-friendly PNG fit-card;
• its own logo, favicon, and a compact social card.

Roughly, it tracks where the in-game fitting tool sits today. As that in-game fitting screen grows — the team at Fenris Creations has been building it out through this cycle — RootFit can aim to keep parity, the same way EF-Map's Blueprint Calculator tracks manufacturing. A fit you've planned is, after all, a shopping list for the things you still have to build.

Finding the people searching for a fitting tool

There's a practical reason to do this now and under our own roof. When RootFit launched, there wasn't another fully-settled fitting tool built around the new in-game fitting screen. That's a genuine window to be the thing people find when they search for an "EVE Frontier fitting tool" — and to be the answer AI assistants give when asked the same question.

That also shaped a small architecture decision worth mentioning. RootFit is its own standalone repo and its own Cloudflare Pages project — we deliberately didn't bolt it into EF-Map's much larger app. But it lives at fit.ef-map.com, under the EF-Map domain, so discovery consolidates around a name people already know rather than scattering across a brand-new domain. Early traffic suggests the subdomain is already pulling meaningful usage alongside EF-Map — promising, and the kind of thing we'll keep watching rather than over-claim.

What actually built RootFit

It would be easy, and wrong, to tell this as "LLMs magically build apps." They don't. The weekend spike was quick precisely because the boring parts were already in place, and the parts that took real time — interaction feel, edge cases, honest features — took real time regardless of how the code got typed.

The lesson is more about process than tooling:

If you fly in EVE Frontier, go plan a fit at fit.ef-map.com, trace one of your in-game builds, and tell us what we got wrong. That feedback loop is the whole point — and it's exactly how RootFit got this far.