How we built a support tool in an hour to fix one broken scan

A bug in our pipeline caused some 3D floor scans to merge incorrectly. We shipped the fix. Then a support request came in from a customer who had scanned a big house while the bug was still live, so their file came out merged wrong.

The scan was technically fine. The file opened and the data was all there, but the survey points had landed in the wrong places, which made the model impossible to use as the source of truth for a floor plan. And the customer needed a usable report by Saturday.

The scan came from an iOS LiDAR capture. Apple’s RoomPlan hands you a structured model of a home: walls, doors, windows, and rooms, each with coordinates and a level. Our scan-to-floor-plan product reads that model and turns it into a floor plan a customer can actually use. If you want the technical shape of that pipeline, we wrote it up separately: RoomPlan USDZ in, a web-renderable scene out.

When it works, you get the picture above. This file didn’t. The rooms had merged into each other, so there was no clean plan to export.

The two options we used to have

The bug was already fixed, so this wasn’t about the product going forward. It was about one customer’s already-broken file, on a deadline. Two endings, and neither is good.

Ship a product feature. Build proper handling to repair affected files into the product, test it, release it. That’s the right long-term answer, and it’s also two weeks minimum. The customer needed Saturday.

Tell the customer to rescan. The honest version of “sorry, can’t help.” Rescanning a whole 2,000-square-foot home is real work for them, and it moves our problem onto the person who’s already frustrated.

For one broken file on a deadline, both cost more than the case is worth. So tickets like this drag, or land on an engineer who has to drop what they’re doing.

What we built instead

So Federico, one of our engineers, asked Claude to build a small visual editor for the scan. Not a product feature. A tool. You load the broken file, you see the rooms laid out, and you drag them apart, drop each one onto the right level, and nudge them into position. Think of it as Tetris for a floor plan: separate the pieces, slot them where they belong, done.

It took roughly an hour, start to working tool, iterating with Claude the whole way. Partway through, Jorge looked at it and said the rooms needed labels so you could tell which was which while you moved them. That went in during the same session. Try that as a change request against a normal sprint board.

The support engineer loaded the customer’s file, pulled the merged rooms apart, dropped each one where it belonged, and exported a clean report. Saturday deadline met.

Why one hour changes the math

Building that editor by hand would have taken days, and nobody signs off on days of engineering to rescue a single file. A year ago the tool never would have existed, and the customer would have gotten option one or two. An hour changes that answer. At an hour, a tool that helps exactly one customer is worth building, and once it exists it’s not one customer anymore: the next time a scan comes in scrambled, support already has the fix open in a browser tab.

That’s the quiet shift under the noise about AI writing code. It isn’t that engineers type faster; it’s that the threshold for “worth building” dropped far enough that a whole class of small internal tools, the ones that make support feel fast and competent, landed on the right side of the line. Building software got cheap, so you stop choosing between a two-week feature and telling the customer to start over, and invent the thing while you’re in the problem instead. Find where work is sitting still, and build the smallest thing that gets it moving.

What happens to it now

The editor started as a rescue for one ticket. It’s already more than that. The support team can reach for it on the next scrambled scan, and we’re looking at folding the same logic into the product so files that come in merged wrong get straightened out before anyone has to touch them. The one-off becomes the prototype for the real feature, which is a nice way to find out exactly what the feature needs to do.

One note on the media above. We don’t publish real customers’ homes, so the scan you’re looking at is one of our own: a house we scanned ourselves, aligned to its real location. When we hit this bug for real, it was a customer’s file; here we reproduced the same bad merge on our own scan to show the fix. The bug is real. The house is ours.

If you’re running a scan-heavy or data-heavy product and your support team keeps hitting edge cases the product doesn’t handle yet, that gap is exactly where a small internal tool pays for itself now. Happy to compare notes: hello@lagarsoft.com.