It was totally unplanned that I got into a hackathon with a 4% acceptance rate.
Built with Opus 4.6 is a week-long virtual hackathon hosted by Anthropic and Cerebral Valley, celebrating Claude Code's first birthday. As far as I know, it was one of the first global-scale virtual hackathons Anthropic has ever run.
I found out about it on social media. My first instinct was to re-post it for the founders who follow me. But while sharing, I clicked into Cerebral Valley's registration, and the process caught my attention. It reminded me of the submission agent I designed for our fund: an agent that works through your background via conversation, asks what you want to build, and how you think about problems. I was testing. Just curious. I filled it out and forgot about it.
Then I got the notification that I was in. I thought this might be a small event that not many people signed up for, so I went to check Anthropic's announcement on X and the post had over 900K views. On Day 1's kickoff, I learned it was 13,000+ applications for 500 spots, each receiving $500 in Claude API credits to build for a week. As a former founder who now runs a venture fund, I'm really glad I got the chance to be a builder again, even just for a week.
Since I already had the credits, I decided to seize the opportunity to build something I actually need. I run a venture fund and one of the things I think about is how my LPs and high-net-worth individuals (HNWIs) manage their personal wealth across different asset classes, so they can make better decisions about where to allocate, including investing in our fund.
At the same time, many of my friends in the Bay Area, especially those in tech with concentrated stock positions, employee equity, and cross-border tax situations, have the same pain point. Managing wealth across stocks, crypto, angel investments, and employee equity while staying on top of tax implications is genuinely hard to do well.
I already knew who the user was, what problem to solve, and what the scope should look like. The next question was: how should this thing be built? Since the hackathon is for Claude Code, I wanted to build something Claude Code native. Not a standalone app with a heavy database and a complex frontend. Instead, a real-time data visualization layer that reads from the user's existing Excel files (because that's how most people already manage their financial data), renders a lightweight dashboard, and lets Claude Code handle everything else through the CLI: portfolio analysis, tax briefings, price tracking, guided data entry.
Building Capiis felt like going through the full product cycle again. Understand your users. Understand their existing behavior. Understand where your tool fits in their workflow. I happen to be the user, so I could move fast.
This devlog documents my chain of thought throughout the six days. For the architecture, technical details, and source code, check out the GitHub repository. For a quick overview, here's the 3-minute demo video.
Build Log
Chain of Thought
Frontend Stack Choice
Options considered: Vanilla JS, Web Components, React/Next.js. Final decision: Vanilla JS for hackathon speed.
No build step means the fastest Claude Code edit-to-refresh loop. When you're racing against a 6-day deadline, the overhead of a framework — even a lightweight one — eats into iteration speed. Vanilla JS kept the feedback loop tight: edit a file, refresh the browser, see the result.
Data Layer Choice
Options considered: external database service vs Excel files. Final decision: Excel files as the primary portfolio data layer.
Spreadsheets are how most people already think about their finances. Using Excel as the data layer respects that existing mental model while keeping everything local-first — no cloud database means sensitive wealth data never leaves the user's machine.
Asset Classification Hierarchy
Options considered: 3-tier hierarchy (market type + subtype + account/tax tags), liquidity-first grouping, tax-treatment-first grouping. Final decision: 3-tier hierarchy.
The key tradeoff was user readability vs multi-dimensional agent analysis. A liquidity-first or tax-first grouping would optimize for one specific agent use case but make the dashboard confusing for humans. The 3-tier hierarchy strikes a balance — users can scan their portfolio naturally while agents can slice across risk, tax, and liquidity dimensions.
Employee Equity Tax Fields
Options considered: basic equity fields vs full tax-aware fields. Final decision: full tax-aware model, implemented in phases.
Basic equity fields would've been faster to ship, but they'd miss the entire point. The value of a wealth dashboard for tech workers is proactive tax guidance — AMT risk alerts, exercise-window timing, disposition planning. Without the full tax-aware model, you're just showing numbers people already know. With it, you're surfacing decisions they didn't realize they needed to make.