This week I sat down with Brian Weisberg, a finance leader who has built and run finance teams at high-growth, venture-backed companies through several exits. He told me about a procurement tool his team built in-house instead of buying, and how the tool died: water was spilled on the laptop running the tool.
Brian's read on 2026 is that a lot of us have gotten good at building, but have not gotten good at enabling our work to run without us (or our laptop).
This week's PTO Handoff Skill writes a PTO handoff packet for you - useful for your end-of-summer vacations.
Run the Skill and it reads your open tasks, your in-flight threads, your calendar, and your meeting notes, then sorts what it finds into three buckets. Live items need a human while you are out, so each one gets an owner. Parked items will wait, so each one gets a resume date instead. And lastly, landmine items: tasks that that aren’t due today, but have catastrophic consequences if not handled while you’re away.
The packet produced is written for whoever is covering you, provide a task’s state, next action, decision authority, and a link for every item instead of exporting your to-do list.
Drop it into your Claude Skills directory and run /pto-handoff.
Answer the first-run survey about which systems your work actually lives in. The Skill hands you back a configured copy of itself, and saving that copy replaces the original. Setup happens once, calmly, rather than the night before a flight.
Before your next trip, run the Skill again and give it your dates, who is covering, and how reachable you plan to be.
Review the coverage packet and your own pre-departure checklist, then approve the batch. On approval the Skill posts the packet, DMs each coverer their slice, reassigns tasks and moves due dates, declines or delegates meetings, and sets your OOO.
What does Brian Weisberg, former VP of Business Operations and Strategic Finance at Mux, think about the ratio of time accountants should spend building versus maintaining their AI tools?
"You can't just build a tool. Building something is a third of the work, and then the other two thirds are maintenance of that tool."
His team at his last company replaced a purchased procurement tool with a version they built themselves. Brian still thinks the call was correct, and he called procurement "a ripe case for build versus buy." Then water hit the laptop the tool ran on. Sticking the laptop in a bag of rice sadly couldn’t save it, meaning the locally-run procurement tool was lost.
Accounting has a control for that shape already: key person dependency. One person builds a tool, one person runs the tool, and one person understands the tool. Accountants mitigate key person dependencies already, and now’s the time to apply the practice to your builds. Brian's standard for when a build is actually finished is blunt:
"Everything should always be able to continue if you aren't there. And if it doesn't, you're doing it wrong."
2026 is a hot moment for finance engineering with everybody building their own close workbooks, their own flux analyses, and their own reconciliation automations. Then the person who built the tool moved onto a different company, leaving the workflow broken at their previous company.
This is where accountants can borrow notes from software developers and engineers. You must build your tools with the foresight for maintenance and sharing your work. Otherwise, you’ve created a flash in a pan with your tool rather than a sustained flame.
With maintenance in mind, the useful question is not whether to keep building. Keep building. The question is what you can do while building so the tool survives during the week you are out or say, tragedy strikes and the laptop that gets water on it. Brian gave four best practices:
Break the build into discrete pieces: as one monolithic build, a tool is unmaintainable by anyone else, because whoever inherits the tool has to understand all of it before they can fix any bugs. Built as separate Skills that each do part of a job, the same workflow can be repaired one piece at a time by someone who didn’t craft it.
Work in projects, not in one long chat: a fresh chat for every session within the same scope is inefficient. When assigning workflows to projects, the context of your build ends up in a project that a colleague can easily access. Projects are app-native sections you can assign certain chats to that retain context from previous chats and any files you store in the project.
Store your Claude Skills outside a project: a project holds the context for one build. Skills you build need to live somewhere more general: file hosting on sites like Google Drive or Github.
Document as you go with release notes: write a README file, Google Doc, or a Notion page to document what you're building, and how you're progressing.
So build your tools in pieces, put the context for them where a colleague can open it, keep the Skills outside any one project, and write down what you made and what changed. Then run Brian's test on it: if you were unexpectedly out next week, could the tool run without you?
READER SURVEY
Ten issues in, I want to know what has been useful to you! The survey runs about two minutes, and it'll help me decide what I cover next: which Skills and topics land in your inbox.
My takeaway: Watching this video made me consider how much AI has changed and improved in two years. The video's whole method is using a carefully-crafted prompt that produces VBA, then pasting it into Excel’s developer tab. Both halves of that method have been replaced. Claude works inside Excel now, so the copy-paste round trip is gone. This made me think about the art of the prompt: is it dying because our models are getting smarter? I don’t think it has died so much as it has been repackaged: robust prompt engineering shifted from one-off prompts to building Skills, which now require the tailored instructions to automate a task well.
My takeaway: The part I found interesting is his observation that students treating AI as a shortcut are falling behind in their critical thinking, while students treating AI as a sparring partner are getting sharper. I have a personal stake in the question, because I am adjuncting this fall at my alma mater, the University at Buffalo, teaching technical accounting research.
Here’s my approach: Give the student a fastball - a fact pattern with everything they need, asking for the classification of a lease. That question maps to the guidance almost as a checkbox, and I should assume every AI on Earth can answer the question. The real test is the curveball: the asset is in the back half of its useful life. Does that matter? A student who used AI to understand the guidance can reason toward an answer. A student who used AI to produce answers freezes. And the student who says "I am not sure, but here is which way I would lean and why" is showing me the thing Joel says is most durable and hardest to teach: professional judgment.
My takeaway: Bobby set out to automate monthly reviews, 13-week cash forecasts, and comp ratio analysis, and the first thing the AI forced him to do was write down what "good" looked like for each deliverable. In his words, the real value is that "teaching the AI forces you to write down the work you've been doing in your head, which is the part most of us outsource to memory and prayer." You cannot hand off a standard you have never stated, to a colleague or to an agent. It also raises the bar Bobby names at the end, which is being able to defend the work. Once the definition of good is on paper, you can defend the output, point at the pattern it came from, and tell whether the work is accurate based off of that pattern.
💭 If this newsletter hit for you, forward it to one finance engineer in your network.
Happy building, and I’ll see you next week!
– Alec
Numeric, 548 Market St #81114, San Francisco, California 94104, United States
-1.png?upscale=true&width=1120&upscale=true&name=PRODUCT%20UPDATE%20EMAIL%20HEADERS%20(5)-1.png)
