Building and maintaining web applications and websites. CMS care, security updates, content changes, performance, analytics, SEO, integrations, and the hundred small fixes a real site needs every month. For the sites I’ve built and for the ones you already have. Project work, monthly retainers, or a combination — whichever fits the shape of your situation.
Why this is positioned as “web systems” rather than “web design”, and what that means for the work.
Most websites don’t fail all at once. They degrade slowly and quietly: a plugin stops being maintained, an SSL certificate expires on a subdomain nobody was watching, content goes stale because updating it requires logging into a CMS nobody remembers, a form silently stops submitting, page speed creeps up. By the time it becomes visible to the people running the organization, the site is an embarrassment — and the fix is usually larger and more expensive than ongoing care would have been.
The same pattern shows up in custom applications: a system gets built, gets quietly deprioritized for six months, and by the time anyone looks at it again the dependencies have rotted and a plugin update three versions ago broke a workflow nobody noticed. Both failure modes are avoidable with honest scoping, maintainable technical choices, and the understanding that building a system and keeping it running are two halves of the same engagement.
I think of the work as “web systems” rather than “web design” because design is one part of it. The system is the design plus the CMS plus the integrations plus the hosting plus the monitoring plus the documentation plus the person who knows how it’s put together. Get any of those wrong and the rest doesn’t hold up.
Marketing sites, organizational sites, content-heavy sites, and rebuilds of existing sites that have outgrown their current platform. Accessible from the start, performant by default, and built so the team that maintains it after launch can actually maintain it.
Purpose-built applications for specific operational problems — intake systems, scheduling tools, member portals, donor management extensions, reporting platforms, internal admin tools. Scoped honestly, built incrementally, and architected for handover rather than lock-in.
Clean integrations between the tools you already depend on — CRMs, payment processors, scheduling platforms, email systems, ticketing tools, analytics stacks. The connective plumbing so your systems talk to each other rather than your staff doing it manually.
Replacing manual hand-offs and “someone emails someone a spreadsheet” workflows with automated pipelines that are monitored, logged, and recoverable when things go wrong. Often the highest-ROI category I take on.
CMS core, plugin, and theme updates on a scheduled cadence, reviewed rather than auto-applied. Security-header and CSP maintenance. SSL and domain renewals tracked. Monitoring for known vulnerabilities in dependencies, with prompt patching when something matters.
The ongoing content work your team either doesn’t have time for or doesn’t want to learn the CMS for: new pages, content updates, image optimization, structured data, navigation changes, form updates. Routine changes typically turned around within a couple of business days.
Quarterly performance reviews against Core Web Vitals. Analytics and Search Console monitoring with flagged issues reported. Technical SEO hygiene — schema, sitemaps, canonical handling, redirects. On-page support for your content team. Accessibility re-checks on new content.
Uptime monitoring with human response to meaningful outages. Backup verification monthly (a backup you’ve never tested isn’t a backup). Email deliverability, DNS, and hosting changes handled as needed. A named point of contact who remembers how your site is put together.
The traditional webmaster work, organized into the foundation work that keeps a site running (Web 1.0) and the marketing-and-growth work that helps it reach the people it’s for (Web 2.0). Most engagements draw from both columns; not every engagement needs all of them.
Two areas live on dedicated pages because they need their own scope: accessibility (WCAG 2.2 audits and remediation) and HIPAA-aware web work (forms, portals, vendor coordination, documentation for compliance teams). AI integration also has its own page. Most engagements only touch one or two of those, but when they apply, the dedicated pages explain how I scope that work.
Project, retainer, or a combination — and what each is genuinely for.
Fixed-scope engagements for new sites and applications, integrations, or significant changes to existing systems. Scoped as a fixed-fee proposal after a discovery conversation, delivered incrementally with regular check-ins, handed over with documentation your team can use. Most project engagements run between four weeks and four months depending on scope.
A predictable monthly arrangement with a defined scope of ongoing work — security updates, a content-change allowance, monitoring, quarterly reviews, and priority access. The right shape for organizations that want to stop worrying about whether the site is being looked after. Retainers are priced against the shape of the work rather than hours, scoped after a first conversation.
Many engagements are both: a project build followed by a smaller monthly retainer for ongoing care. Often the most cost-effective arrangement — the work was just built, I know where everything is, and the retainer covers the small changes and watchfulness that keep systems from decaying.
Project or hourly work when something specific comes up — a migration, a page redesign, a new feature, a response to a security issue. No minimum commitment. Scheduled as capacity allows, which means less responsive than a retainer but available when needs are genuinely sporadic.
I take on maintenance for sites built by other developers regularly. The first step is usually a short discovery pass to understand what’s there, identify any urgent issues, and confirm the site can be responsibly maintained before committing to a retainer. If what I find can’t be responsibly maintained, I’ll tell you that rather than quietly patching over it.
WordPress, Drupal, Joomla, HubSpot, Wix, Squarespace, and custom-built stacks. For headless setups I support common pairings (WordPress or a headless CMS with a JavaScript front-end). If you’re on something unusual, describe it on a call — I’ll be honest about whether I can maintain it responsibly.
Yes — this is a regular part of the inbound webmaster work. I start with a short paid discovery pass to understand the site (CMS, plugins, hosting, any unusual components, obvious issues) before committing to a retainer. The discovery pass either becomes the first month of a retainer or stands alone if I decide the site isn’t a fit for me to maintain.
A retainer gets you scheduled preventive care, priority response times, predictable monthly pricing, and a named person who stays familiar with your site. As-needed work is cheaper in months when nothing happens, but slower to respond and handled on a best-effort basis. For mission-critical sites a retainer is almost always the right answer; for truly sporadic needs, as-needed can work.
Retainer clients have access to an after-hours channel for genuine site-down situations. For everything else I respond within the defined response window of your retainer (typically next business day for routine issues). I don’t run a 24/7 operations center, but I’m responsive, and I’ll be honest about what kind of response time I can commit to.
Yes. I can manage hosting on your behalf (billed through to you at cost, on your account wherever possible), handle domain and DNS changes, and coordinate transfers between providers. Retainer clients often have me as a named technical contact on their hosting and registrar accounts, which is usually simpler than routing everything through a non-technical staff member.
Yes, always. I build in your repositories, on your cloud accounts, with credentials you control. You own the code, the data, and the infrastructure — and my documentation is designed so you could replace me tomorrow if you needed to. I’d rather earn the retainer by doing the work well than by making the system impossible for anyone else to maintain.
Yes, when capacity allows. If your site is down, compromised, or in an urgent situation and you’re not currently a client, email directly with the word “urgent” in the subject and a brief description. I’ll respond the same day if I can, and tell you quickly if I can’t so you can seek help elsewhere.
Whether you’re starting fresh, inheriting a neglected site, or just want to stop worrying about whether the site is being looked after — a 30-minute conversation is the cleanest way to tell whether we’re a fit.
I won’t sell you a retainer you don’t need.
I’ll send a short set of questions beforehand so the call is useful from the first minute.
