DEV Community: Fh Ndiritu

We spent 10 months rendering the wrong file

Fh Ndiritu — Mon, 26 Oct 2026 14:51:21 +0000

Disclosure: I'm the founder of Hadaa, an AI landscape design tool. I use it as the worked example here because it's the system this actually happened to — the lesson is the point, not the product.

There's a failure mode I now watch for in every system I build, and it has nothing to do with the model, the framework, or the infra. It's this: you can spend a year perfecting a pipeline that operates on the wrong input.

Here's how I learned it.

The pipeline that worked

We build software that turns a landscape design into photorealistic renders. For about ten months, the entire thing rested on one assumption I never once stopped to examine: the input is a sketch. A pro uploads a rough drawing of the yard, the engine reads it and produces a render.

And it worked. People paid for it. So we did what you do with something that works — we optimized the hell out of it. Better reading of the sketch. Better inference of what the lines meant. Better handling of ambiguity. Ten months of honest, measurable engineering progress on the sketch-to-render path.

The thing is, every one of those improvements was in service of a harder and harder guessing game. A sketch is a lossy proxy for the real design. We were pouring effort into reconstructing information that had been thrown away before the file ever reached us.

The one sentence

I got on a call with a pro to debug why one of his renders didn't match what he'd pictured. We were looking at his sketch together and he said, completely offhand:

"Yeah, the sketch is just the rough version. The real drawing is the CAD file."

He shared the .dwg. I opened it. And it was one of those quiet, slightly sickening moments where the floor tilts.

The file had everything the sketch had discarded. Every layer. The plant legend with exact species. Spot levels. Retaining walls. Sheet notes. All the information we'd built an elaborate engine to infer — the customer already had it, in full, sitting in a file on his laptop the whole time.

We'd built a beautiful machine for reconstructing a plan from a blurry photo of it, while the plan itself was one upload away.

The general lesson

This generalizes way past landscaping. So much AI product work is quietly an exercise in recovering information from a degraded representation — OCR'ing a scan when the source doc exists, parsing a transcript when structured data was available, re-deriving intent from a UI screenshot when there was an API. The lossy proxy is seductive because it's what the user happens to hand you first. It feels like the input. It usually isn't the source of truth.

The question I should have asked in month one — and now ask on day one — is: "Is this the real artifact, or a lossy picture of it? And if it's a picture, where does the real one live?"

Almost always, the real one lives somewhere boring and accessible, and reaching for it is less work than the heroics you'd otherwise spend compensating for what the proxy lost.

So we stopped guessing and started reading the file directly.

Reading the source of truth is its own kind of hard

I want to be honest that "just read the real file" is not a free lunch. Turning a CAD drawing into a render that actually matches what was drawn is brutal. The only way we found to get it right was to get on call after call with real pros and ask them for real, messy, live project files — never clean demos. Every single call broke something: a house on a slope with walls floating in the air, a roof overshooting the walls, retaining walls that didn't step the ground, garden lights that didn't look like lights, plants that all rendered identical.

Two things came out of that grind that I'd recommend to anyone building on a "real" source artifact:

1. Measure fidelity as a number, not a vibe. We built a test set of real drawings with hand-made answer keys, purely so we could measure how much of a drawing's meaning a render preserved and how much it lost. "Meaning and loss" is now a value we track on every change. You cannot improve "does the output match the input" if match is a feeling.

2. Discover that half your "loss" is upstream. A lot of what looked like our engine losing information turned out to be drawings that never carried it cleanly in the first place — inconsistent layers, missing legends. That pushed us to write up a CAD drawing standard for landscape plans: the layer and legend conventions that make a drawing read cleanly for a machine. When you consume a real-world artifact at scale, you often end up having to define what "clean" looks like.

Where it landed

We ship to this engine every day now, and we eat the cost of being wrong on purpose: every rendered view is checked back against the original drawing, up to three times, until it matches — and if it still can't, the customer pays nothing. A miss is on us, not them. That guarantee is terrifying and it's also the best forcing function we've ever had, because it means "meaning and loss" isn't an internal metric, it's money.

If you want to see where the source-of-truth path ended up, this is the engine now: turning a landscape DWG into a photoreal render.

The takeaway

