I like interesting problems. I build the tools that solve them.
I'm Tim Hodge, and Off Walter is where I build custom integrations, WordPress plugins, and operational tooling: software that connects systems never meant to talk, holds up under real load, and gets reviewed before it ships. Not another website vendor. A builder who cares whether the thing actually works.
I don't sell websites by the pound.
Most of the web business now is a race to the bottom: cheaper templates, cheaper hosting, more subscriptions that half-work and don't talk to each other. That's not the work I'm interested in.
What I like is the problem underneath the problem. The listings data trapped in a portal that keeps your leads. The CRM that never sees what your website collects. The plugin that gets you 85% of the way there and stops. The system nobody can explain anymore. I build the code that connects those things, and when a fix turns out to be everyone's problem, I turn it into a tool and keep sharpening it.
Below is some of what that's produced. Most of it runs in production right now.
The Walter tools
When a client problem turns out to be a whole category's problem, I build a tool for it and keep it sharp. These run in production today.
Walter Offloads: media offload that refuses to lie to you
Every WordPress media-offload plugin promises the same thing: move your images to a CDN, free up disk. Most of them cut the one corner that matters. They report a file as safely uploaded and then delete your only local copy, whether or not that's actually true. Walter Offloads treats every CDN operation as fallible and refuses to delete a local file on anything less than a confirmed, file-by-file remote success. I built it after watching the popular plugins fail in production: a 787,000-file news site melting down at the memory ceiling, responsive images silently breaking because nobody rewrote the srcset. It ships with more test code than product code and passes static analysis at the strictest level there is.
PHP · Bunny.net CDN · PHPStan level 10 · 351 tests · running in production
Walter Sentry: security monitoring from outside the house
Most WordPress security tools live inside the site they protect, so the same attacker who gets in can switch them off. And they scan files, which means they miss the modern attack: a card skimmer hidden in a database row, an admin account created by quietly elevating a real customer's permissions. Walter Sentry watches from the outside. It never runs code inside WordPress. It logs in the way a developer would, fingerprints the files, database, users, and settings, and compares against a known-good baseline on a schedule. It was born from a real breach, a store compromised for months while name-brand security plugins ran and caught nothing, and every check it makes maps to something that breach taught me.
Python · SSH + WP-CLI · 26 checks · 762 tests · monitoring live sites
Walter: the command center this whole shop runs on
Walter is my command center: one server that runs my entire practice and sharpens it into something closer to a small engineering department. I still do the work I'm good at, all of it. I architect the system, plan the build, write and test the code, run the servers, and maintain what ships. Walter makes every one of those better. It holds the full context of every project I've touched, surfaces the right hard-won lesson at the right moment, and puts today's best AI models to work as instruments I direct, never as an autopilot. Every change runs a gauntlet: models from rival labs cross-check each other, static analysis and automated review on every diff, and me with my hand on the merge button. It isn't for sale. It's the reason one person can build to the standard of a much larger team, with a human doing the engineering at every step.
Command center · cross-model review · self-documenting memory · human in the loop
The problem behind the problem
Clients usually arrive with a solution in mind. The interesting part is figuring out what they actually needed.
Your listings, your brand, ten milliseconds
Real estate agents were funneling their own visitors to third-party listing portals, every click a lead handed to someone else. I built a full You Got Listings integration: a middleware API that syncs their inventory into a local cache, a map-based property search on their own site, and leads routed straight to their CRM. The first version proxied every search to the listing provider and took two to five seconds. I rebuilt it cache-first and got it to about ten milliseconds. It became a product of its own.
Node/TypeScript · SQLite · Leaflet · You Got Listings API · Follow Up Boss
This became BWG YGL, built for Boston Web Group.
Vacation rentals, priced to the cent
A resort wanted live availability and real prices for its cottages on its own WordPress site, pulling from the channel manager it already uses to sell on Airbnb and VRBO. The catch: that vendor has no endpoint that tells you what a stay actually costs. So the integration reconstructs the price itself, nightly rates and fees and taxes and length-of-stay discounts, rounded exactly the way the vendor rounds, so the number on the site matches the checkout to the penny. Two separate accounts merge into one set of listings, kept fresh by webhooks and a lightweight calendar sync.
Node/TypeScript · SQLite · Uplisting Connect API · webhooks
One event database, many websites
An entertainment company ran shows across several branded WordPress sites and updated each one by hand: duplicate data entry, inconsistencies, missed events. I built a Laravel API as the single source of truth and a WordPress plugin that pulls listings into any connected site. Enter an event once; every site updates itself.
Laravel · WordPress plugin · REST API
600 scholarships in an Access database
A nonprofit thought it needed an expensive scholarship-management platform. What it actually needed was its existing data in a real database with a web interface. I replaced the Access file with a Laravel and Filament backend and a REST API that feeds the public site. Staff manage everything through a clean admin; students search and filter on the web.
Laravel · Filament · REST API · WordPress
The best tools available, in the hands of an engineer.
I use modern AI tooling heavily, because it's real leverage and leaving it on the table would mean slower, worse work. But I use it the way a good engineer uses any powerful tool: deliberately, and with my eyes open. This is not a vibe-coding shop.
I architect the system before a line is written. I plan the build, write and review the code, write the tests, run the infrastructure, and maintain it after launch. The tooling accelerates every one of those steps. It replaces none of them. Nothing it drafts reaches you without passing a real gauntlet: models from other labs cross-check the work, static analysis and automated review run on every change, and someone who understands the code signs off on all of it.
The tool that produced a first draft doesn't matter. What matters is that a person who knows what they're looking at owns the result.
- The Floor: static analysis on every repo, always on
- The Gatekeeper: automated code review on every change
- The Panel: cross-company model review, scaled to the risk
- The Inspector: a sandboxed reader with no write access
- Me: architect, reviewer, and the only one who ships
Powerful tools, pointed by someone who still does the engineering.
Bring me a problem.
I take on a small number of projects at a time: custom integrations, WordPress plugins, Laravel backends, and the occasional "nobody can figure out why this is broken." If your tools don't talk to each other, if you need a feature your platform doesn't have, or if you've got a build from Cursor or Bolt or your last developer that needs a real set of eyes before it ships, that's my kind of work.
No packages, no price grid. Tell me what's not working and I'll tell you what it takes to fix it. More on working with me →
Tell me what's not working
Email or a form. No tickets, no portals. Just the problem, in your own words.
I scope it
What it takes, what it costs, and whether I'm even the right person for it. Straight answers.
I build it
Reviewed, tested, documented. You see what's happening as it happens.
I stick around
I don't build and disappear. If it's live, it's supported.
Got something interesting?
A messy integration, a plugin that doesn't exist yet, a codebase that needs a second opinion, or a problem you haven't been able to describe to anyone technical. I'd like to hear it.