Capital Compass: showing small business owners what money actually costs

Three things happened here, and only one was code

We each designed our own version of the product, independently, and then put them side by side. Mine was the one the group decided to build. That was the first thing.

The second was harder and mattered more. A design winning a comparison is not the same as a team believing in it. What I had to do next was earn genuine buy in on the problem and the vision: why this particular user, why these three questions, why in that order. Once people are bought into the problem, most design arguments answer themselves. Once they are not, every decision becomes a negotiation. We refined the solution together from there, and it got better for it.

The third was that I presented it. Standing up and making a room of judges care about a coffee shop owner in Long Beach is a different skill from building the thing, and it is the one that decides whether any of the work gets seen.

Winning the design and then holding it too tightly would have been the fastest way to lose the team. Winning the design and then not being able to sell it would have been the fastest way to waste it.

The person this is for

Kennedy owns Coffee Drunk in Belmont Shore, Long Beach. She needs a roaster. She does not know what a roaster costs installed, what kinds of financing exist, which ones she would qualify for, or what any of them would do to her monthly bottom line.

She is not going to read a comparison chart of SBA loan products. She is going to ask someone she trusts and take their word for it, and that is precisely how small business owners end up in financing that quietly costs them their margin.

That framing was the thing I needed the team to agree on before a line of code got written. Not “a financing marketplace.” One specific person, three questions, in the order she actually asks them: What does this really cost? What are my options? What does each one do to my month?

My first project with Claude Code

This was the first software I have built using Claude Code, and I want to be straightforward about what that means, because I think the interesting part is not the tool.

It let me hold the whole system in my head at the level I am actually good at, which is deciding what the software should do and why, while moving far faster on the part I am slower at, which is typing correct Angular. The 3,800 lines are real, they work, and the architecture is deliberate: a domain core that knows about money, and a presentation layer that knows nothing about it.

What I learned is that the leverage moved. The hard questions stopped being “how do I implement this” and became “what does a project cost actually consist of” and “which single number will a lender use to say no.” Those are strategy questions, and they were still mine to answer. Getting them wrong would have produced working software that gave people bad advice.

What the app does

The cost estimator sizes the equipment to the business and prices the whole project, not the sticker price of the machine but installation, electrical, ventilation, permits, and contingency. This is where most owners get hurt. They finance the roaster and forget the rest of it.

The finance engine does the real work: amortization schedules, implied APR, IRR, debt service coverage ratio, and borrowing headroom. Not a monthly payment calculator. The actual metrics a lender will run on her, so she sees herself the way they will see her.

The health check runs a stress test and returns a binding constraint verdict, naming the one thing actually limiting her options in plain language rather than handing her a wall of ratios to interpret.

The document agent is the piece I like most. Connect your accounts and it retrieves what a lender will ask for, against a permission scope you control. Leave QuickBooks disconnected and it does not fail. It drafts a request to your bookkeeper, because a bookkeeper is who actually holds those reports. It models how the task really gets done, not how software wishes it got done.

Every figure recalculates against her actual $30,000 monthly revenue. The stack panel on the right shows two grants combined, $22,500 of $46,500, still $24,000 short, and compares the blended effective rate against financing the whole project with one lender.

The design decision that mattered most

This app talks to people about money they may not be able to repay. Getting the tone wrong is not a UX problem. It is a harm.

So three rules were non negotiable, and they are enforced everywhere in the codebase:

1. It never says “you qualify.” Every match is phrased “you likely qualify because” followed by the specific reason. The app is not a lender and does not pretend to be an oracle.
2. Every claim carries its source. Each funding product has a source, a source URL, and a last verified date. The data is currently a constant, shaped exactly like what a live retrieval layer would return, so swapping it for a real service is a one line change.
3. Every claim can be flagged as wrong. There is a control on each one. If the tool is confidently incorrect about someone’s business, the fastest path to fixing it should be in the user’s hands.

The footer says the figures are illustrative. It should. Building trust into a financial tool means being loud about the limits of what you know.

The demo detail

Untick a single cost line on the last intake step, say the ventilation work, and the total, the contingency, and every downstream financing option recompute live. Untick something marked required by regulation and it warns you rather than silently letting you plan around a permit you legally need.

That interaction is the whole thesis in one gesture. This is not a form that produces a number. It is a model of her actual project, and she can push on it.

What it taught me

Domain modeling is where the leverage is. Most of the difficulty was never the framework. It was working out what a project cost genuinely consists of, and which metric decides the answer. Get the model of the world right and the interface mostly designs itself.

Winning the design was the easy half. The work that actually mattered was aligning people on the problem before defending any particular answer to it, and then being able to stand up and make strangers care about it. I have done both at much larger scale, over months instead of hours. The compressed version is not different in kind. It is just less forgiving of skipping steps.