Our old engine wasn't bad. It was good engineering built on an assumption we never had the humility to question. One customer questioned it for us, in passing, and the single most important technical decision we made this year came out of one offhand sentence on one call.

Before you optimize a pipeline, interrogate its input. Ask whether you're reading the artifact or a lossy photo of it. The expensive mistakes aren't the bugs in your code — they're the assumptions you never thought to put under test.

Has a single conversation ever flipped a core assumption in something you'd been building for months? I'd genuinely like to hear it.

Single-Signal Recommenders Feel Dumb: Prune, Don't Rank

Fh Ndiritu — Tue, 18 Aug 2026 12:33:38 +0000

Every recommender starts as a single filter and stays there longer than it should. You ship colour matching, it works, the demo looks great, and the product feels dumb the moment a real user touches it. I spent a while working out why, and the answer turned out to be structural rather than a modelling problem.

Disclosure: I work with Clad9, which is the worked example throughout. The argument is about recommender design, not the product.

The domain, quickly

Wardrobe apps digitise your clothes and tell you what to wear. Simple-sounding, and the category has an unusually high failure rate. Two failures dominate, and only one of them is about recommendations.

Failure 1: the ingestion cliff

Before you can recommend anything, you need the inventory. The classic flow was per-item photography — lay the garment flat, shoot, crop, tag with category/colour/season. Two hundred items.

Look at what that does to the user's cost curve. The entire cost is paid before any value is delivered. There is no partial payoff at item 40; a half-digitised wardrobe is useless because the recommender can't reason over a partial set without producing visibly wrong answers. So the user pays a large, front-loaded, unrewarded cost, and predictably most of them quit somewhere in the first twenty items.

The fix isn't motivational, it's architectural: change the ingestion modality. One video pan across the rail, frames extracted, garments detected and segmented, background removed, attributes tagged automatically. Three minutes of user time instead of an afternoon, and the payoff now arrives before the effort rather than after it.

If you're building anything that needs a user-supplied corpus before it can work — a finance app needing transactions, a fitness app needing a training history, a knowledge tool needing documents — this is the first thing to check. Most "engagement problems" in corpus-dependent products are ingestion-cost problems wearing a disguise.

Failure 2: the single-signal recommender

This is the more interesting one.

Once you have the inventory, the obvious v1 is: pick a signal, rank on it, return the top result. In this domain the candidate signals are colour harmony, body proportion, weather, and occasion. Every one of them is defensible on its own, and every single-signal version produces output that users describe as "technically fine but useless."

Watch the failure modes, because they're characteristic:

colour-only     → beautifully coordinated, badly cut
proportion-only → flattering shape, palette drains your face
weather-only    → correct insulation, wrong formality entirely
occasion-only   → right register, might look terrible on you

Each one is right along its own axis and wrong along the others. And here's the part that matters: users don't perceive this as "one dimension is missing." They perceive it as the system being stupid. A recommendation that's 75% correct doesn't read as 75% good; it reads as broken, because the one wrong dimension is the salient one.

Why the problem is conjunctive

The real query isn't a ranking over one dimension. It's a conjunction:

wearable(outfit) :-
    palette_compatible(outfit, user.undertone),
    silhouette_compatible(outfit, user.proportions),
    warmth_appropriate(outfit, forecast),
    formality_appropriate(outfit, calendar.event).

Adding predicates does something specific to the result set: each one cuts it, often hard. Over a real wardrobe, colour alone might leave hundreds of candidates — far too many to rank meaningfully, so your top result is essentially arbitrary among near-ties. Add proportion and it drops sharply. Add weather, then occasion, and you're frequently down to single digits.

That's the actual insight, and it's a bit counter-intuitive if you come from search: the constraints aren't a re-ranking problem, they're a pruning problem. With one predicate you're picking arbitrarily from a huge plausible set. With four you can just return the answer, because there's barely a choice left to make.

It also means output shape should change. A single-signal system almost has to return a ranked list, because it can't justify picking one. A conjunctive system can return one outfit, which is what users actually want — a list of five is the decision fatigue they were trying to escape.

The signal everyone skips

Of the four, occasion is the one most products omit, and it's the highest-information one.

