The Rebuild You Can’t See | What’s New Under the Hood

Rebuilding the Engine Behind Both Sites

Over the last few months, I rebuilt the backend that powers both TheTecnoAgrarian.com and FruitionForestGarden.com. On the surface, both sites look the same—and that was intentional. The real work happened underneath. The rebuild wasn’t about appearance; it was about eliminating code drift, improving maintainability, and building a foundation that would scale without introducing the same problems twice.

This post breaks down the architecture changes, the shared core system, the internal tools I built along the way, and the lessons that came from taking a curiosity-first approach to the entire process.

Where the Real Problem Was

When TheTecnoAgrarian.com was forked from the FruitionForestGarden.com project, I suddenly had two of everything: two upload systems, two admin interfaces, two sets of middleware, two image pipelines, two places to fix the same bug. In time, each site would slowly drift away from the other unless I spent time constantly keeping them aligned.

That’s where the idea of a shared core came from. If both sites ran off one backend engine, I could focus on building features once, not twice.

The Shared Core Architecture

The core of the rebuild is an app factory—a function that creates a fully configured Express application using a shared set of logic, models, middleware, and tools. Each site provides its own views and branding, but the backbone remains identical, guaranteeing consistency.


// blog-core/src/app.js
export function createBlogApp(config) {
  const app = express();

  const db = initializeDatabase(config.databasePath);

  app.use(helmet());
  app.use(csrfProtection);
  app.use(session(sessionOptions));

  app.set("views", config.viewsPath);
  app.use(express.static(config.publicPath));

  return { app };
}

This cleaned up a huge amount of duplication. Adding a feature or fixing an issue now updates both sites instantly.

Curiosity, Cleanup, and Removing Spaghetti Code

Using AI sped up parts of the rebuild, but it also introduced overly complex abstractions, long middleware chains, and unnecessary documentation. The real work happened when I slowed down, asked better questions, and removed anything that didn’t fit. We still have some work to do for sure. Curiosity became the tool that kept the architecture under control.


// Before (too many steps):
router.post("/upload", auth, upload.single("image"), resizeImage, logUpload, notifyUser, save, nextStep, finish);

// After (trimmed with intention):
router.post("/upload", auth, upload.single("image"), processImage, savePostImage);

Cleaner code, fewer surprises, easier maintenance.

Internal Tools That Emerged

As the shared core came together, other improvements naturally followed:

A custom analytics dashboard (no Google dependencies)
A smoother hero-image upload pipeline
A reliable automatic backup system
Consistent image processing across both sites

These weren’t the original goals, but they became natural extensions of the new foundation.

Image Processing That Works Everywhere

One consistent workflow came from unifying the image pipeline. Both sites now use the same automatic conversion, resizing, and compression workflow. This doesn’t just help posting; it guarantees consistent performance and predictable behavior across the board.


// Unified image pipeline
sharp(file.path)
  .resize({ width: 1600 })
  .webp({ quality: 80 })
  .toFile(finalPath);

The Result: Fast, Consistent, and Maintainable

The new architecture is easier to extend, easier to reason about, and significantly more consistent. The shared core eliminated drift between sites, and the internal tooling gave me better visibility and reliability than I had before. Posting is smoother, that was a byproduct of building a stronger system.

What Comes Next

With the foundation in place, I’m shifting into the next phase: detailed Raspberry Pi and Home Assistant guides, automation tools, ESP32 builds, and more of the hands-on technical content I’ve been planning.

The videos will stay short and efficient. The write-ups here will dig deeper into the reasoning, the architecture, and how everything fits together. This rebuild took time, but it set the stage for everything I want to build next.

Categories