Build the evidence, not the bullet point
· Brandon Crenshaw
This week I wanted to add three things to my site: Google Cloud, enterprise cloud, and industrial automation. Job postings ask for all three, I have adjacent experience for all three, and the temptation to write a line and move on was real.
So I searched my own repositories first. Here is what was actually there.
No Cloud Run. No Pub/Sub, no BigQuery, no Cloud Build, no Google Cloud client library anywhere. I use Gemini, which is a Google API and not Google Cloud infrastructure. Two repositories mention Terraform or Kubernetes and nothing of mine runs on either. Nothing industrial at all: no Modbus, no OPC UA, no PLC code.
The honest read is that I had none of it. Not a little. None.
Why the line would have cost more than it earned
A resume line is a claim, and a claim gets tested by exactly one question from someone who does this daily. The first follow up on Cloud Run is whether you used a service or a job, and why. If the answer is vague, the interview is over and so is your credibility on everything else you said.
The rest of my site is built on claims a reader can check. Every project links to a running product, every badge comes from a daily check rather than someone typing the word Live, and every case study ends with a section that says what is not proven yet. Adding one unverifiable line to that page would have been the cheapest possible way to make the rest of it worth less.
A weekend is enough to make it true
The pipeline I already run watches a few sources every two hours, scores what it finds, and files the leads. It runs on GitHub Actions. That is a fine place for a schedule and a poor place for everything after it: no query surface, no way for anything downstream to subscribe, and state living in a spreadsheet shaped database.
So I ported it. Cloud Scheduler triggers a Cloud Run job. The job collects, dedupes, scores in code, writes every row to BigQuery and publishes the ones that clear the threshold to Pub/Sub. All of it is Terraform, and the whole thing can be destroyed and rebuilt from nothing.
Four decisions in there are worth more than the port itself.
**A job, not a service.** The work is periodic. A service sits there between runs being billed for readiness it does not need. A job starts, does one pass, exits with a status, and the scheduler owns the question of when.
**One identity per component.** The worker can write one table and publish to one topic. The scheduler can start one job. Neither can do the other one's work. If either credential leaked, that is the whole blast radius, and it is short enough to say out loud in a room.
**Retries have to be safe, because retries are certain.** Cloud Run retries a failed job, and a retry is a rerun. Rows carry an insert id, so BigQuery drops the duplicate instead of adding a second copy of the same lead. Without that, you get punished for having failure handling at all.
**Partitioning is the cost control.** BigQuery bills for bytes scanned. The table is partitioned by day and clustered by source, so a query over yesterday reads one day. I did not really understand that until I deleted a where clause and watched the number jump.
It sits inside the free tier at twelve runs a day. About 7,200 vCPU seconds a month against an allowance of 180,000.
The part that makes it learning instead of copying
The repository has a file called LEARN.md. Eight steps, each with a command to run, a file to read, and a question to answer. The questions are the point:
Why does the worker need both a role on the table and a role on the project, and what breaks if you remove either.
What happens to your rows when a job fails halfway and retries.
Which saved you money on that query, the partitioning or the clustering.
What does a Pub/Sub ordering key guarantee, and what does it deliberately not guarantee.
If I had asked a model to build this and then moved on, I would own a repository and know nothing. Writing the questions down forced me to be able to answer them, which is the only version of this that survives a conversation with an engineer.
What I still will not claim
The thing is built, tested and not deployed. The Terraform validates against the real provider and the worker's tests pass, which proves the shape is right and proves nothing about the operational reality. It has never met a quota, a cold start under load, or an API having a bad afternoon.
So its page on my site says exactly that, and the cost figures are labelled as coming from pricing pages rather than from a bill. When it has run for a month, that paragraph gets replaced with real numbers and gets shorter.
Industrial automation got the same treatment, which is to say I left it off entirely. I have process automation, which is a different thing wearing a similar word, and pretending otherwise would fail on the first specific question.
Try this on your own site this week
Pick the skill you most want to claim. Search your own repositories for it before you write a word. Not your memory, your repositories.
If the evidence is there, link it. If it is not, you have two honest options: leave it off, or spend a weekend making it true and write down what you learned while it was still confusing. The second one costs about the same as arguing with yourself about whether the line is defensible, and at the end you own something that answers the follow up question for you.