Weather is easy: a public API, a scalar, low integration cost. Calendar is annoying: OAuth, permissions, parsing messy event titles, inferring formality from "Standup" vs "Client review — offsite". So teams ship weather and tell themselves it covers context.

It doesn't. Weather is a scalar — it constrains one dimension. Occasion is categorical over formality and prunes far more aggressively. Two users at 14°C, one going to a client pitch and one to the park, get identical recommendations from a weather-only system and correctly conclude it doesn't understand their day.

General lesson: the highest-value signal is often the one that's most annoying to integrate. Ease of integration and information content are frequently anti-correlated, because everyone already took the easy ones.

Undertone, or: your features may not be the user's features

One domain-specific detail with a general moral.

The naive colour model uses hue relationships — complementary, analogous. It's clean and it's insufficient, because whether two garments work together depends on undertone (warm/cool) relative to the wearer's own colouring, not just the hue relationship. Two textbook-complementary colours can look wrong on a specific person. "Blue" isn't even a specification: cobalt and powder blue behave completely differently next to the same burgundy.

So the natural, mathematically tidy feature — hue angle — is the wrong feature. The right one is a warm/cool decomposition relative to a user parameter. The full reasoning is written up here and it's a nice example of a domain where the obvious representation quietly loses information the users can see.

What this looks like shipped

The feature set reads like a normal list — colour analysis, body-aware styling, calendar, try-on, capsule builder. The thing that isn't visible in a list is whether those are four features sitting next to each other or four predicates over one query. From the outside those look identical. From the inside they're completely different systems, and users can tell within a day which one they're using.

The competitive landscape sorts fairly cleanly along this line: several products are excellent single-signal tools, and their reviews say some version of "great at X, gives weird suggestions."

Takeaways if you're building a recommender

Check your ingestion cost curve. Front-loaded cost with no partial payoff = an abandonment cliff, and no amount of onboarding polish fixes it.
Count your predicates. One signal means a large near-tie set and an arbitrary top result.
Prune, don't rank. Enough constraints and the answer falls out.
Integrate the annoying signal. It's usually annoying because it's information-dense.
Question your feature representation. The tidy one may be losing exactly what users perceive.
Let output shape follow confidence. Returning one answer is a claim you can only make if your pruning earns it.

AI Landscape Design in 2026: Why the Generative Model Is the Easy Part

Fh Ndiritu — Sun, 02 Aug 2026 11:32:18 +0000

If you've used any modern image model, you already know it can redesign a backyard photo into something gorgeous. Feed it "make this yard a modern Japanese garden" and you get a convincing render in seconds. Problem solved, right?

Not even close. The pretty picture is the easy 20% of the problem. The hard 80% — the part that decides whether the output is a usable product or a toy — is everything the generative model doesn't know: whether those plants can survive in the user's climate, how to turn an unstructured photo into a spatial map, and how to emit a structured spec a contractor can actually build from.

I want to walk through the real engineering pipeline behind a production AI landscape tool, because it's a nice case study in the gap between "a model that generates" and "a system that ships." I'll use Hadaa as the concrete example since it's one of the more complete implementations in this space, but the architecture lessons generalize to almost any "generative + real-world constraints" product you might build.

The problem, stated like an engineer

Input: 1–14 phone photos of a messy real yard.
Output the user actually needs:

Photorealistic renders in multiple styles and angles
A planting list where every plant will survive at that location
A contractor blueprint with zones, labels, and path widths
A bill of quantities (plants + materials) that can be priced

Only the first bullet is a generative-vision problem. The rest are structured-data problems wearing a trench coat. That's the whole insight.

Stage 1 — Photo to structured understanding

You can't constrain or annotate what you don't understand spatially. So before any "make it pretty" step, the system has to convert pixels into structure: segment the scene (lawn, fence, patio, existing trees, structures), estimate rough geometry, and — when given several photos — stitch them into a coherent area map of the site.

This is the unglamorous computer-vision plumbing: segmentation, depth/consistency estimation, and multi-image synthesis into a single top-down understanding. Get it wrong and everything downstream inherits the error. Get it right and you now have a canvas with known regions you can preserve, edit, or replace deliberately instead of letting the model hallucinate over the whole frame.

