I am a Drupal developer based in Pflugerville, Texas, about fifteen miles north of downtown Austin. I have spent more than twenty years building for the web and the last fifteen of them almost entirely in Drupal, from Drupal 6 through Drupal 11. I maintain more than twenty-seven contributed modules and themes on drupal.org, including the Solo theme, Paragraphs Bundles, Cloudflare Purge and the Views Vanilla JavaScript suite. This page is about working with me specifically, and about what being in Austin does and does not change.
What Being Local Actually Changes
Let me be straight about this, because most local service pages are not. Drupal work is not plumbing. Almost none of it requires anyone to be in the room, and I have delivered enterprise Drupal work for organisations in other states and other time zones without it costing them anything. If you are in Seattle and you need a Drupal architect, hire the right one, not the nearest one.
What proximity does change is narrow but real. It is easier to sit with a content team for a day and work out a content model on a whiteboard than to do the same thing over three video calls. Discovery for a large migration goes faster in person, because the people who know where the bodies are buried tend to mention them in passing rather than in a meeting. Executive stakeholders who are nervous about a rebuild are reassured by a face. And being in the Central time zone means a full working day overlaps with almost everyone in the United States.
If those things matter to your project, being an hour from most of the Austin metro is useful. If they do not, the work is the same work.
Who I Work With Around Austin
Austin has an unusual concentration of the kinds of organisations that end up on Drupal: universities and research groups, state and municipal agencies, healthcare systems, non-profits and associations, and companies that outgrew a simpler content platform. Those organisations share a set of problems that Drupal is genuinely good at and that other platforms handle badly — structured content with real editorial workflow, multiple sites sharing one codebase, accessibility obligations that are not optional, and content models that need to survive a decade rather than a redesign.
They also share a specific risk. A Drupal site built by a team that has since moved on, running a version that is now behind, with custom code nobody remembers writing, is an expensive thing to inherit. A large part of my work is exactly that: reading somebody else's site carefully enough to say what it would take to bring it forward, and being honest when the answer is not what anyone wanted to hear.
What I Do
The detail for each of these lives on its own page, but in short: custom module development against current APIs; theming with Twig, render arrays and accessible markup; version upgrades and Drupal 7 migrations; ongoing support and maintenance; security reviews; architecture consulting before a build starts; code review of work done by others; and performance work diagnosed by profiling rather than guesswork.
If you want the longer background rather than the service list, the Drupal developer guide, the Drupal themer guide and the Drupal architect page describe how I think about each of those roles and what separates someone doing them well from someone doing them adequately.
Drupal 7 in Texas, Specifically
Drupal 7 reached end of life on 5 January 2025 and receives no security coverage from the Drupal Security Team. A surprising number of Texas public-sector and institutional sites are still on it, usually because the original build was solid enough that nothing forced the issue. That is exactly the situation where an unhurried, properly inventoried migration goes well and a panicked one goes badly.
The move off Drupal 7 is a migration rather than an upgrade — the content carries across through Drupal's Migrate API, but the theme and any custom modules are rebuilt against an architecture that changed completely at Drupal 8. That means the honest first step is an inventory, not a proposal: what contributed modules are in use and what replaced them, what custom code exists, what the content model actually contains, and how much of it is still earning its place. The inventory is what makes an estimate worth anything.
How I Prefer to Start
With a written assessment rather than a pitch. For most projects the first useful deliverable is a document that says what your site is, what shape it is in, what the options are, and what each one would realistically cost in time. Sometimes that document concludes that the work is smaller than you feared. Occasionally it concludes you should not do it at all this year. Either way you own the document and can take it to anyone.
I work solo, which has an obvious trade-off worth naming: you get the person who wrote the code rather than an account manager, and you do not get a bench of ten people to throw at a deadline. For a focused build, an upgrade, an audit or ongoing maintenance, that is usually an advantage. For a project that genuinely needs six people in parallel, it is not, and I will say so.
I have worked in web development since 2005 and I am the author of Drupal modules and themes. The code is public, so you can read it on my drupal.org profile before we talk.
Get in Touch
Tell me your Drupal version, roughly what the site does, and what is prompting the conversation — a deadline, an audit, a security notice, a redesign, or a site nobody wants to touch any more. That is enough for me to tell you whether I am the right person and what the first step would cost. Get in touch and we can work out whether it is worth a longer conversation. If you already know the scope, you can request a quote directly.
