Free. Practical. Tested.

Most CPA firms run Windows, most firm laptops are locked down, and most tutorials assume you are on a Mac with admin rights. This is the version that works on the machine you actually have.

What you need first

• Windows 10 or 11 with WSL2 available. Claude Code runs in a Linux environment; WSL2 is how Windows provides one.
• Local admin rights for the WSL install, or an IT ticket. This is the only step that needs elevation.
• A Claude account with API access or a Claude Pro/Max subscription.

Install WSL2

Open PowerShell as administrator and run one command. It installs WSL2 and Ubuntu together.

 wsl --install 

Reboot when prompted. On first launch Ubuntu asks for a username and password — these are local to the Linux environment and have nothing to do with your Windows or network credentials. Pick something you will remember; you need the password for every install command after this.

Install Node and Claude Code

Inside the Ubuntu terminal, install Node through nvm rather than apt. Firm laptops get reimaged and apt-installed Node ages badly; nvm keeps the version under your control.

 curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.1/install.sh | bash
source ~/.bashrc
nvm install --lts
npm install -g @anthropic-ai/claude-code 

Then authenticate. Claude Code opens a browser window against your Windows default browser, which works fine from WSL.

 claude 

The IT conversation

If your firm requires approval, the questions you will be asked are predictable. Answers that have worked:

• Where does client data go? Only what you paste or point it at. Work in a scratch directory with de-identified data until you have a policy.
• Is it a browser extension or an agent on the endpoint? Neither — it is a command-line tool inside WSL, sandboxed from the Windows filesystem unless you cross the boundary deliberately.
• Can it change files without asking? It asks before writing by default. Do not turn that off while you are learning.

Verify it works

Make a scratch directory, drop in a CSV, and ask for something small. If it reads the file and answers, you are set up.

 mkdir ~/scratch && cd ~/scratch
claude 

Next: build something real in article B2.

The best first project is one where you already know the right answer, because you will be checking the output by hand. Reconciling a bank export against a general ledger export qualifies: tedious, well-defined, and you can eyeball whether it worked.

Set up the problem

Put two de-identified CSVs in a scratch directory — a bank export and a GL export for the same period. Then start Claude Code in that directory and describe the job in business terms, not technical ones.

 I have two CSVs in this folder. bank.csv is a bank export;
gl.csv is a general ledger export for the same month.
Write a Python script that matches transactions between them on
amount and date (within 3 days), and outputs three files:
  matched.csv    - pairs that reconcile
  bank-only.csv  - on the bank, not in the GL
  gl-only.csv    - in the GL, not on the bank
Read the actual headers from both files first. Do not assume
column names. 

That last line matters more than it looks. Left to itself the model will guess at column names and write something that fails on your real data. Telling it to read the files first is the difference between a demo and a tool.

Iterate on real failures

The first run will be wrong in an interesting way. That is the point. Common corrections, in the order they usually come up:

1. Sign conventions. The bank shows a debit as positive, the GL as negative. Say so.
2. Duplicate amounts. Two $500 checks in the same week match each other wrongly. Ask for one-to-one matching, not greedy first-match.
3. Dates as text. Excel exports dates in a dozen formats. Ask it to parse defensively and report anything it cannot read rather than dropping the row.

Make it reusable

Once it works, ask for the part that makes it a tool rather than a one-off.

 Add a summary printed at the end: total rows read from each file,
number matched, total dollars matched, and total dollars unmatched
on each side. Make the file paths command-line arguments so I can
run this on any client. 

You now have something you can run next month without rebuilding it. That is the whole loop: describe the real job, correct the real failures, then generalize.

Publications are long, badly indexed, and cross-reference each other constantly. That is exactly the shape of problem a model is good at. It is also the shape of problem where a confident wrong answer costs you a client.

The rule

Use the model to find the passage. Read the passage yourself. Never cite what you have not opened.

A prompt that behaves

Download the publication as a PDF into your working directory, then ask against the file rather than against memory.

 I have attached Publication 946. Answer only from this document.
Question: what is the recovery period for qualified improvement
property placed in service in 2024?
For your answer, give me:
  1. The direct quote that answers it
  2. The page and section it appears on
  3. Anything in the document that qualifies or limits that answer
If the document does not answer the question, say so and stop. 

The last line is doing real work. Without it, a model asked a question it cannot answer from the source will answer from training data instead, and you will not be able to tell which happened.

What this is good for

• Locating the controlling paragraph in a 120-page publication.
• Listing every place a term appears so you can check for a definition you missed.
• Explaining a passage you have already read but cannot parse.

What it is not good for

• Anything you will sign.
• Positions where the answer depends on facts the document does not contain.
• Current-year changes. Publications lag, and so does the model.