Practical takeaway if you build anything like this: masking and region-preservation are features, not afterthoughts. Users need "redesign the beds but keep my house and pool exactly where they are." That's only possible if Stage 1 produced real regions.

Stage 2 — Constrained generation (the "easy" part)

Now the generative step. Given the structured scene and a style prompt, produce photorealistic variations. Modern diffusion-based image-to-image handles this well; realism in 2026 is basically a solved commodity.

The engineering effort here isn't "can it look good" — it's control: honoring the preserved masks, keeping edits local (swap the bamboo for a palm without redrawing the house), and generating a consistent set (same design across 8 camera angles and seasonal/night variants) rather than 8 unrelated images. Consistency across a set is the actual hard sub-problem, and it's a very different beast from one-shot generation.

Stage 3 — The biology layer (the actually hard part)

Here's where most "AI yard design" tools quietly fail, and where the interesting engineering lives.

A generative model has no idea what grows where. It draws tropical palms into a render for a yard in USDA zone 4 because palms look right for "lush garden," and the model optimizes for plausibility, not survivability. The user finds out nine months later when everything's dead.

Fixing this is not a prompt-engineering problem — you can't just append "use appropriate plants" and trust it. It's a constraint-satisfaction problem layered on top of generation:

Resolve the user's location to a hardiness zone, plus rainfall and frost-date data.
Maintain a plant database keyed on those environmental tolerances.
When the render calls for "tall flowering shrub in the back corner," resolve that role to an actual species that satisfies the location's constraints — not just any plant that looks similar.
Verify the final planting list against the constraints before it ever reaches the user.

Hadaa calls this its "Biological Engine," and it's the piece competitors have had the hardest time replicating — precisely because it's not a model tweak, it's a whole data-and-rules subsystem bolted onto the generative core. This is the classic pattern: the moat isn't the model, it's the domain constraints you wrap around it. (Their 11-tool teardown is a decent map of which tools do and don't have this.)

Stage 4 — From pixels back to a structured spec

The last mile is turning an approved render into something buildable: a color-coded blueprint (zones, labels, path widths) and a bill of quantities (how many of each plant, how much material). This is essentially an information-extraction and layout-generation problem running in reverse of Stage 2 — going from the visual design back to structured, quantified data.

It's also where a lot of business value hides, because it's the deliverable a professional can hand to a crew. For a solo designer, the difference between "here's a nice picture" and "here's a blueprint, a zone-verified planting guide, and a priced BOQ generated in two minutes" is the difference between a sales cycle measured in days and one measured in minutes. That's the whole pitch of Hadaa's Pro Studio, and the feature breakdown for professionals is basically a spec sheet for this stage.

"Why not just use a general image model?"

Because a raw diffusion model gives you Stage 2 and nothing else. To ship a real product you still have to build:

Capability	Raw image model	Full pipeline
Photorealistic render	✅	✅
Preserve existing structures	⚠️ manual masking	✅ region-aware
Consistent multi-angle set	❌	✅
Climate-valid plant list	❌	✅ constraint-checked
Contractor blueprint	❌	✅
Bill of quantities	❌	✅

Every ❌ in that first column is a subsystem, not a prompt. That's why "I could rebuild this with an API key in a weekend" is the famous last words of this category.

If you're evaluating (not building) one

Most people reading a piece like this just want to redesign their own yard or use one professionally. The engineering lens still gives you the buying criteria:

Ask what happens in Stage 3. Does it verify plants against your actual climate zone, or just draw greenery? This is the single highest-signal question.
Ask what comes out of Stage 4. A render alone is wallpaper; a render plus a zone-verified planting guide plus a buildable blueprint is a project.
Match the pricing model to your usage. Pay-per-project (Hadaa starts around $9/render, no subscription) fits a one-time redesign; a monthly seat only makes sense if you're producing designs every week.

If you want to poke at a working implementation of the full pipeline, the fastest way to build intuition is to run a yard photo through one and inspect what the planting guide and blueprint actually contain — that's where you can feel which stages a tool has really built versus faked.

Takeaway

The lesson generalizes well beyond gardens: in most "AI does X" products of 2026, the generative model is a commodity, and the durable engineering — and the moat — is the layer that constrains generation to real-world truth and emits structured, actionable output. In landscape design that layer is spatial understanding, climate-aware constraint satisfaction, and spec generation. The render is just the part that demos well.

