Easy but hard: qualifying as a BASH partner
A demonstration-based path to partnering with BASH — open to anyone, hard to finish
Qualify as a BASH consultant by building, not claiming — an open path that starts with a fork and ends with a business tool shipped in public
Table of Contents
BASH consultants are expected to be among the most advanced IT professionals in any room they walk into. There is no way to prove that on a résumé, and we do not try. We qualify partners the way the whole practice works — by building something real, in the open, and showing the work. This is that qualification. It is easy to start and hard to finish, and the difficulty is the entire signal.
We reject the usual gates: paywalls, credential checks, and the closed interview that rewards people who interview well over people who build well. Anyone curious and capable enough can begin today. What separates a BASH partner from an applicant is not permission — it is demonstrated ability.
Easy but hard
The name is the promise.
Easy. The door is open. You fork a public repository and start — no application fee, no gatekeeper deciding whether you are allowed to try, no proprietary tooling to buy first. The path runs on the same open, inspectable foundations our clients’ systems are built on.
Hard. The bar is the best work, not the minimum. Passing means shipping a genuinely useful digital business tool, built on GitHub with artificial intelligence (AI) as a collaborator, and showcased in public so anyone can inspect, run, and fork it. Most people can start. Finishing to that standard is the filter, and it is meant to be.
What you’ll demonstrate
The qualification is a sequence, and it begins where collaboration always begins on open work: with a fork.
1. Collaboration and forking. Fork one of our open repositories — this site, the toolkit, or the it-journey learning platform — and contribute through the normal GitHub flow: a branch, a focused change, a clean pull request, and a conversation in the open. Forking is deliberately the first step, because it is how real collaboration starts and because it shows immediately whether you can work inside someone else’s codebase without breaking it. This stage is easy on purpose. It is the handshake, not the test.
2. Build a digital business tool. Pick a real problem a small business actually has — [[The small-business IT foundation]] and the rest of the business track are full of them — and build a working tool that solves it: on GitHub, deployable to GitHub Pages or a small serverless function, AI-assisted with your own judgment in the loop. Not a tutorial clone, not a toy. Something an owner could put to use on Monday.
3. Showcase it in public. Publish it documented and inspectable, the way a real portfolio does. Build in the open; learn in the open. A tool nobody can see, run, or fork is a claim, not a demonstration. The reference standard for what “showcased” means is below.
4. Show the doctrine. The tool has to reflect how BASH builds: deterministic, auditable foundations under an AI overlay, documented so a non-author could own it, and portable so no one is locked in. Read [[The deterministic-first doctrine]] and [[Running an AI-native consulting practice]] before you start — they are the standard your build will be read against — and [[The BASH engagement method]] is the discipline that shapes it.
What “best” means here
“The best BASH consultants build the best digital business tools” is not a platitude; it is the rubric. A qualifying build is judged on five things.
- Usefulness. Does it solve a real small-business problem well enough that someone would actually adopt it? Toys do not qualify.
- Deterministic foundations. Is the load-bearing logic scripted, versioned, and reproducible, with AI confined to where judgment genuinely helps and always behind a check?
- AI as a collaborator, not a crutch. Did AI accelerate the work while you kept judgment, review, and correctness? Confidently wrong output that shipped unchecked is a failing grade, not a shortcut.
- Ownership and portability. Could a business inherit this — inspect it, run it, and move it — without you? Open, documented, and standards-based.
- Taste. Clarity over cleverness. The simplest thing that does the job, built to be maintained by someone who is not you.
The reference bar
When we say “showcase it, like this,” we mean a working portfolio of real tools shipped in the open. bamr87.github.io is a GitHub Pages portfolio that does exactly that — a filterable gallery of projects built and deployed with Jekyll, Bootstrap, GitHub Actions, and AI-assisted workflows, from the it-journey learning platform, to the zer0-mistakes theme this very site runs on, to full-stack apps demonstrating AI content pipelines. That is the level: not one polished demo, but the demonstrated habit of building useful things in public and shipping them.
You do not need to match its breadth to qualify. You need to show, convincingly, that you can build to that standard — and that you would keep doing it.
How to start
Start today, in this order.
- Fork a repository — bashconsultants, the toolkit, or it-journey — and open a first pull request.
- Build your digital business tool and deploy it publicly on GitHub Pages or a serverless stack.
- Showcase it: a public repository and a live link, documented so a stranger could run it.
- When it is real, tell us what you built and point us at the repository and the running tool.
The door is open and the bar is high. That is the job.