Case Studies

The problem

Jill, the owner, runs the business and does much of the work herself. She fields a constant stream of calls: new inquiries, rescheduling requests and cleaners who can't make a shift. With so much routine traffic, calls that could become new work get missed. Every quote is also built by hand, even for people who are only browsing.

What we're doing

Start with how the business works. Before choosing any technology, we're mapping the real workflows with the owners to find where AI will deliver the biggest return first.

Phase 1: Protect Jill's time. The goal is to clear Jill's path. The first solution will:

• Answer basic questions and keep website visitors engaged
• Give an instant cleaning estimate based on the property
• Pass serious prospects and important calls to Jill, so she writes full quotes only for people ready to move forward
• Handle routine requests, like rescheduling, and keep Jill informed

Phase 2: Coordinate the whole operation. Longer term, a set of AI tools will connect clients, cleaners and Jill. When a client or a cleaner needs to change a visit, the system will find the property, the job and the people involved, and coordinate the change between them. Jill steps in only when a decision needs her approval, based on rules she sets.

Connect to the tools they already use. Everything will run through GoHighLevel, their CRM, and Jobber, which tracks clients, visits, quotes and jobs, so nothing is entered twice.

What we'll measure

• Fewer missed high-value calls
• More website visitors turning into leads
• Less of Jill's time spent on routine requests and dead-end quotes

Status: Discovery in progress. Results will be added as the work moves forward.

The problem

The company replaced its core finance and HR systems with Microsoft Dynamics GP, NetSuite, ADP Payroll and ADP Recruitment. Some were upgrades, others were new vendors. Bad data in these systems means wrong financial reports, payroll errors for 2,000 people, or missed FCC reporting that stations need to keep their broadcast licenses.

What we did

Own the data. I owned the data migration for every one of these systems and led report creation for each rollout. For accounting, that meant about 20 years of records: the last five years in full transaction detail and older years summarized. For HR, we moved current data only, as HR requested.

Learn the business. To get it right, I learned how each team actually works: accounts payable, accounts receivable and the general ledger in finance, how payroll staff use their system day to day, and what recruiting data the stations must capture for FCC EEO reporting.

The results

• Highly accurate data in every new system, because I knew the old and new systems well enough to translate between them
• Reports finance and HR could rely on from launch
• Recruiting data that supported the stations' FCC EEO reporting

After the rollout, the HR director wrote to the IT director about my role. She described me as respectful throughout, said I eased tense discussions with a bit of humor, and said she was very happy with how the project ended.

The problem

The company chose WordPress as its new CMS, and the whole team was new to it. We hired an experienced WordPress developer to build the first site and to teach the rest of the team along the way. We knew depending on one developer was a risk, and as a company we accepted it. That is why we started with the station that had the least impact on viewers and revenue. Several months later, the site went live on a Monday. On Tuesday morning, his resignation letter, effective immediately, was on my desk. The team was learning WordPress alongside him while still supporting our existing applications, and it wasn't up to speed yet. We had a brand-new live site and no one on staff who knew it well.

What we did

Act. I went straight to the IT director and got approval to contact a local Minneapolis development agency. Within hours, they sent the resume of a senior WordPress developer available part time.

Structure the engagement. I negotiated a phased arrangement. For the first month, he worked on site three days a week alongside our team, teaching WordPress and our specific build. As the team took on more responsibility, he moved to an advisory role for the rest of a four-month engagement.

The results

• No rollback to the old website
• No impact on the station or its audience
• The team taking ownership of the site within the first month
• A planned four-month consulting cost instead of a rushed hire
• Time to find and hire the right permanent replacement

The problem

Fifteen days before going live, the company's network architect resigned. Its websites and databases ran in its own data center, and traffic was unpredictable. A quiet day could turn into a sudden surge when severe weather or breaking news hit. Replacing the role safely meant hiring two architects, a lead and a backup, at about $110,000 each.

What we did

Instead of treating it as a hiring problem, I recommended to the IT director that we use it as a chance to rethink hosting. Working with the network manager, we added up the real cost of self-hosting: two architects, infrastructure, a firewall and caching servers. It came to roughly $250,000 a year. We evaluated fully managed hosting providers and moved all seven sites and their databases to the best fit. The provider took over backups, security patching, firewall protection and CDN caching, and absorbed traffic spikes.

The results

• About $125,000 saved per year ($125,000 for managed hosting vs. an estimated $250,000 to self-host)
• No need to hire and keep two network architects
• Weekend on-call calls dropped from 2 to 4 per weekend to zero
• Fewer outages and faster pages, even during news and weather spikes