If you're comparing tools in this space, judge them by the parts that don't screenshot nicely.

Have thoughts on constraint layers over generative models? I'd love to hear how you'd architect the biology engine differently — drop a comment.

I migrated 15M records of 13GB data from Mongo to Rails Postgres on a 512MB budget

Fh Ndiritu — Thu, 22 Jan 2026 20:04:07 +0000

The "Complexity Tax" of Polyglot Persistence

Scaling is exciting; it’s even more exciting before the grounding reality of the first month in production sets in and the thousands of customers you scaled for actually come knocking and you find out the actual numbers. Our Polyglot persistence setup was not unique, nor was it unexpected for an application handling hundreds of thousands of documents through extraction pipelines. But like most startups, we ended up scaling our costs long before we scaled our user base.

Early on, we designed the system to store extracted paragraphs on a MongoDB instance while keeping the core relational data on Postgres. This delivered the expected flexibility of very fast writes and schema-less retrieval—until the day we had to critique the bill. We were paying a "Complexity Tax": the maintenance overhead of running two databases, the cognitive load of context switching, and the realization that we were leaving Postgres's best features—joins, foreign keys, and optimized includes—on the table.

Postgres 18 and recent versions have introduced the most significant optimizations since the debut of TOAST decades ago. The switch from memory-heavy PGLZ to LZ4 compression for text columns, reliance on hardware acceleration (SIMD), and Async I/O with copy scans has changed the calculus. These updates promised near-similar speed to MongoDB, lower costs, and zero network latency between our data and our metadata.

We also had early expectations that users would be constantly editing paragraph contents, leading to massive write spikes. This turned out to be false. After extraction, a paragraph is touched less than three times over its lifecycle. Our write-throughput bottleneck had disappeared, and so had our justification for the overhead of running two databases.

Designing the Migration Architecture

Moving data is easy to judge: is it there or is it not? But getting it there without downtime is a different beast. We needed to account for potential rollbacks and the reality that our extraction pipelines would continue pouring new data into MongoDB while we were trying to empty it. This demanded a "Dual Write" pattern combined with a Hot Swap approach to ensure we kept exactly the same table names, models and relationships.

The Dual Write Sequence

The application needed to write to the new Postgres table without breaking existing code. The strategy involved creating a shadow Active Record model, RailsParagraph, pointing to the standard paragraphs table.

class RailsParagraph < ApplicationRecord
  self.table_name = 'paragraphs'
end

We mirrored the MongoDB fields exactly but made one crucial decision: the mongo_id would become a unique index. This was the anchor. It allowed migration scripts to be replayed infinitely without creating duplicates.

We had more indexes but each B-tree index adds an extra write request, indexes like page_id, section_id and contains_images could wait and be added concurrently when doing the hot swap after data migration which involves renaming AR models and removing the MongoId models.

To capture live data, we hooked into the Mongoid lifecycle. Using after_save callbacks, every new or updated document was synced to Postgres immediately.

# Inside the Mongo model
after_save :sync_to_postgres

def sync_to_postgres
  # We use upsert to safely handle replays
  RailsParagraph.upsert(
    { mongo_id: self.id.to_s, content: self.content },
    unique_by: :mongo_id
  )
end

Idempotency is King

For the backfill script, simple inserts were insufficient. If the script crashed halfway through, it needed to be restartable without manual cleanup. We utilized the upsert_all method with the unique_by: :mongo_id parameter. This ensured that if a record had already been synced by the Dual Write process, the backfill script would simply skip it or update it, preventing race conditions.

The Poison Pill (Sanitization)

Migration scripts are excellent at finding data corruption you didn't know you had. MongoDB, being schema-less, had happily accepted strings containing Null Bytes (\u0000). PostgreSQL is stricter; a single null byte in a text column is a violation that aborts the entire transaction.

A sanitization boundary was required, stripping these characters before they ever touched the SQL payload.

# The Sanitization Boundary
text: doc['text']&.delete("\u0000")

The "Naive" Implementation & The Crash

A separate PR would remove the MongoId index which would not be needed anymore, add the remaining indexes by disabling ddl transaction which allows us to add concurrently indexes without locking tables and finally insert our relationships between paragraphs, pages and sections.

