Saturday morning I was staring at theapparchitect.com’s hero section and something was off. The stat I had been showing — “116 GitHub stars” — is real, but it answers a question no business owner is actually asking. They are not asking whether other developers think my repos are interesting. They are asking whether I have shipped anything that people actually use. Four commits later, that number was gone. By Sunday afternoon the same audit had touched three separate sites. No new features. No new pages. Just an honest reckoning with what “proof” means when you are trying to earn the trust of someone who wants custom app development.
What Weak Proof Looks Like in the Wild
The GitHub stars stat had been sitting in the hero strip for a while. I put it there originally because it is an easy number to pull dynamically and it signals that the code is visible and real. But the more I looked at it this week, the more I thought: if a small business owner lands on this page trying to figure out whether I am the right person to build their app, “116 developers bookmarked a repo” tells them almost nothing.
“4 apps live in the App Store” tells them something they can verify in thirty seconds.
Swapping those two lines was a one-commit change to the EN homepage — sha: 8bda547 — but the decision behind it took longer than the implementation. I sat with it for a bit because I had to be sure I was not just trading one vanity metric for another. Four apps is a small number. I could have inflated it with project prototypes or internal tools. I chose not to. Four means four things a stranger can download today. That felt more honest than a larger but softer number, and honesty is the whole point of building in public.
The DE homepage got the same treatment in a follow-up commit — “Apps live im App Store” instead of the German equivalent of the GitHub stars line — to keep the two language versions in parity. I am meticulous about this. When EN and DE drift apart in what they promise, it erodes trust in exactly the readers who are careful enough to notice.
The Calendar Problem: Hidden Until You Click
The second meaningful change on theapparchitect.com was to the booking section. Previously the live calendar was behind a click — a “Show calendar” button that revealed the embed when pressed. The reasoning at the time was performance: the calendar widget adds a third-party script load, and I did not want to block page render for visitors who were not going to book anyway.
The problem is that hiding the calendar introduces doubt. A visitor who is genuinely ready to book a call has to take an extra action before they even see whether there is a slot available. That friction is small in absolute terms, but small frictions compound. I flipped the embed to load immediately, accepted the slight script cost, and removed the button entirely.
I also added what I am calling an “honest no-logos proof line” in the same commit. A lot of agency sites run a row of client logos in the social proof section. I do not have a roster of recognizable enterprise clients I can name in a strip of SVGs. So rather than fake that pattern or leave the space empty, I replaced it with a plain-language statement about what I actually have: shipped apps, public repos, and a verifiable track record. It reads less impressively than a logo from a known brand. I think it reads more honestly, and I would rather have that.
civo-cloud-manager.app and marcelrgberger.com: Same Audit, Two More Sites
The same thinking carried over to the marketing site for Civo Cloud Manager, the native macOS app I built for managing Civo Cloud infrastructure — Kubernetes dashboards, S3 browser, menu-bar firewall, Touch ID protected credentials, the works. One commit there (sha: bc146b9) fixed several things at once: the hero trust strip now leads with “source-available” rather than vague language, the free-tier hook is more prominent, and a piece of microcopy about the macOS version requirement got corrected. There was also an alt text bug — a screenshot was reusing the alt text from a different image, which is the kind of thing that only surfaces when you go through a page slowly and deliberately. Bad alt text is an accessibility failure and an SEO signal I do not want to send.
On marcelrgberger.com, the portfolio site, the GitHub API call that powers the “code footprint” stat was hitting the unauthenticated rate limit in production and failing silently — showing zero or a stale cached value. I added authentication to that fetch and while I was in the file I added proper hero CTAs that had been missing. That one I am not fully happy with yet. The API fix is correct, but the CTA placement feels a bit bolted-on rather than designed in. I will revisit it properly.
What This Week Actually Was
No new features. No new releases. No version number incremented anywhere. This was an editing week — the kind where you go back through what you have already built and ask whether it is doing the job it was supposed to do.
I think those weeks are underrated in build-in-public writing. It is more exciting to announce a new feature than to write “I changed a stat and fixed an alt text”, but the quieter work often has a more direct impact on whether the sites actually convert. Shipping a calendar reveal and replacing a GitHub stars number will never get a Hacker News thread. It might be the difference between a visitor booking a call or leaving.
If you are a small or mid-sized business thinking about having an app built and you are doing your own version of this audit — looking at developer portfolios and trying to figure out what signals actually matter — I would focus less on stars and followers and more on what shipped. Apps in the store. Repos with recent commits. A developer who writes honestly about what did not work. That is the stuff that is hard to fake.
You can see where I landed on theapparchitect.com/services/.