Titus Nicolae
Applied scientist turning one room photo into a place you can furnish
Applied scientist whose path runs through competitive programming on InfoArena, Python and Django at 3Pillar Global, research at Intel on getting neural networks to run, LiDAR localization at Ring, and dental AI at Smilecloud, tooth distances, segmentation, in-painting, the unglamorous geometry of a face. With Andrei Statescu he is building HausJam, a room planner that tries to give a single 2D photograph the seriousness of a professional layout tool: clean the clutter, estimate depth and light, then let you move furniture inside the room you already have. At Indie TM #14 he and Andrei opened the prototype and let the room argue about fallbacks, on-device inference, and who should pay.
Journeys
Events
Advice & Tips
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.
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.
Every automatic step needs a manual shove
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.
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.
If the photo is the product, run the model where the photo already lives
HausJam's two heavy passes, about twenty seconds to clean a room and twenty to estimate light, are the line items that would destroy a consumer margin the moment traffic arrives. Titus's preferred answer is to run the first useful slice on the user's own machine, an eight or nine gigabyte model that cold-starts in about twenty seconds and, if they can pull it off, still works on integrated graphics. That is the same economic move Naramine made with in-browser Kokoro, applied to furniture: the free or early tier brings its own compute, and the cloud becomes an upgrade rather than the default. When your unit of value is an image the user already has, ask whether that image ever needs to leave the laptop. Recurring GPU rent is a tax on success. Hardware the user already paid for is not.
Consumers furnish in projects. Price the project.
A ten-euro subscription with a handful of rooms was on the table and did not survive contact with the room. People do not rearrange an apartment every month; they do it in bursts, a move, a renovation, a new child, and a calendar tax on the quiet months is the same mistake Naramine refused for web-novel binges. What survived were project-shaped offers: credits you top up, a time-box on a room, a pack for one apartment, a five-room house in the 50 to 100 euro range with several layouts, maybe a lifetime deal for early users with a room cap. Professionals can still have a seat price, because their week is volume. Consumers need a price that matches a job they will finish. Before you copy a SaaS page, ask how often the job happens. If the answer is "twice a decade," you are not selling a seat.