I have built a dozen tools for my own firm and I would not build any of these four. The skill worth having is not “can I build it” — it is knowing when the answer should be no.

1. When you are the only one who understands it

A tool that only you can fix is a liability with a nice UI. If you get hit by a bus mid-March, someone has to run the firm. Anything that touches a deadline needs either a second person who understands it or a documented manual fallback. Write the fallback before you write the tool.

2. When the rules change faster than you can maintain it

Payroll tax tables, state nexus thresholds, per-diem rates. These change on someone else’s schedule, and a tool that is silently a year stale is worse than no tool, because you will trust it. Buy the thing whose vendor is contractually obligated to update it.

3. When it is the system of record

There is a real difference between a tool that reads your data and a tool that owns it. Readers are low-risk: worst case, you throw it away. Systems of record need backup, restore, migration, and an answer to “what happens when this breaks in the middle of tax season.” That is not a weekend project, and treating it as one is how firms lose data.

4. When someone already sells it for less than your time

Your billable rate is real. A tool that takes you thirty hours to build and maintain costs your firm thirty hours. If a vendor sells it for $600 a year and it fits, buy it. Build when the thing does not exist, or when every version that exists is wrong for how you actually work. That is a narrower category than it feels like at 11pm.

The good news is that the remaining category is still large. Nobody sells a converter for your specific bank’s statement format. Nobody sells the checklist your firm has evolved over twenty years. That is where this pays.

The gap between “it worked on my laptop” and “the firm uses it” is where most self-built tools die. This is the discipline that closes it, using workpaper prep as the example.

Start with the manual procedure, written down

Before you prompt anything, write the procedure the way you would hand it to a first-year. If you cannot write it, you cannot automate it — and the writing itself usually reveals that two people on your team do it differently.

 Workpaper prep, current-year:
  1. Export TB from the tax software as CSV
  2. Pull prior-year workpaper
  3. Match accounts by number; flag new and dropped accounts
  4. Compute variance dollars and percent
  5. Flag any account moving more than $5,000 AND 10%
  6. Carry forward prior-year tickmarks on unchanged accounts 

Build it against a real prior year

Use a closed engagement where you already have the finished workpaper. You are not asking whether the tool produces output — you are asking whether it produces the output you already know is right.

 Read tb-current.csv and wp-prior.csv. Follow the procedure in
PROCEDURE.md exactly, step by step. Produce workpaper.xlsx.
For every account, show your work: the prior balance, the current
balance, the variance, and which flag rules fired. I am going to
diff your output against the workpaper we actually filed. 

Write the CLAUDE.md before you write more features

A CLAUDE.md in the project root is persistent instruction. It is the single highest-leverage file in a firm project, because it stops you re-explaining your domain every session.

 # Workpaper generator
## Domain rules
- Account numbers are 5 digits. Leading zeros are significant.
- Negative means credit balance. Never take absolute values.
- Materiality is $5,000 AND 10%, not OR. Both must be true.
- Prior-year tickmarks carry forward ONLY if the balance is unchanged
  to the penny.
## Do not
- Do not round anything before the final presentation layer.
- Do not drop rows. Unparseable rows go to an exceptions sheet. 

Put it under version control

This is the step firms skip and the step that makes it real. Git gives you three things you need: a record of what changed, the ability to go back when a change breaks something mid-season, and a way for a second person to review before the change ships.

 git init
git add .
git commit -m "Workpaper generator: matches filed FY24 output" 

From here every change is a branch and a diff. When you or the model changes the materiality rule, the diff shows exactly that, and someone else can read it in thirty seconds. That review step is what makes the tool something the firm relies on rather than something you personally operate.

The exceptions sheet is the deliverable

The workpaper is not the valuable output. The list of things the tool could not handle is. Design for it: every row it could not parse, every account it could not match, every flag rule that fired ambiguously goes on one sheet a human reads first. A tool that processes 94% and tells you precisely which 6% needs you is worth more than one that silently processes 100%.

Vibe Trial Balance is source-available and free for internal firm use. It runs on your hardware, which means your client data never leaves the building. This is the standalone install; if you want the whole suite, see article B8.

What you need

• A machine running Ubuntu 24.04 LTS. A refurbished mini PC with 16GB of RAM is plenty for a small firm.
• Docker and Docker Compose.
• A backup destination. Do not skip this.

What it does

It maps a chart of accounts to tax return lines, with 1,061 pre-built mappings covering UltraTax, Lacerte, GoSystem, and CCH Axcess across 1040, 1065, and 1120S entity types. The mappings live in Postgres, which means you can edit them — that is the point of running it yourself.

Install

