What an AI-assisted build actually costs

1. Opening

Product managers don't do project plans. Any commitment made is based on the roadmap and the velocity of the team, not on a Gantt chart a someone dreamt up. My last employer didn't understand that, which is how I came to have time on my hands.

So I used the time to answer a question I actually cared about: how much has AI-assisted product development genuinely changed over the last year? This is not one of those posts where an app materialises over a weekend and the reader is meant to be impressed. It is primarily a cost-modelling exercise: what does a realistic, unsubsidised build actually cost now, run on open-source models I controlled end to end?

The problem space came from my wife. She is half-Asian, a fluent Japanese speaker, and lives in K-beauty, the Korean skincare that has become the cutting edge the rest of the industry is now following. It introduces a new vocabulary of ingredients and a real need to understand what works for your own skin. The information is scientific, and most of the people buying these products aren't comfortable with it. That gap is a nice problem space to explore.

2. The how

This was never a hackathon. It was, in large part, a cost-modelling exercise; the experience gained with the tools, skills, and platforms was also valuable. The aim was to learn what a realistic, unsubsidised cost of AI-assisted development actually is, so that when AI takes more of the strain off human developers, future resourcing decisions get made on real numbers, not vendor demos or social media hype.

That aim dictated the setup. The US labs in particular run on opaque pricing, with heavy speculation about what the final unsubsidised cost will ultimately be: the "blitzscaling" conversation I wanted no part of. So I ran hosted open-source models through OpenRouter, which meant every operation carried a precise, known cost that could be extrapolated into an honest development-cost estimate for a similar method moving forward. Because the environment was mine to define, I controlled the system prompts, the related skills, and the cost, with no hidden layer deciding what the model was or wasn't allowed to do. A hosted demo hides that cost; running my own exposed it.

To the model I added a borrowed system prompt, originally from Codex, that forces the AI to plan carefully and read the specifications of any language, tool, or service it needs before it writes a line of code. It changes the AI from a code-typewriter into something that reads first. Alongside it I used the Claude Superpowers brainstorming and planning skills to handle the planning and specification-writing, named in full because the specific toolchain is part of the evidence.

GLM 5.2 did both the planning and the coding; the model that planned the work is the model that wrote it.

DeepSeek V4-flash was scoped to one job only, running the research agents, chosen purely for cost at volume. That is the routing decision: a cheap model where volume matters, a capable model where judgement does.

And the discipline that matters: more than half the elapsed time was spent planning with the AI before a line of production code, until there was a specification I was confident enough to build from. The proportion is the point. Most of the rework was done in conversation, where it was cheap, rather than in code, where it isn't. That is the single biggest reason a solo build landed at the numbers it did rather than ballooning. That said, I do expect agent architecture improvements, and other change will eat more tokens as they will be made against a already existing repo and planning will be more difficult.

3. The product & architecture

The App is an intelligent companion for navigating K-beauty: skincare whose ingredient lists have outgrown the vocabulary most shoppers are comfortable with. Its value proposition is a single line, and it is also the reason the architecture is the way it is: verified scores versus brand claims. Every other engineering choice follows from refusing to let the model invent.

The App launches into a brief onboarding: Fitzpatrick skin tone, formulation preferences, known conditions, environmental factors, allergies and sensitivities. It stays brief on purpose, because the profile is also built passively; every product you add to your routine feeds it back in, so the app learns what complements and what conflicts as you simply use it. From there you capture a product three ways: scan its barcode with the device camera, photograph the packaging, or type it in. Every product should be reachable regardless of how it's labelled.

What happens next is the part that is hard to fake. The capture dispatches a team of seven research agents, each with a focused brief and a narrow job: ingredients (what's in it, sourced), social-intelligence (what people are actually saying about it), benefit-profile (what the ingredients claim to do, and whether they do), personas (who it's for), pricing (what it really costs across channels), recommendations (what might work better), and match-score (how well it fits your profile). Every agent retrieves live data via Brave Search, attaches a Source object (id, type, title, url, retrievedAt, confidence) to every fact it returns, and emits only JSON that conforms to a strict TypeScript schema. There shouldn't be room for the model to ad-lib an ingredient that isn't there.

Those seven reports are then assembled into one large structured report, and here is the move that matters: the product-intelligence screen is not generated by an LLM per request. It is rendered deterministically from that report. The model does the research; the interface is built from data. So the screen is consistent across every user, it costs nothing to re-render, and it cannot hallucinate a fabricated ingredient list. The agents run concurrently through a resource pool rather than in sequence, and once a product has been researched the result is persisted in SQLite, so a subsequent scan of the same product renders instantly and runs zero agents. The architecture is engineered for the cost-per-scan, not for a demo that works once.

The agents themselves follow Google's Deep Research pattern (plan, loop, evaluate), ported from Python to TypeScript with GLM 5.2. I am not claiming the pattern; I'm claiming I ported it, wired it to live retrieval, and made it emit schema-bound JSON. Routing is split by task: DeepSeek V4-flash runs the research agents because it is cheap at volume, while GLM 5.2 drove the authoring loop. The full stack is Next.js 16, React 19, TypeScript, better-sqlite3, iron-session for auth, @zxing for barcode capture, marked for rendering the agent reports, and Tailwind 4.

End to end, the flow is: launch → brief onboarding → capture a product → seven agents research it in parallel → reports assemble into one structured report → the product-intelligence screen renders deterministically for your profile → you add it to your routine → the routine feeds back into future recommendations. By the time this is published, every scan runs against real products.

4. The receipts

The total development cost was $34.44. That is the all-in figure, planning and execution combined; I could not tease the planning effort out from the rest, so I will not pretend to. A single multi-agent research run costs approx. $0.0065, which is roughly 250 scans for a dollar. The whole build was about five full days of work end to end (40-50 hours).

Not everything worked. An image-generation model was trialled to produce product images matching the UI; even on Nano Banana 2 flash it came to about $0.10 an image, which broke the unit economics, so it was dropped.

This was the point of the exercise. The aim was a cost model for when AI takes more of the strain off human developers, and at $0.0034 a scan and $27.44 all-in for a working multi-agent product, that model now has real numbers in it rather than speculation.