Infrastructure, maintenance, security updates, and the client work that did not start while the team shipped a 'free' internal stack.
Someone on a developer thread put it better than most vendor decks do: no software works without infrastructure, maintenance, and security updates. Avoiding an expensive third-party tool can be rational. Pretending next year's bill will be zero is not. And while the internal team spent a month "saving" the subscription, which client projects were delayed or never started?
That is the question we hear when agencies and product teams use AI coding tools to stand up an internal dashboard, a scraper farm, or a home-grown PageSpeed loop. The first demo looks cheap. The second year does not.
What follows is how we price that trade-off when the alternative is buying a monitoring product, including our own: Apogee Watcher. We are biased toward layering a specialised tool onto the stack you already run. We are not biased toward pretending AI removes run cost.
AI coding assistants compress the time from idea to working prototype. A senior engineer can scaffold a multi-site Lighthouse runner, a Slack notifier, and a rough report page in days instead of weeks. The invoice for that month may show only tokens, coffee, and a weekend.
The demo hides four lines that do not appear on the prototype slide:
- Hosting, queues, storage, and secrets for something that must run every day.
- Dependency and runtime upgrades when Node, Chromium, or the Lighthouse API moves.
- Access control, audit logs, and incident response when client URLs and credentials sit in your system.
- The billable work that did not ship while that engineer owned the internal project.
Month one is a capitalisation of attention. Month twelve is operations. Those are different ledgers, and confusing them is how "free" tools become expensive quietly.
We are not arguing against building. We are arguing against incomplete cost models, especially when AI made the first commit feel almost free. The spreadsheet that only lists SaaS seats will always favour the internal prototype.
Infrastructure. Schedulers fail. Disk fills. Rate limits trip. Someone gets paged when the overnight suite stalls. A managed product folds that into a subscription; an internal tool folds it into someone's Friday, which is still a cost even when it never appears as a line item.
Maintenance. Lighthouse versions, PageSpeed Insights quotas, browser images, and OAuth tokens all age. The code that "just works" in March needs an owner in September. AI can rewrite a broken script. It does not attend the capacity meeting when three clients regress on the same weekend.
Security updates. Anything that stores client domains, screenshots, or API keys is a security surface. Patch cadence, least privilege, and offboarding when staff leave are not optional extras. They are the price of keeping the tool on the network without becoming the next incident review.
Opportunity cost. This is the line the comment nails. If a strong engineer spent four weeks on an internal monitoring stack, those weeks were not spent on a client launch, a performance remediation, or a proposal that might have paid for several years of a SaaS seat. "We avoided a subscription" is incomplete without "we deferred this revenue work."
For agencies, that last line is usually the largest. Delivery capacity is the scarce asset. Software licences are not.
Build versus buy for portfolio PageSpeed monitoring
Performance monitoring is a poor place to learn that lesson the hard way. You need history across many URLs, device splits, budgets, and alerts that arrive when a deploy breaks LCP. Building that once for one client is a weekend project. Building it for forty clients with permissions, white-label reports, and fair API quotas is a product.
We wrote our build-versus-buy framing for agencies in Lighthouse CI vs Managed Monitoring: Build vs Buy for Agencies. The short version for this discussion: CI gates and managed monitoring solve different jobs. AI makes the CI path faster to start. It does not erase the ownership tax of keeping a multi-tenant monitoring system honest.
If the honest goal is scaling client coverage without growing the monitoring headcount, the decision is less about whether AI can generate a script and more about whether you want that script to become a permanent internal product. Scaling Without Headcount is the Watcher-side case for automating the loops that expand with every new domain. That is the capacity question, not the prototype question.
Use this before you celebrate the "we built it ourselves" thread:
| Question | If the answer is no |
|---|
| Who owns patches and dependency upgrades in six months? | Budget an owner or do not start |
| Where do credentials, screenshots, and client URLs live, and who audits access? | Treat it as a security project, not a hackathon |
| What is the monthly infra and quota cost at full portfolio size? | Re-run the SaaS comparison at that size |
| Which client commitments slip if this takes four weeks? | Put that list next to the "saved subscription" slide |
| Will this layer onto tools we already trust, or replace them under pressure? | Prefer layer-don't-replace unless you have a retirement plan |
AI changes the cost of the first commit. It does not change the cost of being on call for the result. Treat ownership as part of the build estimate, not a surprise in month four.
Build when the workflow is a genuine differentiator, when compliance forces data to stay inside your boundary, or when you are extending a stack you already operate with spare capacity. Build a thin adapter. Buy the commodity loop.
Do not build because a social post claimed SaaS is a tax and AI is free labour. That framing skips maintenance, security, and the client work that paid the salaries funding the experiment. Those skipped lines are where next year's bill hides.
Count the full cost, then choose
Next year's bill will not be zero. Count infrastructure, maintenance, security updates, and the projects that waited. If the total still beats a specialised product after you price the opportunity cost, build with eyes open. If it does not, buy the monitoring layer and keep your engineers on client outcomes.
We built Apogee Watcher for the second case: multi-site PageSpeed schedules, budgets, and alerts without asking your team to become a second product company. Layer it on. Keep the AI assistants for the work that is uniquely yours.
Originally published on Hashnode.