Reopen the problem when the first assumption dies
Applied scientist turning one room photo into a place you can furnish
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.
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.
Ship the on-device slice before the cloud starts billing you
HausJam's expensive seconds are image passes, and image passes billed in the cloud will eat a consumer product the first week it works. Titus's V0.5 is deliberately smaller: a room cleaner that runs on the user's machine, inside a 4 to 8 GB memory budget if they can hold it, so the first useful magic has a marginal cost near zero. Steam then becomes a storefront for a tool, not a server bill in disguise. The pattern is the same one indie founders keep relearning with local models: put the wedge on hardware the user already owns, and let the cloud be an upgrade for the people who need the heavy lighting pass. If your v1 requires a GPU invoice on every photo, you do not have a consumer business yet. You have a demo with a fuse.
Do not hide your price inside the retailer's invoice
Charging furniture sellers, or folding HausJam into the price of a sofa, looks like distribution and behaves like a tax the shop will resent. Titus and Andrei want the end user to pay, because that is who received a furnished room and who can understand a credit pack or an apartment project. Seller-pays also poisons the catalog: every SKU becomes an ad, and the planner stops being a tool. Keep the invoice on the side that gets the outcome. Retailers can still partner; they should not be the meter.
Extracted from
HausJam: Start From the Room You Already Have