Why Build in Public: Our Portfolio Is a Commit-by-Commit Log

To build in public means shipping your work where anyone can watch it happen: the code, the commits, the plans and the mistakes, not just the finished screenshot. I do it for a practical reason. A development partner’s portfolio is the only evidence a client has before paying, and a commit history is much harder to fake than a case study. So Parkk Technology’s portfolio is a build log: public repositories, the planning notes committed beside the code, and a pipeline that turns meaningful commits into posts on this blog.

What Does It Mean to Build in Public?

For a solo founder on social media it usually means posting progress and revenue. For a software practice it means something stricter: the work itself is inspectable. You can open the repository, read the commit that added a feature, read the plan that preceded it, and run the tests. The claims on the marketing site point at those things instead of standing on their own.

What Is in the Public Build Log?

The parkktech GitHub organization has seven original public repositories with 868 commits between them. Two of them carry most of the history.

FastMagento: benchmarks you can rerun

FastMagento (230 commits) publishes its benchmark method and results in the README: on a 513,000-product catalog the uncached home page renders in 775 ms instead of 2,911 ms, with 80 SQL queries instead of 10,090. It also states its limits, such as category grids still being served from MySQL. A claim with a method and a limit is one you can check. See the case studies page for the short version.

SpendifiAI: the plans are in the repo too

SpendifiAI (218 commits) goes further. Its .planning folder holds the research, plan, summary and verification notes for every phase, committed next to the code they describe. More than a third of its commits are documentation, because the reasoning is part of the build.

Forty-three fix commits is not something most portfolios would show. It is the most useful number in the table: it tells you bugs get found, named and fixed rather than hidden. The v2.0 quality gate, for example, caught an audit-log foreign key problem before release, and the fix is a commit you can read.

What a phase looks like in the log

SpendifiAI’s first release, v1.0 on 11 February 2026, was built in five phases and fifteen plans: scaffolding and API architecture, auth and Plaid bank integration, AI categorization and financial features, events and the React frontend, then testing and deployment. Each phase left the same trail in the history: a research commit, a plan commit, feature and fix commits tagged with the plan number, then a verification commit. The milestone closed with 142 tests, 524 assertions and a GitHub Actions CI pipeline. Reading the log in order, you can watch the product being assembled, decision by decision.

How Commits Become Blog Posts

This blog is fed by the Parkk Blog Engine, itself a public repository. A GitHub Action watches for pushes and decides whether a commit is worth writing about:

1. Push Code lands on the main branch and a GitHub Action picks up the commit message and diff.
2. Filter Dependabot commits, merges, and chore, ci, docs, style, test, build and revert commits are skipped, as is anything tagged [skip-blog].
3. Score Claude rates the commit’s blog-worthiness from 1 to 10. Below 7, nothing is written.
4. Draft Commits that pass become a draft post with headings, an FAQ and structured data.
5. Review Drafts are saved as drafts by default and a notification goes out for a person to review before anything is published.

Why Build in Public as a Development Partner?

It makes the portfolio verifiable

You do not have to trust a claim when you can open the commit behind it. The accountant portal post links to the one commit that added it; the deduction finder post quotes the exact confidence formula from the code.

It improves the decisions

Writing the plan down before building, where anyone can read it, forces the plan to be clear. The SpendifiAI plans went through a checker step and several were revised before any code was written; those revisions are commits too.

It compounds

Each shipped project leaves behind code, tests and a written record that the next one can reuse. FastMagento’s checkout and personalization extensions build directly on the core extension’s history.

What Stays Private, and Why

Building in public has limits. Client stores belong to clients. The counter-UAS hardware I engineered is defense work, and its source stays private. Private products like EdgeTrades are described without numbers. What goes public is my own products and tooling, and the rule for the rest is simple: no claim about private work that goes beyond what I can explain to you directly.

How to Evaluate a Developer’s Public Work

• Open the commit history. Is it steady work, or one giant upload before a sales push?
• Read a few fix commits. Are problems explained, or just patched?
• Look for tests and whether they run.
• Check whether the README states limits as well as results.
• Ask the developer to walk you through a commit you picked, not one they picked.

Frequently Asked Questions

How can I tell if a developer's GitHub portfolio is real?

Look at the history, not just the code: steady commits over weeks, fix commits with explanations, tests that run, and a README that admits limits. Then ask the developer to explain a commit you choose.