Apollo
Web app · Live demoPaste a messy reorder list and get back a priced, stock-checked order.
How I built it
Three of us built Apollo over four weeks. We rotated between three tracks each week for the first three weeks, so each of us worked across the stack. The fourth week was dedicated to bug fixes and agile enhancements. My work included the tool Claude calls to turn a pasted message into line items, and the validation that runs on whatever comes back. I also built the landing page.
Hammering structure into the model
I wrote the reorder tool Claude calls, a JSON schema with a description on every field. Early versions kept coming back with fields quietly missing and I could not work out why. The schema has to be specific in a way I was not being: strict set on the tool, an explicit required list at every level of nesting, and additionalProperties set to false so nothing extra creeps in. Once those were in place the shape came back identical every time, and the code downstream stopped having to guess.
Deciding what the model does not do
Claude reads the paste and works out what is being asked for. That is the whole job. Looking up a code, applying an account's discount, deciding which fields a role is allowed to see, and choosing the sentence a buyer reads when a stock check times out are all ordinary code, because each has exactly one correct answer for a given input. Keeping that line clear is most of what makes the result trustworthy.
Checking the answer before using it
The schema tells Claude what to send. Zod checks what actually arrived before anything downstream touches it. Anything the buyer never stated comes back as null rather than missing, so a quantity nobody wrote is a value the table can render instead of a hole that throws three layers later.
What I learned
The biggest thing I took away is how much structure a model needs before its output is safe to build on. Left loose, it answers a little differently every time. Pinned down with a strict schema, required fields at every level, and a description on each one, it answers the same way every time. That difference is the difference between a demo and something you can write real code against.
I also learned where a model does not belong. It is tempting to hand it more of the job, but anything with one correct answer, pricing, stock rules, who is allowed to see which field, is better as plain code I can read and test. Apollo ended up with the model doing one narrow thing, and that restraint is what makes the rest of it predictable.
Working in parallel tracks was new to me. My part had to hand structured data to code I did not write, which meant agreeing on the shape early and then not moving it. The schema turned out to be the contract between us as much as it was the instruction to Claude.