Clone the repo, copy the environment template, and bring it up.

 git clone https://github.com/KisaesDevLab/Vibe-Trial-Balance.git
cd Vibe-Trial-Balance
cp .env.example .env
# edit .env — set the database password and secret key
docker compose up -d 

First run

The container runs its migrations on first boot and seeds the mapping tables. Give it a minute, then open the app and create the first admin account — the first account created becomes the administrator, so do this before exposing the machine to the network.

Access from outside the office

Do not port-forward. The supported pattern is Tailscale: install it on the server and on each staff laptop, and the app becomes reachable on the private mesh without opening anything to the public internet.

 curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up 

Back it up

The database holds your mappings and your engagements. Dump it nightly and send the dump somewhere off the machine.

 docker compose exec -T postgres pg_dump -U vibe vibetb | gzip > backup-$(date +%F).sql.gz 

Test the restore before you need it. An untested backup is a guess.

A skill is a folder of instructions and reference material that loads when it is relevant. For tax research this matters because the failure mode you are trying to prevent is the model answering from memory when it should be answering from a source.

The structure

A skill is a directory with a markdown file describing when to use it and how to behave, plus whatever reference material it needs.

 tax-research/
  SKILL.md          # when to trigger, how to answer
  sources/
    pub-946.pdf
    pub-535.pdf
  crosswalk.csv     # section -> plain-language topic 

Writing SKILL.md

The instructions that matter are the ones constraining behavior, not the ones describing capability. Most of the file should be about what not to do.

 # Tax research
Use when the user asks a question about federal tax treatment,
deductibility, recovery periods, or filing requirements.
## How to answer
1. Search the documents in sources/ first. Always.
2. Quote the controlling passage directly. Do not paraphrase it.
3. Cite the document, section, and page.
4. State the effective year of the source you used.
## Never
- Never answer from memory. If sources/ does not cover it, say so.
- Never produce a section number you have not seen in a source.
- Never give a conclusion without the quote it rests on.
- Never omit a limitation or exception that appears near the passage.
## Always end with
"Verify against current-year guidance before relying on this." 

Curating sources

The quality of the skill is the quality of the folder. A small, current, well-chosen set of publications beats a large stale one. Date every file, and put the effective year in the filename so the model can see it.

• Keep one directory per tax year. Do not mix years in one folder.
• Prefer the publication over the instructions, and the Code over both, when the question is close.
• Remove superseded documents rather than leaving them alongside the current version.

Testing it

Test with questions you already know the answer to, including questions the sources do not cover. The second kind matters more — you are testing whether it declines correctly.

1. Ask something the sources answer clearly. Check the quote is real and the citation is right.
2. Ask something the sources do not cover. It should say so and stop.
3. Ask something the sources answer with an exception attached. It should surface the exception unprompted.

If it fails the second test, tighten the Never section and try again. That is the whole development loop.

The Appliance is a meta-installer. Rather than deploying each app separately, it composes them onto one Ubuntu host with a shared Postgres and Redis, Caddy in front for TLS, and the operational tooling to keep the thing alive.

Hardware

A small-firm install is comfortable on a refurbished mini PC: 16GB of RAM, a 500GB SSD, wired ethernet. Buy two if you want a spare you can restore onto — that is cheaper than a support contract and faster than a rebuild.

Install

 curl -fsSL https://raw.githubusercontent.com/KisaesDevLab/Vibe-Appliance/main/bootstrap.sh | sudo bash 

The script installs git, clones the repo to /opt/vibe/appliance, and re-executes from there. It then asks how you want the box reachable — a domain with public TLS, LAN-only, or Tailscale.

What comes up

The core stack is shared infrastructure, not per-app copies. One Postgres cluster, one Redis, one Caddy. Apps are Compose overlays layered on top, enabled one at a time.

• Postgres 16 and Redis — shared by every app that needs them.
• Caddy — reverse proxy and automatic certificates.
• Tailscale or Cloudflare Tunnel — how you reach it from outside.
• Portainer, Cockpit, Duplicati — containers, server admin, whole-tree backups.

Enabling apps

Each app in the catalog is a manifest in apps/. Enabling one brings up its services and adds its route to Caddy. Start with one, confirm it is healthy, then add the next — a failed enable is much easier to diagnose alone.

Adding other open-source tools

This is the part worth understanding. Because every app is a Compose overlay against the same core, any other self-hosted tool that speaks Docker Compose drops into the same pattern: put it on the vibe_net network, point it at the shared Postgres, and let Caddy route it. Document management, a password manager, a file server — all the same mechanism.

Backups

Duplicati backs up the whole tree on a schedule. Pair it with an off-site copy and a restore you have actually tested.

Run the drill. A backup you have never restored is a hypothesis.