This week I pushed the same commit I pushed three weeks ago: refresh the cached data on a small static site and move on. Two minutes of work. One green square on the graph. That was the week. No new features, no releases, no architecture decisions. Just the autopost and a stale embed that needed updating again.
I am writing this down because the honest version of build-in-public includes the weeks where the most interesting thing that happened was a maintenance task you have already done before.
The Pipeline I Keep Not Building
The site is one I built and maintain. The stack is Astro with static output and TypeScript, deployed via a standard build pipeline. One section of the site pulls external feed data and renders it at build time. That means the section can drift. If the source changes and I don’t trigger a rebuild with fresh data, the section shows whatever was current the last time I ran the refresh script.
I mentioned in the September 7th post that I hadn’t wired up a scheduled refresh pipeline yet. Three weeks later, I still haven’t. The data went stale again. I ran the script, pushed, done.
The architecture itself is not wrong. Static-first is a deliberate choice: fast loads, predictable hosting costs, no server to babysit. The trade-off is that “current” requires an active trigger: either a manual push or a scheduled job that runs the refresh automatically and kicks off a new build. I know exactly what that job looks like. A schedule, a short shell script, a build hook. An hour of work, maybe two.
The reason it is not done is honest and a little embarrassing: that site is in maintenance, not an active build. The work that fills my weeks is Civo Cloud Manager, this site, architecture decisions. The site gets what it needs when it needs it. A stale section is annoying but not broken. So the pipeline keeps sitting at the bottom of the list.
That is a real software architecture decision, just not a flattering one. I am trading my own time (periodic manual refreshes) against the cost of building proper automation. Right now the manual refresh wins because the frequency is low enough. If the source changed daily and the section mattered more to the business, the calculation would flip immediately.
What a Week Like This Actually Tells You
If you are considering having a custom app or website built, weeks like this one are part of the honest picture. Not every week is a feature release. Some weeks are maintenance. The static-first choice I made for that site keeps hosting cheap and the site fast, but it created a small ongoing cost that I pay in minutes rather than money. That is a trade-off worth understanding before you make it, not after.
Good software architecture is mostly making those trade-offs explicitly and knowing which side of each one you are on. Bad architecture is making them by accident and discovering the cost later.
Two commits. An honest week. If you want to talk through what the right architecture looks like for your own project, the contact page is the place to start.
Take a look at the Civo Cloud Manager app page if you want to see what a more active week of shipping looks like.