The problem

In our regular meetings, the IT director raised a growing concern. The company had no reliable way to track which assets and permissions each person held as employees joined and left. Access often spanned several business units, so former employees could keep permissions they should have lost. That was both a security risk and an audit exposure.

What we did

Plan. I turned the concern into core requirements, then scoped a simple prototype to prove the approach before investing further.

Build and mentor. Instead of building it myself, I guided an infrastructure engineer who wanted to move into development. I coached him to design the database around how the business would actually use the data, so it could adapt as the company grew. We built in a full audit trail and role-based access, so each user could do only what their job required.

The results

• The prototype went into everyday use across the business units
• About 100 hours saved every month across the company
• Much lower risk of former employees keeping access after leaving
• A flexible design that made it easier to bring acquired companies into the system
• The engineer continued growing as a developer

The problem

Our news sites had to stay stable through sudden traffic spikes during breaking news and severe weather. At the same time, our release process was manual. We didn't use Git, had no test environment and made changes by hand. That led to errors, lost time and frustrated users. For years, I had asked for change control and separate development and test environments, but they were never in the budget.

What we did

Choose guardrails. After deciding to move to managed hosting, we chose Pantheon partly because it is strict. Code can't jump from development straight to the live site. Every change has to pass through development, testing and live environments in order.

Change how we work. We moved all seven sites onto Pantheon and rebuilt our process around it. Every change went through GitHub, so it was tracked. Changes moved through all three environments before reaching the public. We tuned caching and performance so the sites held up under traffic spikes. Instead of working around the platform, we used it the way it was designed.

The results

• A stable platform that held up through news and weather traffic spikes
• Every change tracked and tested before going live
• Fewer release errors and less time lost fixing them
• Our team was named one of Pantheon's Best in WebOps Top 20 in 2023, the first year of the awards
• Full value from the hosting investment, because we used the platform instead of bypassing it

Further reading

• Pantheon's Best in WebOps Top 20 announcement (2023)
• Pantheon's published case study on this project

The problem

I introduce technology into my own business the same way I do with clients: use it on myself first, set the rules, find the limits and keep what works. My website was the latest test.

WordPress is an excellent CMS, and it earned its place. The admin is mature, non-technical people can publish without touching code, and most features are a plugin away. My issue was the front end: the site a visitor actually loads.

A standard WordPress site builds every page on demand. Each visit runs PHP and queries a database, so pages are heavier than they need to be, and speed becomes a moving target that depends on server load, the theme and whichever plugins are active that day. Running it well meant a caching layer to survive traffic spikes and a firewall to watch the doors WordPress leaves open: live code on every request, a login, a database and a stack of third-party plugins. All of that machinery existed to manage a problem the architecture created.

What I did

Start with the common plan. My first move was to keep WordPress as the CMS and put Astro in front of it. Astro builds static HTML, so the pages it serves are fast, light and have almost nothing to attack. A process would export posts and category pages from WordPress and rebuild them in Astro. For many businesses, that headless setup is the right answer.

Question the piece I assumed I needed. Working in Astro alongside Claude Code, I asked a simpler question: why keep the CMS at all? I kept WordPress only to write and organize content, and I was already writing in my editor with Claude Code checking grammar, flagging repeated ideas and telling me whether the text said what I meant.

Manage content in plain language. Then it went past writing. I asked Claude Code to build a page for my frequently asked questions, and from there I managed it in plain words: add this question, remove that one, group them by category. At that point it was doing the job of a CMS, so I retired WordPress.

Be honest about what is still manual. The site is now static files on Firebase Hosting, with no server running my code, no database and no login. I make changes with Claude Code and deploy the built site myself. The next step is conversational maintenance: saying "update the website" or "show ten posts in this category instead of twenty" and having it happen.

The results

• Content changes, like adding or grouping FAQ questions, made in plain language with AI instead of a CMS
• One less system to run: no CMS to update, patch or log into
• No server, database or login on the site, which leaves almost nothing to attack
• As a consequence of the move, mobile PageSpeed performance went from a score that swung between 65 and 75 to a consistent 98
• On mobile, Best Practices and SEO both score 100, Accessibility scores 93, and the site passes all 3 Agentic Browsing checks

Where I would still choose WordPress: this works because I am a technical team of one and the approval loop is just me. If several non-developers publish content, need a polished editor or schedule posts, WordPress is still the right tool, often with the headless setup I first planned in front of it. Rebuilding that in code to follow a trend would be a mistake.

I use AI in my own business where it earns its place, and here it replaced a whole system. I bring the same test to client work: test it on a real process, set the rules, find the limits and keep what fits how the business actually works.

