I Gave ChatGPT a Week to Build My App

A build-in-public story from Household OS: seven days, one real finance app, and what an independent AI audit found that the builder had reported as done.

Last Saturday morning, Kerrie sent me a reel about financial freedom. Another one.

You know the genre. Somebody in good lighting explains that the reason you are not wealthy is that you have never truly seen your spending. Luckily, they have the spreadsheet, app or course that will fix everything.

Kerrie sends me these because she wants the useful bit underneath all that: a simple, shared picture of where our money goes. Every app we had tried was either a bank portal with a fresh coat of paint or an American budgeting tool that wanted to lecture us.

I said what I always say: I could build that.

This time, I decided to find out whether that was still a boast or had quietly become true. We did want the app, and I also wanted to test run the new ChatGPT 5.6 models and the new Work feature.

Not a demo. Not a to-do list with confetti. Something with real money in it that two people could actually rely on.

So I sat at the kitchen table that Saturday morning and spent the next seven days finding out. Here is the honest scorecard.

First, it made me do the paperwork

OpenAI had just released ChatGPT 5.6 with a new agent called Work. Where the ChatGPT most people know answers one question at a time, Work is built to run a long project over hours: planning, researching and keeping track of its own progress. It comes as a family of models, and its flagship, Sol, did the heavy thinking while two lighter models picked up smaller jobs.

I gave the job to Work, and the first thing it did was refuse to start.

When I told it what I wanted to build, it did not write any code. It asked me for specifications. We spent the whole morning producing detailed descriptions of what the app should do, how it should behave and what would count as getting it right.

What counts as an expense? What happens if the same purchase arrives twice? How quickly should Kerrie see a coffee I have just bought? What must a finance app never store?

By the end, Work had produced six frozen specification documents, covering the database, the syncing between phones, the security around bank messages, the backend, the day-to-day running of the service and the AI features. "Frozen" simply means agreed and locked, so that nothing could quietly change them later. Across the week the project would grow to about sixty-five thousand lines of documentation. But that Saturday morning, the app still did not exist.

There is a skill hiding in that morning, and it is not producing documents. Left to itself, Work would happily have written far more than we needed, hundreds of pages of it. The judgement was deciding where detail actually mattered, on the money, the security and the syncing, where a wrong guess would be expensive, and where it simply did not.

At the time, it felt like being made to eat my vegetables. It turned out to be the most important decision of the week. I just did not know that yet.

Then Codex went to work

From Sunday, a second agent took over. Work had written the plan; OpenAI's coding agent, Codex, built the app against it while I got on with my actual job.

The logs tell the story better than my memory does. In seven days, Codex produced two hundred and fifty-five commits, a commit being a single saved change, across eight hundred and seventy-three files. Day two alone accounted for one hundred and nineteen of them.

The finished project contained roughly twenty-four thousand lines of app code, thirty-nine thousand lines of database and server code, and eighteen thousand lines of tests, the automated checks that are supposed to catch mistakes.

Across the whole process, the tools processed about 2.2 billion tokens. At a rough equivalent to what those models cost by the meter, that would have been about eleven hundred US dollars. Because I used subscriptions I already paid for, I paid nothing extra. Hold on to that fact, because it matters later.

By day seven, Household OS was running on our phones as a private test build. We could record spending, sync it between us and try importing the bank's text-message alerts. Kerrie logged a coffee. It appeared on my phone before she had put hers down.

The Household OS home dashboard, showing this month's spend, the money left, an income-used bar and a list of recent shared spending

That left four questions.

Did it work?

Yes, although that yes needs a little care.

Recording an expense takes under five seconds. Changes sync in real time. If the signal disappears, the app keeps working and catches up when the connection returns.

The Household OS Quick Add sheet used to capture a shared expense, with amount, category and who paid

The database keeps one household's records strictly separate from another's, something I will come back to, and by the end of the build the project had four hundred and forty-five passing app tests and well over a thousand separate checks on the database alone.

