Every automatic step needs a manual shove
Applied scientist turning one room photo into a place you can furnish
HausJam estimates a floor, then places furniture on it, and the estimate is sometimes wrong enough that a sofa floats or sits in the aisle. The product's answer is not a better apology, it is a fallback: rotate the piece by hand, push it to the wall, finish the hidden chair legs the camera never saw. Titus treated that pair, model plus shove, as the design, not as a temporary shame until the model is perfect. Vision products fail in public, in the screenshot the user was about to send to a partner, and a slider that corrects the lie is the difference between a demo and a tool. If your pipeline infers the world from a photo, budget the correction UI in the same sprint as the inference. Users forgive an estimate they can fix. They do not forgive a beautiful room they cannot trust.
Related advice
Validate the model before you let it pose for the screenshot
HausJam can produce a room that looks finished and is still dimensionally untrustworthy, which is the most dangerous kind of demo. Titus's rule is to validate before production, before the screenshot, before the moment a founder falls in love with a render. Prompting, used carefully, still fixes more than a hurried fine-tune, and a human fallback is part of validation, not an admission of defeat. The lesson is wider than furniture: generative features fail by being persuasive. Build a check that can say no, a measurement, a held-out set, a person with a slider, and run it while you still have the nerve to throw the pretty output away.
Compile after the picture is true
The HausJam speed toolkit is the current fashion, quantization, Torch.compile, a model small enough to live in 4 to 8 GB, and Titus still refuses to lead with it. Twenty seconds to clean a room is annoying. A fast room that sells the wrong sofa is a refund and a screenshot on someone else's Slack. The same ordering applies to any generative consumer tool: pick the quality bar that makes the output a decision, then spend the engineering on latency. Hardware targets, including unfashionable integrated GPUs, belong in that second pass, not as an excuse to ship a blurry world. Users will wait a few seconds for a room they trust. They will not wait at all for a room they have already learned to doubt.
Make the picture true before you make the picture fast
The HausJam stack has a speed roadmap, quantization, Torch.compile, a model that should eventually run on integrated graphics, including an old MacBook Pro, but Titus ordered the work the opposite of the usual launch panic: get the output good enough to decide a sofa, then spend the compile pass. A twenty-second clean and a twenty-second lighting estimate are painful, and still less damaging than a fast room that sells the wrong dimensions. The beginner-friendly web stack came up too, Supabase and Vercel as a default, and it did not change the order. Latency is a product problem you can profile. A wrong world is a product problem you cannot refund with a spinner. Ship the quality bar that makes the screenshot honest, then attack the seconds.
Reopen the problem when the first assumption dies
Titus's working habit, carried from Intel, Ring, and Smilecloud into HausJam, is to treat a broken output as evidence that the problem was mis-stated, not as a request for a prettier model. If the floor is wrong, the task is no longer "place the sofa," it is "why did we believe this plane was the floor?" That sounds philosophical and is in fact operational: it stops a team from spending a month fine-tuning their way around a bad prior. The general rule for anyone shipping vision or geometry is to keep the original problem statement on a short leash. When the demo lies, rewrite the job, add the measurement you skipped, or change the input, two photos instead of one, before you buy another training run. Stubbornness belongs to the user outcome, not to last week's framing.
Extracted from
Indie TM #14: One Photograph, Then the Furniture Moves