With the architecture set, the code was written—clean, idiomatic Ruby. A Sidekiq job was built to process 15 million historical records in batches of 2,000, spawning subsequent jobs in a neat daisy-chain. It looked perfect in the Pull Request.

Then it was deployed.

The jobs ran for a few minutes, processed a few batches, and then the worker would silently die. No error logs, just a vanished process. On Heroku, the graphs revealed the dreaded Error R14 (Memory Quota Exceeded).

It wasn't a flat line; it was a "staircase." Every batch pushed the memory baseline higher. Ruby was releasing the objects, but the operating system wasn't reclaiming the RAM. We weren't fighting a bug in the code; we were fighting Memory Fragmentation. The heap looked like Swiss Cheese—full of holes too small to reuse.

Debugging Physics

At this point, standard advice is "Just install jemalloc." It’s the easy button that swaps the memory allocator to mask the problem. But rather than masking it, we chose to fix the physics of the container.

Taming the Arenas

The standard Linux allocator creates multiple memory pools ("arenas") to optimize for multi-threaded speed. In a constrained 512MB container, these arenas compete for RAM and hoard pages. We forced glibc to be frugal by strictly limiting the number of arenas via the environment config.

# Force the allocator to reuse memory chunks
heroku config:set MALLOC_ARENA_MAX=2

The Hack: Manual Garbage Collection

High-churn string processing is the enemy of Ruby's lazy Garbage Collector. By the time the GC wakes up, the OS has already allocated new pages, increasing RSS (Resident Set Size). We manually managed memory inside the loop by forcing the GC to sweep immediately after releasing the batch reference.

# 1. Clear the reference explicitly
batch_docs = nil 

# 2. Force Ruby to clean up NOW
GC.start(full_mark: true, immediate_sweep: true)

The Defragmenter

Just cleaning up isn't enough if the heap is fragmented. We introduced compaction to physically move objects in memory, smashing the "Swiss Cheese" holes closed every few thousand records.

if (processed % 10_000).zero? && GC.respond_to?(:compact)
  GC.compact 
end

The "Crowded Door" (Connection Limits)

With memory stabilized, ambition took over. We scaled the worker count to speed up the migration. That’s when the second wall appeared: Redis Connection Limits.

Running on a Redis "Mini" plan meant a hard limit of 20 connections. The workers crashed immediately on boot with ERR max number of clients reached. Worse, attempting to debug via rails console grabbed 10 connections instantly, effectively performing a "Murder by Console" on the production workers.

The Fix: Connection Diet

The application had to go on a strict diet. We capped RAILS_MAX_THREADS to 2 and SIDEKIQ_CONCURRENCY to 1. We traded theoretical capacity for actual stability.

# Force Rails and Sidekiq to fit in the box
heroku config:set RAILS_MAX_THREADS=2
heroku config:set SIDEKIQ_CONCURRENCY=1

Optimizing Optimizations

With the system stable, we hunted for bottlenecks. The biggest one wasn't the database; it was the logs.

Writing "INSERT INTO..." 15 million times is a massive I/O operation. The CPU was spending half its cycles waiting for the disk to acknowledge the log write. We silenced ActiveRecord for the migration block, and throughput instantly increased by 40%.

ActiveRecord::Base.logger.silence do
  # Pure signal, no noise.
  migrate_batch!
end

Counter-intuitively, setting SIDEKIQ_CONCURRENCY=1 also made the migration faster. With 3 threads, there was high context-switching overhead and constant contention for the database lock. With 1 thread, the worker entered a "flow state"—reading from Mongo and writing to Postgres in a tight, uninterrupted loop without swapping to disk.

Conclusion

We successfully migrated 15 million records, consolidated our database stack, and reduced our monthly infrastructure spend. But the real lesson wasn't about PostgreSQL or MongoDB.

It was about Physics.

We could have installed jemalloc and called it a day. But by choosing the hard path—tuning the arenas, manually compacting the heap, and mathematically sizing our batches—we actually learned how our runtime interacts with the hardware. We moved from a fragile, complexity-taxed system to a boring, standard stack. And in infrastructure, "boring" is the highest compliment you can get.