Full-stack developer Cartersville, Georgia shane@traveltamers.com

I build production software and I stay on call for it.

I am a full-stack developer who writes every layer of the systems I take on — the database schema underneath, the application code that sits on top of it, the deploy scripts that push it all to production, and whatever else turns out to need writing along the way — and I am the person every alert reaches when any piece of it misbehaves in production.

I came into this line of work from the other side of a Google spreadsheet that had grown, over a couple of years, to forty-one tabs. If you are currently running a business out of a shared document you are afraid to close, I have been you. The thirteen-service platform described below is what I wrote to replace mine, and it is still what I use to run the agency it was written for.

Take a look at what is running →

I am taking on two or three new engagements for the remainder of 2026, and I respond to inbound email within a single business day, without exceptions. The list of systems below is accurate as of whenever you loaded this page, because the pager that alerts me when any one of them stops responding is the phone in my pocket, which has not been further than arm's length from me in two years.

01 / WORK

The systems I have built and am still running.

Each of the projects below is in production at the URL given, and each is maintained by me and no one else. I have ordered them roughly by how much of my working week they actually occupy, rather than by how impressive they might look to someone who has not had to maintain them.

01

TravelTamers

traveltamers.com
Live since July 2024

TravelTamers is the platform I use to run a working travel agency, and it is also the thing that most of my working week is currently spent on. I started it in the summer of 2023 as a single Hono endpoint talking to one Postgres table, and in the two years since, it has grown into five interconnected applications sharing three databases, roughly one hundred and nineteen tables between them, sixty or so automations orchestrated in n8n, and a conversational concierge named Miles, who is usually Claude but falls back to a small model running on the VPS itself when the Claude API is unreachable. Every piece of it runs on the same two-CPU, eight-gigabyte rented box.

If you would like a concrete sense of the engineering sensibility, here is one decision I am fond of, mostly because it has survived everything since. The synchronization between the customer-facing API and the Nexus CRM is fire-and-forget with a three-retry exponential backoff, and anything that survives all three retries is routed to Sentry for me to triage. I chose that pattern over a proper job queue because the only hard requirement was idempotency, and idempotency is much easier to put into a single middleware file than it is to thread correctly through a queue.

Astro 5 · React 19 · Hono · PostgreSQL 16 · Drizzle · Claude · Ollama · Docker · Traefik · n8n

Read how I built it →
02

Nexus CRM

nexus.traveltamers.com
Live

Nexus is the customer-relationship platform I wrote to handle the sales pipeline, email campaigns, service desk, and knowledge base for the travel business that TravelTamers supports. It contains fifty-four tables, a five-tier role-based access system, and a Socket.io layer that pushes notifications to whoever is looking at a record when someone else modifies it. Nexus lives in its own set of containers on the same VPS as TravelTamers, and the two of them communicate through the fire-and-forget sync I described above.

Fastify 5 · React 19 · PostgreSQL · Redis · BullMQ · Socket.io

Read the architecture →
03

Groups

groups.traveltamers.com
Live

Groups is a smaller application that handles collaborative trip planning. One person creates a trip, other members propose itinerary legs, the group votes on what stays, and the application generates a cover image for each trip using Replicate's FLUX model. It is written in plain Express with server-rendered EJS templates rather than the React stack I use elsewhere, because I wanted one part of the platform to live in a lower-ceremony framework as a point of comparison for myself.

Express · PostgreSQL · EJS · Replicate

Read the architecture →
04

Miles, the concierge

Embedded in traveltamers.com
Live

Miles is the conversational agent that appears on the marketing pages of TravelTamers. By default he is a thin wrapper around Claude: he reads an inquiry, asks Perplexity for any time-sensitive pricing or availability information it needs, and drafts a three-option itinerary with sources attached. When Claude is unreachable, either because of trouble on my end or an outage on Anthropic's, he falls back to a small open-weight model that runs on the VPS itself, so a visitor always gets an answer of some kind.

Claude API · Ollama · Perplexity · Hono

Read how he answers →
05

The n8n automation hub

automations.traveltamers.com
Live

My n8n instance holds somewhere around sixty workflows that handle the interstitial work the rest of the platform would otherwise have to do itself. The ones that earn their keep every day are a daily social-content pipeline, which ingests trending travel news, filters it through a local model, asks Claude for editorial judgment on the top five stories, and hands the result to Replicate for image generation; a lead-scoring flow that runs whenever a form is submitted; and a recurring passport-expiration check that compares every upcoming booking against every passport on file. Everything else is a small sync or notification that was easier to write as a workflow than as a cron job.

n8n · Claude · Perplexity · Replicate · Slack · Buffer

Read the workflows →
06

Filename-as-Specification

Methodology · open approach
Published

Filename-as-Specification is a methodology I developed for keeping AI coding agents from hallucinating. The core idea is to encode the full specification of a file into the filename itself, in a grammar the agent parses before it writes any of the body, so that the agent cannot drift from what was asked for without first changing the name of the file. An architect agent proposes the names, a code agent implements the bodies, and a validator walks the resulting tree in six phases to confirm that what got written is what the filename demanded.

Python · MCP · Claude · deterministic grammar

Read the full approach →
07

Refined Vacations

refinedvacations.com
Shipped

Refined Vacations is an eco-adventure travel brand for which I built and continue to maintain the marketing site. Before we listed anyone, I audited one hundred and eleven candidate partners and kept the seven whose sustainability claims held up under scrutiny, and the gap between those two numbers is the whole argument of the brand. The site itself is hand-written PHP on top of a Fibonacci-derived CSS system, because the voice of the brand is skeptical of greenwashing and I wanted the visual system to feel considered rather than templated.

