Meaning
“Remaining” could mean budget, prepaid balance, or a session allowance. I explored stable positions for provider cost, the builder’s limit, and provider-specific information.
Before BuildMeter, I used AI to accelerate research synthesis, exploration, and prototyping within a familiar design process. Building this app took that further: agents became part of planning, implementation, critique, and verification. The product’s needs helped shape the workflow as I went.
Executive Summary
- Designed and built a native macOS menu bar app that brings seven AI providers into one cost view, owning product decisions, design, implementation, testing, and release.
- Reached TestFlight in 48 days by building and testing small increments, progressing from an empty popover to a working app and release pipeline.
- Made provider differences part of the design: costs, balances, quotas, reporting delays, and monitoring limits needed distinct meanings rather than a uniform-looking total.
- Used BuildMeter to evolve an agentic workflow across planning, implementation, critique, and verification, with shared context and documented decisions supporting the work.
- Separated code verification from visual review and made design validation a gate before implementation, keeping human judgment central to product decisions.
- Delivered a working beta while identifying the next validation step: learn from beta use and test the proposed provider-card pattern. Customer impact remains to be established.
01 / The product problem
The data existed.
The view didn’t.
My own AI product work and agent experiments spread usage across multiple providers, each billing independently. Checking cost meant logging into a dashboard, re-authenticating, finding a number, and repeating the process elsewhere. Spend could accumulate faster than I checked it.
I wanted a glanceable macOS menu bar app: seven providers, one cost view. I owned the product decisions, design, implementation, testing, and release process, working with AI throughout.
The complexity was there before I knew to ask.
Providers measured usage in tokens, characters, credits, and prepaid dollars. Authentication, spend-limit access, and reporting latency varied. At the start, I did not understand that landscape—and the AI research had not exposed the depth of it either.
I asked surface-level questions and got rich-looking, surface-level answers. Even what I thought was deep research was not deep enough. The project became a sequence of correcting those misses. Context and concrete checks mattered more than the apparent completeness of an answer.
02 / Building to beta
One small increment at a time.
I researched macOS practices, existing products, access to provider cost data, and a Swift code-to-design-to-code workflow. The search surfaced an old Figma-to-Swift plugin, but no workable loop for this project. I deliberately began with design in code—an approach I had not used before.
With agent support newly available in the Xcode beta, I built one small chunk at a time: an icon, an empty popover, then one layer of functionality. I tested each layer as it appeared.
At first, I was the routing layer.
A dedicated Claude.ai project supported planning. An agent inside Xcode implemented scoped chunks. Notion held the requirements, architecture, and session log. I carried prompts into the editor, reviewed the running app, and brought observations back into planning.
From those increments to a running product.
BuildMeter brought Anthropic, OpenAI, OpenRouter, xAI, ElevenLabs, Deepgram, and Tavily into a dollar-based view. The project reached a TestFlight beta with a working macOS app and release pipeline.
Product evidence / Running app
One cost view, with room for provider differences.
The overview brought spend together; the detail screens retained the context needed to interpret it. These running-app screens show why a single dollar total was only the starting point.
03 / An agentic workflow
Building the app also meant
building the way I worked.
BuildMeter exposed the limits of carrying every prompt, handoff, and check myself. Its development became a practical setting for evolving an agentic workflow: how to give agents useful context, divide the work, and verify their results before making the next product decision.
As the work grew, I separated code verification from visual verification. CLI agents could inspect source and dependencies. Figma and Pencil could reproduce the running interface for visual critique. Notion became a live shared reference for briefs, skills, handoffs, and decisions.
When an agent said an issue was fixed but I could still see it, an independent source review helped resolve the disagreement. I arbitrated between code evidence and the visible experience. The design loop used a visual representation of the app; it was not a lossless conversion of Swift source into editable design and back.
Put a real decision before implementation.
For the next provider-card iteration, an AI collaborator proposed building a SwiftUI scaffold while exploring three visual variations in parallel. I pushed back. If the cards turned out too bulky or complex, that implementation would be wasted.
I made design validation a gate before code, and required one variation that challenged the preferred direction. The agent’s own critique later found that skeptical alternative competitive on glanceability. More output was not the goal; a better-supported decision was.
The API became a design constraint.
A command-line test tool made provider differences concrete. The next interface needed to make those differences understandable rather than hide them behind uniform-looking cards.
Availability
Some data was intraday; some was delayed or excluded today. Missing could not become zero. Accumulating, subject-to-adjustment, and unavailable values needed distinct treatment.
Authority
The Anthropic and OpenAI APIs I worked with did not expose console-set spend limits. A BuildMeter limit could provide a monitoring signal, without implying control over provider billing.
Design evidence / Proposed iteration
Make the differences understandable.
Make the states part of the design.
The exploration tests both configured and unconfigured limits. It also makes room for rate limiting, retries, server errors, and balance information without changing where the main cost and limit information live. Those states mattered because a compact card still needed to explain what the app knew—and when the data could not be trusted or was not available.
A shipped beta, and an unvalidated next step.
The proposed three-layer provider-card pattern was still a hypothesis. Reaching TestFlight established that I could build and release the product; it did not establish that the next design solved the problem for other people. Beta learning and validation needed to shape what came next.
04 / What BuildMeter changed
A product built.
A practice still evolving.
BuildMeter was part of a wider year of experimentation, and a concrete place to put that learning to work. Each shift answered a limitation in the previous setup. AI began alongside the work, became an agent inside the editor, then separated into strategy and execution. Context discipline, parallel agents, and codified working patterns followed. Design validation and direct source inspection shortened the distance between a claim and something I could verify.
The app and the workflow developed together. Product problems exposed gaps in the process; better context, critique, and verification helped me return to those problems with stronger evidence.
Five shifts in how I worked
The five stages below trace that progression, from using AI within an existing process to coordinating agents and checking their work. Each change responded to a limitation I encountered. BuildMeter gave me a concrete product against which to test those changes, and the experience gradually shaped my views on how I would build with AI and help a team work with it.
- AI alongside the workAcceleration within an existing process.
- An agent in the editorImplementation became part of the conversation.
- Separate strategy and executionShared context and handoffs became deliberate work.
- Orchestrate multiple agentsCodified patterns and a design gate gave parallel work a structure.
- Shorten the verification loopVisual replicas, direct source access, and better briefs made claims easier to check.
- Delivered
- A seven-provider macOS app and a working TestFlight release pipeline.
- Learned
- Small increments, explicit design decisions, and separate code and visual checks made the work easier to verify.
- Next
- Learn from beta use and validate the proposed provider-card pattern.
How this shaped my thinking about AI
Building BuildMeter made me more opinionated about working with AI because I had to live with the consequences of the decisions. I saw where agents helped me move faster, where incomplete context produced convincing but shallow answers, and where a claimed fix still needed to be checked in the running product. That is what “always human in the loop” means to me: I remain responsible for framing the problem, deciding what good looks like, challenging the proposed direction, and judging whether the evidence supports moving forward.
That experience also changed how I think about leadership. I expect leaders to manage token use alongside headcount as model work becomes part of how teams deliver. Decisions about which work to delegate, which models to use, and how much iteration and verification a task deserves will affect both cost and quality. BuildMeter made that cost visible in my own practice; the broader question is how teams will make those choices deliberately.
My starting position for helping a team through this transition is to make AI fluency part of the work itself. I would pair with designers, work through real problems together, and make the reasoning behind decisions visible. Shared expectations for briefs, deliverables, and verification would give people a foundation they could practice and improve together.
I am still working out how much of that practice should be standardized. People have different appetites, learn at different speeds, and find different tools useful. A larger team also needs enough consistency to collaborate and trust the work it produces. BuildMeter gave me practical experience to draw on and a clearer position to test. How I would balance that consistency with room for individual approaches is a question I would continue to work through with the team.