The problem

The newsroom asked for a tool to control the order of stories on its sites. The goal was to install it on all seven stations, starting with the main one because that site had to work. It passed development testing and a week and a half of staging review. About 90 minutes after it went live on the main station, stories began disappearing and reappearing on its site. For a news organization, that is a credibility problem.

What we did

Contain. I treated it as an incident. Using our monitoring tools, we confirmed the pattern, isolated the new tool as the cause and switched it off. The site was stable within about an hour.

Diagnose. We rebuilt staging as a full copy of production and reproduced the failure. The tool created heavy database load that only appeared at production scale, which is why earlier testing missed it.

Decide. Fixing the tool would have cost more than replacing it, and it was outside the team's expertise. An off-the-shelf plugin was available for $100 a year, but the director of TV digital operations would not have been happy with the result. I pushed for a custom build even though it cost more, and made the case to leadership to bring in a specialist vendor to build a plugin designed for our scale.

The results

• Main station site stable the same day
• Newsroom got the capability it asked for, built for our traffic
• Custom plugin rolled out to all seven stations
• Testing with production-scale data added before major releases
• Team stayed focused on core work instead of rewriting unfamiliar code

What I learned: before a release, agree with the whole team on what "testing" means. We had discussed the testing plan and assumed we understood each other, but it meant something different to me than it did to the website manager in charge of the testing.

The problem

The company planned to host its news websites in its own data center, on load-balanced web servers and a database server. For a newsroom, an outage during breaking news means lost audience and lost trust. Leadership needed to know what would happen if any part of that setup failed.

What we did

Plan. In the early stages, I represented the development team on a disaster recovery committee with the IT director and the network and security compliance manager. Together we defined how to switch to a standby copy of production, with current code and data, and how to switch back without losing anything. As the plan took shape, the full development and network teams joined to take ownership of their steps.

Coordinate. No single team could run the plan alone. The network team owned some steps and my team owned others. We mapped every step to an owner and set clear lines of communication, so everyone knew the full plan and who to call.

What happened next. We scheduled a weekend failover test during low traffic. The plan depended heavily on our network architect, and before the test ran, he resigned. With only a junior network architect left, senior leadership decided not to run the test rather than risk an outage. The company then moved to fully managed hosting, and the provider took over recovery.

The results

• A complete recovery plan, agreed across the IT department
• Every step assigned to a clear owner
• A failover test scheduled to confirm zero data loss

The problem

The company depended on outside partners: specialists for SEO, design and short-term development, a hosting provider, the Associated Press news feed, and enterprise systems like ADP, NetSuite and Microsoft Dynamics GP. Without one accountable person, problems bounce between vendors, costs creep up and issues sit unresolved.

What we did

Specialists on demand. I brought in SEO experts, graphic designers and extra developers for a few days or a single project, and managed their scope, timelines and hand-offs.

Hosting. I owned the hosting provider relationship from the WordPress implementation through the rest of my time there.

Associated Press. I was the technical contact with the AP. I kept our sites current with their API requirements and worked directly with them to resolve any issues with the feed.

Enterprise systems. I worked closely with ADP support to get our tickets resolved. For NetSuite, I owned reporting and data loads, and led the conversation with the vendor whenever data or reports had problems. I was also a point of contact with the Microsoft Dynamics GP vendor.

The results

• Every vendor knew exactly who to contact when they needed information
• Faster issue resolution, because problems no longer bounced between people
• Cost savings from fewer delays and less time lost chasing answers
• Specialist skills brought in only when needed, instead of added headcount

The problem

We were designing an in-house system, and my team split on the approach. Our network architect was convinced his solution was the right one. The development team, including me, had serious doubts. The stakes were high: the wrong choice could have led to data corruption. A split like that can also stall a project, or leave people disengaged long after the decision is made.

What we did

Listen. I kept the discussion open and respectful. We put the options side by side, laid out the pros and cons of each and made sure every view got a full hearing, including the one I disagreed with.

Decide. As team lead, the call was mine. I weighed the options with data integrity as the top priority and made the decision. We documented the decision and the meeting notes, so we could look back at the reasoning later.

Stay open. As the work went on, some requirements changed. Our notes let us revisit the architect's ideas, and several fit the new needs. The final application combined both approaches.

The results

• A clear decision that protected data integrity
• An application the whole team was happy with
• Trust between the architect and the development team stayed strong after the disagreement
• A documented record that made it easy to adapt when requirements changed

After the meeting, the network architect came to me and told me that, even though he and the development team disagreed, he felt heard.