DEV Community: Fh Ndiritu

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.