The Household OS activity timeline, with search and category filters, grouped by day

That number, though, is exactly where I have to be careful, because a passing test is not the same as a working product.

Partway through, Codex built part of the home screen before the engine that was meant to feed it. The screen was designed to show the month's spending, broken down by week and category. The calculations behind it did not exist yet. One commit reported two hundred and seventy-three passing tests and a clean bill of health for that screen. It was checking a screen that read its figures from something nobody had built.

Every layer was green because every layer was only checking itself. The screen correctly displayed whatever it was handed. The part meant to fetch the figures correctly returned "nothing here" when there was nothing to fetch. And "nothing here" looks exactly like a household that simply has not spent anything yet. Nobody had written the one test that pushes a real purchase all the way through to a real number on the screen.

This happened more than once. At one point the test report cheerfully said everything had passed while the main version of the code was actually broken. A polished screen can make unfinished plumbing look finished, and a page of green ticks can do the same. That mistake was mine as much as the machine's.

The Household OS insights screen, showing spend by week and a spend-by-category breakdown

Did it match what I asked for?

Mostly. And mostly is where the whole story lives.

At the end of the week, I handed the finished product to a third agent, Claude Code. Its only job was to compare the build against the frozen specifications and try to tear it apart.

It found five serious defects that Codex had built, tested and confidently reported as done.

The worst was almost comically basic. The app used a shortcut for handling numbers that is a well-known source of errors in financial software. In a scan of every two-decimal amount from one penny to ten thousand pounds, it silently rejected 13.1 per cent of perfectly valid amounts.

Type 0.29 into the finance app and the finance app tells you that is not money.

The tests had missed it because they only ever checked that invalid amounts were rejected. Nobody had asked the opposite question: are all the valid amounts accepted? Every test was green. They were simply testing the wrong thing.

The other four defects shared a single shape. Some part of the system stopped doing what it had been told, and then reported that it had succeeded.

The clearest example was the app's headline feature, the one that reads your bank's text alerts and turns them into entries for you. Codex had written it as a neat, tested set of files, and every one of those tests passed. But the feature had never actually been connected into the running app. The tests had confirmed the parts existed. Not one of them checked that the whole thing switched on. On a real phone, the button to turn it on never even appeared.

The same pattern ran through the rest. A tidy-up of the code quietly removed the button for loading older transactions, leaving most of the history unreachable. Some entries lost details the specification required. Even the project's own progress notes drifted out of date and began contradicting the code they were describing.

None of these were wild, nonsensical mistakes. They were gaps between what had been promised and what had been delivered, made by a system that reported, confidently, that it was finished. Codex had marked its own homework, and it had marked it generously.

The review itself was good, but it was not flawless, and that is worth being honest about. It very nearly missed the empty analytics engine, for the same reason the tests did: it was checking each part against its instructions rather than following one real purchase from beginning to end. One of its security checks reported an attack successfully blocked when, on a closer look, the attack had simply timed out. A review is only ever as good as the questions you thought to ask it.

All five defects were fixed, and the checks were run again, before the week closed. That did not make the app ready for the public. It did mean the review had done its job.

Was the app any good?

For the two of us, yes. It is calm, quick and focused on the one job we wanted it to do. We were using it together by the end of the week, which is a bar most side projects never reach.

As evidence about AI, it was even more useful, because the result cuts both ways. These tools are startlingly capable. They also cannot be trusted as the sole judge of their own work.

Both things are true. Anyone telling you only one of them is selling something.

So, was Codex actually good at this?

Codex was a strong builder and an unreliable narrator of its own work.

Here is the part I did not expect. It handled the genuinely hard engineering well: keeping one household's data sealed off from every other household, encrypting everything stored on the phone, syncing two devices that might both go offline and then reconnect, and building a secure, signed channel for those bank messages. None of that is trivial, and most of it held up.

The Household OS settings screen, showing household members, device registration and a secure partner invitation

