Skip to main content
William Lodge

Build / Search / Data / Infrastructure

What I can build, fix, and operate

I work across web development, search engineering, data, automation, infrastructure, and AI-assisted systems. The useful part isn't the list — it's that I can follow a problem from the browser to the database to the server without handing it to someone else halfway through.

01 / Cross-layer work

Following the problem all the way down

Most technical problems get misdiagnosed at a boundary. The frontend developer says the API is wrong, the API developer says the data is wrong, and everyone is looking at their own layer.

I can usually follow a problem past the application layer. If the bug is actually in DNS, a proxy rule, a redirect chain, a database index, or the server configuration, I don't have to stop at “the code looks right.”

Worked example 01

A search problem

  1. Crawler can't discover inventory
  2. Inspect frontend rendering
  3. Check routing
  4. Read server responses
  5. Verify sitemap
  6. Confirm in Search Console

The cause can sit at any one of those layers, and sometimes more than one.

Worked example 02

An automation problem

  1. Manual resource verification
  2. Model the database
  3. Build the crawler
  4. Schedule the job
  5. Add admin approval
  6. Alert when data goes stale

The useful system is rarely just the crawler. The approval and stale-data handling are what make the automation operationally trustworthy.

Worked example 03

An application problem

  1. Feature request
  2. Interface
  3. API
  4. Schema change
  5. Deployment
  6. Monitoring
  7. Revise when the logs say something unexpected

The implementation is only one part of the work. What happens after deploy is part of the system too.

You usually don't need someone who knows every tool. You need someone who can follow the problem far enough to find the actual cause.

02 / Depth map

Capability map

Grouped by domain, and honest about depth. Anything in the first tier I'll happily be interviewed on. Anything in the third I'd charge you for the learning curve, or tell you to hire someone else.

01

Web development

I build both traditional websites and application-style systems. I'm not tied to one framework, CMS, or hosting stack, and I'll tell you when a project doesn't need one.

DeepPHP · JavaScript · HTML · CSS · responsive UI · REST APIs
SolidReact · Vite · Node · TypeScript · PWAs · custom admin interfaces · CMS work
Workingadvanced accessibility implementation
02

Search engineering

Technical SEO as an engineering discipline rather than a content exercise: crawl and indexing behavior, structured data, canonicalization, redirect architecture, internal linking, sitemap design, Search Console diagnostics, local search, and AEO/GEO research held to primary sources.

I also do large-scale SEO QA — checking hundreds or thousands of URLs for a class of problem instead of manually reviewing a handful of pages.

Deepcrawl/indexing diagnostics · structured data · canonicals · redirects · internal links · sitemaps · Search Console · local search · large-scale QA

Deepest in one niche: Live Event SEO — venues, promoters, festivals.

Live Event SEO

Also focused: Dispensary SEO — Google Maps visibility, crawlable menus, and local search for licensed Colorado retailers.

Dispensary SEO
03

Data and databases

Schema design, data imports, taxonomy design, validation systems, deduplication, ETL-style workflows, search and filter systems, and the APIs built on top of them.

DeepMySQL · MariaDB · SQL · JSON · CSV · data imports · validation systems
Solidschema design · taxonomy systems · search/filter systems · ETL-style workflows · API-backed data systems
WorkingPostgreSQL
04

Automation

Crawlers, scheduled jobs, monitoring and alerting, data verification, content pipelines, approval workflows, CLI tooling, and server-side automation.

The pattern is usually the same: something is being done by hand every week, it is error-prone, and it is a database plus a scheduled job plus a human approval step away from being much easier to operate.

Solidcrawlers · scheduled verification · alerting · admin approval workflows · CLI tools · data pipelines · monitoring
05

AI systems

Not prompt writing. System design around models.

Deeppermission boundaries · human approval layers · approval lifecycle · execution controls
Solidmodel integration · retrieval/context systems · AI-assisted search · structured extraction · fallback logic · model routing
Workingclassification systems
How I use this on client projects: AI Workflow
06

Infrastructure and deployment

This is the section that separates me from someone who only builds front ends.

DeepLinux · SSH · Git/GitHub · DirectAdmin · DNS · SSL · MySQL/MariaDB operations
SolidOpenLiteSpeed · reverse proxy configuration · PM2 · system services · deployment debugging · log analysis · mail/DNS configuration

I operate my own server stack and can manage production hosting directly when a project calls for it.

If a problem turns out to live in DNS, the proxy layer, process management, permissions, or the database, I can keep following it instead of stopping at the application boundary.

07

Auditing and debugging

A good share of technical work is inherited: someone else built it, it broke or underperformed, and the original developer is no longer involved. That is a normal engagement, not a problem.

Deeprepository audits · SEO audits · runtime debugging · route and redirect problems · deployment troubleshooting
Solidarchitecture review · regression analysis · broken integrations · database issues · production failures · technical second opinions
08

Research and technical documentation

Where factual accuracy matters, I prefer primary documentation over model summaries or recycled secondary advice. Source logs and implementation notes stay with the project so the work can be maintained after handoff.

Deepprimary-source technical research · implementation references · source logs · technical manuals
Solidresearch packs · compliance matrices · operational documentation
09

Live production and AV

Deeplive events · corporate AV · broadcast signal chains · theater operations · crew coordination

25 years across live events, corporate AV, broadcast signal chains, theater operations, and crew coordination. Production systems where the show still has to happen at the scheduled time regardless of what broke five minutes earlier.

That background is why I understand venue and promoter workflows without needing the terminology translated, and it is where a lot of my instinct for staged, reversible changes came from.

More background
03 / Current stack

Tools I work with

Languages and runtime

PHP · JavaScript · TypeScript · Python · SQL · Node

Frontend

React · Vite · Tailwind · HTML · CSS

Data

MySQL · MariaDB · JSON · CSV · REST APIs

Infrastructure

Linux · Git · GitHub · SSH · DirectAdmin · OpenLiteSpeed · PM2

Search and analytics

Google Search Console · GA4 · Lighthouse · Matomo

AI and development tooling

ChatGPT · Claude / Claude Code · Codex · Gemini · Kimi

Current working stack — August 2026. Tools change; the underlying capabilities matter more.

Scope / Next step

What to do with this

If you know what you need, the services page explains scope and engagement options. If you're not sure which layer your problem is in, that's a normal reason to get in touch — figuring that out is part of the work.

See services Start a conversation