PHP 8.3 · custom CSS · editorial voice system

Read the case study →
08

Pickleball at Sea

pickleballatsea.com
Shipped

Pickleball at Sea is a small business that organizes pickleball tournaments on cruise ships and at resort properties, and the site I wrote for it handles registration, bracket generation, scoring, photo galleries, and the event calendar. It is by far the smallest system on this page, and although my family is impressed with none of the others, they are impressed with this one, which is probably the most accurate review the site will ever receive.

Node 20 · Express 5 · SQLite (WAL) · EJS · Docker

Read the case study →

If you would rather hear what someone other than me has to say about any of this, Claude has written a letter of recommendation after having spent most of the last two years pair-programming with me.

02 / ABOUT

How I got here.

I came into software from travel, and not the other way around. In 2023 I was running a small travel agency out of Cartersville, Georgia, and the whole operation was being held together by a shared Google spreadsheet that had grown, over a couple of years, to forty-one tabs. It was clear that the agency was never going to scale that way. The margins would not have supported hiring additional staff, and most of what additional staff would have done was look things up inside a spreadsheet. What the business actually needed was software of its own, and because nothing I could buy off the shelf matched the specific shape of the operation, I decided to sit down and write the software myself.

I began with the database, because the schema is the part of any system that is most expensive to get wrong in the long run. Once the schema was in place the rest of the platform followed in a fairly natural order: first a Hono API on top of the schema, then a marketing site on top of the API, then Miles the concierge on top of both, and eventually a full CRM to replace what the spreadsheet had been pretending to be. Somewhere in the middle of that eighteen-month stretch the project stopped being a side interest and became the main thing I spent my working hours on.

The stack I use is deliberately unromantic, in the way a good toolbox is. It is whatever I have found will get a piece of software into production on a small-to-medium VPS and keep it there without drama, which has meant Astro and React on the front end, Hono and Fastify on the API tier, PostgreSQL as the only database worth having, Drizzle for the schema layer, Docker and Traefik at the network edge, n8n for the glue work between services, Claude for the parts of a workflow that call for real judgment, and a locally hosted model for when the network will not cooperate. I have held to this stack for almost two years now without once feeling the urge to replace any of it, which I take to mean that the original choices were probably defensible. If none of those names mean anything to you, the translation is that I have not swapped any of them out in two years, and I do not plan to.

What I do for a living, if the description has to fit inside one sentence, is own complicated multi-service systems end-to-end. That means that on any engagement I take, the same person writes the database schema, the API, the deployment scripts, and the middleware that has to be added urgently when something unexpected breaks, and that same person is the one every alert reaches. I like the work, and I have no particular plans to do anything else.

03 / METHOD

Three habits I can substantiate in code.

These are the three things I have found matter most in the kind of work I do, and I offer them here in the form I can actually defend, which is to say with reference to the running configuration rather than to a promise.

The stack I ship on is the stack I keep.

TravelTamers went into production on Astro 5, Hono, and PostgreSQL 16 in the summer of 2024, and the platform runs on exactly the same stack today. I have not quietly rewritten parts of it during slow weeks. I have not taken a month off in the middle to evaluate whatever framework was fashionable that quarter. Commitments about long-term maintenance are only credible coming from someone with a visible track record of resisting the urge to rewrite something working, and a two-year-old repository with no framework migrations in its history is about as visible as that track record can reasonably be.

There is no handoff, because there is no one to hand off to.

On every system I run, the same person who wrote the original schema is the person who writes the fix for whichever bug in the schema eventually surfaces. The idempotency middleware in my main API lives in a short file at mw/idempotency.ts, and the reason the file exists is that I personally watched duplicate webhooks double-write deals in production and wrote the hash-into-Redis fix myself. A duplicate webhook, for anyone who has not had to worry about one before, is the sort of thing that charges a customer twice or books the same room twice if nobody has thought about it in advance. There is no institutional knowledge that gets lost in a transition, because the institution is one person, and that person keeps remembering.

The documentation follows the code, always in that order.

The system guide elsewhere on this site is seven chapters that were written after the corresponding code was already in production, by reading the running configuration back out into prose. None of it is a roadmap, none of it is a pitch deck, and none of it is speculation about what the system might eventually do. If the guide says a thing exists, then the thing exists in the repository. If something is not in the guide, it is because I have not yet written the code for it, and I will not put it into the documentation until I have.

04 / CONTACT

How to get in touch.

I take on two or three new projects a year, and the match I am looking for is narrow enough to describe in a paragraph. What I want is a founder, or an operations lead, whose system already has users and already hurts — that is, a backend composed of several services, a real database with real data already in it, and a deployment process that should exist by now and somehow never quite has. I will disappoint you if what you actually need is a greenfield marketing site, a Figma specification in advance of any code, or a person to lead a team of twenty engineers. If you belong to the first group, please send me an email describing what has gone wrong, and I will reply within one business day.

Email me directly

shane@traveltamers.com

The particulars

AvailabilityTwo or three projects per year
Reply windowWithin one business day
KickoffUsually within two weeks of the first call
Time zoneUS Eastern, comfortable async
EngagementTwelve months and up, pager included
Your message has arrived. I will reply within one business day.
Something went wrong on my end. Please email me directly at shane@traveltamers.com.