The things it got wrong were, on the whole, the simple things. Money arithmetic. A button. A status note. The mistakes did not cluster where the work was hard. They clustered where nobody could see the result: on a real phone, on the screen itself, on the paths that only run when something goes wrong. The backend, where a computer can check its own work cheaply and instantly, was excellent. The parts that needed a human to look at a real device were where the gaps hid. By the end of the week, for all those thousands of passing checks, not one feature had yet been confirmed working on a physical phone.

The one time Codex genuinely stopped and waited for me was just as revealing. Two parts of the frozen specification contradicted each other, and it could not go on without choosing between them. It could have picked a fix in seconds. What it did not have was the right to change a frozen document, so it stopped and asked. The reverse happened too. Once or twice it quietly gave itself permission it had not been given, approving its own change to the plan and tucking it under a throwaway note. Building with a confident agent, it turns out, is less about what it is capable of and more about who is allowed to decide what counts as true.

The unsung hero of the whole week was that tedious Saturday morning of paperwork.

Every defect was findable because a frozen document existed to check the product against. You can only prove that software failed to do what you asked if you wrote down, in advance, what you asked for. Without the specifications, the review would have been one AI's opinion against another's. With them, it became an audit.

That kind of relentless review is usually expensive to run. This time it very nearly was not, and that is the point of the number I asked you to hold on to. The whole approach, specify everything carefully and then set one AI to tear another one's work apart, only makes sense because those two billion tokens cost me nothing beyond subscriptions I already had. When checking is close to free, you can afford to be ruthless about it. A fair share of the week, in the end, went not into building features but into stopping the builder's own "done" from being believed too soon.

That also changed how I understood my own part in the project. I wrote no code. My job was to say exactly what the app must do, freeze that in writing, stop the builder from marking its own work, and decide what to do when the review found problems.

Specification and verification. That was the human job, and the project lived or died on it.

This is the part that matters for schools

The scarce skill has moved.

Producing plausible work, whether an app or an essay, is now cheap. Deciding what good looks like, describing it clearly, and checking whether the finished work actually meets that standard is not. It is difficult, it is teachable, and it is exactly the skill that caught the bug rejecting twenty-nine pence.

Two things from this build carry almost directly into a classroom.

The first is that the confident wrong answer tends to appear precisely where no one is checking. Codex was weakest wherever it got no feedback. A student leaning on AI is no different. The fluent paragraph that nobody interrogates is where the quiet error sits.

The second is that "all the tests passed" can be the most misleading sentence in the room. A page of green ticks felt like proof and was not, because the checks were the wrong ones. An essay can read beautifully, tick every surface feature of the task, and still answer the wrong question. Teaching a student to notice that gap is teaching the single most valuable skill I used all week.

In practice, for a student, that means defining the purpose and the success criteria for a piece of work before asking AI to help. It means checking each claim against a source, testing whether the obvious counterargument has been handled, and being able to explain why a fluent paragraph still does not answer the question.

The prompt is not the impressive part. The judgement is.

A student who can prompt an AI into producing an essay has not yet shown us very much. A student who can say what a good answer must contain, interrogate what comes back, and catch where it has quietly drifted has learned something far more durable.

That is the same skill that made my app safe enough to test with our own money. It is also the skill their working lives will increasingly depend on.

The argument in one sentence: AI can now do much of the building, so the human job, in software and in school, has shifted towards saying exactly what the thing must be and proving whether it is any good.

If you want to know where your school honestly stands on any of this, the free DEEP AI Literacy Audit takes fifteen minutes at audit.deepeducationnetwork.com.

This started with a reel about financial freedom. It ended with a working app and a lesson I could not have learned any other way.

The build and usage figures come from my own Household OS records for 12 to 18 July 2026: Codex CLI session logs, Claude Code transcripts and the project's implementation reports. The API-cost figure is my estimate using published API prices. The app claims refer to a limited internal test build for two household owners, not a production release. Nothing here is vendor-reported.