Building Apps With AI: What One Person Can Actually Ship.

Three systems, one laptop, and the parts nobody puts in the sales deck.

In eleven days I made eighty-seven commits to a Unity game that runs on an iPhone. Before that I shipped a multi-tenant app through Shopify app review. Before that, an AI platform that answers customers on two of my own websites every day. One person, one MacBook Air, no team and no funding. This post is about what that actually means if your business needs software built, including the parts that are still slow, still expensive and still require a human to decide things.

Table of Contents

• What Actually Changed
• Three Systems, and What Each One Took
• Building Apps With AI: The Method That Survived Contact
• Measure, Do Not Guess
• What Is Actually Possible For a Business
• What It Does Not Do
• What It Costs
• Where To Start
• Summary
• Frequently Asked Questions
• Related Reading

What Actually Changed

The cheap answer is that AI writes the code now. That is not it, and believing it is how projects fail.

Code was never the expensive part of software. Coordination was. A normal build needs someone to hold the requirements, someone to design, someone to write it, someone to test it, someone to deploy it, and then a weekly meeting where those people discover they each understood the thing differently. Most of the budget goes into the gaps between them.

What collapsed is the cost of holding an entire system in one head. I can now design a thing in the morning, have it built by the afternoon, test it that evening and know by the following morning whether it was the right thing. There is no handover, because there is nobody to hand it to. The feedback loop went from a sprint to a day, and a day is short enough that being wrong stops being expensive.

That is the real change. Not that software got easier to write. That it got cheap enough to be wrong about.

Three Systems, and What Each One Took

Three things, deliberately unalike, because the point is the range rather than any one of them.

A game on the App Store ladder. The Magus is a stealth game for iPhone set in 1786, in the world of my thrillers. Unity 6.5 on URP and Metal. Ten scenes. A development build of 2.8 GB that compiles in four to six minutes. One shell world with districts that stream in and out so a phone can hold it: a coast camp, a village of seventeen houses, a forge cut into a mound, four tunnels running under the island. Villagers walk in groups and you hide by blending into one. Missions are rows in a table driven by world flags. Ladders have their rung positions baked at build time, because reading mesh data at runtime fails on the device. Eighty-seven commits in eleven days. The full account of that build is here.

A commercial app through a platform's review. Jane SEO is a multi-tenant SEO agent live on the Shopify App Store. Multi-tenant means it runs many merchants' stores at once with each store's data walled off from the others. That isolation is the hard part and it is the same problem as building an isolated system for a corporate client. It went through app review like anybody else's app. Four weeks to build, three months to work out what it should be.

A production AI platform. Nexus is the agent in the corner of this page. It answers questions about this business from a knowledge base, qualifies real enquiries, writes content, and tracks what is happening in AI. It runs on its own infrastructure with its own keys. It has been live long enough to have embarrassed me in public a few times, which is the only test that counts.

A game engine, a marketplace app and a production AI service have almost nothing technically in common. That is the point. The method moved between them without changing.

Building Apps With AI: The Method That Survived Contact

Building apps with AI badly looks like a conversation. You ask for a feature, you get code, you paste it somewhere, it half works, you ask again. Six weeks later you have something nobody can maintain and you cannot say why any of it is the way it is.

What works is boring and it has three parts.

Two AIs with different jobs. One is the architect. It reads yesterday's report, makes the design calls, and writes the day's brief as numbered items, each with a proof it must satisfy and a list of ways it may fail. It never touches the project. The other is the builder, running inside the project folder, which executes the brief, runs the tests and makes the build. It never decides what the thing is. Keeping those two apart is the single most valuable rule I have. An AI that both designs and builds will quietly redesign around whatever it found hard.

A rules file neither may break. In the project root sits a file the builder reads before every task. It holds laws, and every one of them was paid for by something going wrong. "Disabled is not unloaded." "Missions add, never edit." "Every control works, always." Twenty-eight of them now. Written down once, and not broken since. For a business system the laws are different and the principle is identical: the agent may not spend money, may not delete records, may not execute code. Those are not settings. They are the shape of the build.

I decide, they execute. The design calls are mine, the names are mine, and what the thing means is mine. That is not sentimentality. An AI will happily build the wrong product beautifully, and it will never be the one to tell you so.

Measure, Do Not Guess

This is the habit that separates a system that works from a demo that worked once.

Every test runs on the real path. In the game that means synthetic touch through the input system, thumb on the stick, real scenes loaded, game time running. No direct method calls and no teleported test bots. That rule exists because the first round of tests invoked buttons directly, passed every time, and then failed on the phone. A test that passes in the harness and fails on the device is worse than having no test, because it tells you that you are safe.

Last week a colour flash in the game's tunnels survived three days of entirely plausible fixes. Each one made sense. None of them worked. So I stopped fixing and measured instead: six hundred frames walked, the mean colour printed for every one, twenty-six flagged. The measurement named the cause in one pass. The player's own skin shader was exceeding Metal's sixteen-sampler limit, and only ever under lantern light, which is exactly why daylight had never shown it.

Three days of guessing against twenty minutes of measuring. I think about that number a lot.

It applies far beyond games. When an AI system gives a wrong answer in production, the instinct is to edit the prompt and see if it feels better. That is guessing. Measuring is running the same fifty questions before and after and counting what changed.

What Is Actually Possible For a Business

The useful question is not what AI can build. It is which things have crossed from "too expensive to justify" into "worth doing this month".

The internal tool nobody would ever fund. Every business has three or four of these. The spreadsheet that four people maintain by hand. The report somebody rebuilds every Monday morning. The quoting process that lives in one person's head and goes on holiday with them. These never got built because they could not justify a developer for six weeks. They can justify a few days.

An agent that answers for you. Not a chatbot following a script. A system trained on your business that answers at two in the morning, works out whether an enquiry is real, and hands you the ones that matter. What that looks like by industry is here.

Work that is repetitive but not simple. Reading a hundred documents and pulling out what matters. Rewriting a catalogue of five thousand products so each one is still distinct. Drafting the first version of everything. These were always too big to do by hand and too nuanced to script. That gap is where most of the value is sitting right now.

The mobile app or the small piece of software. A booking flow, a field tool for people who work outdoors, a customer portal. Things that used to mean an agency and a six figure quote.

Knowledge that exists in one head. This is the quiet one. Most businesses have a person who knows how it all actually works. Getting that into a system that anyone can ask is now a project of weeks, and it is the one that protects you when that person retires.

What It Does Not Do

Here is the part that gets left out, and leaving it out is why so many AI projects die six weeks after the demo.

The model is never the hard part. In order, the things that kill a build are: integrating with the systems you already have, the state of your data, and getting people to change how they work. The AI itself is the third or fourth problem on that list, not the first. Anyone who leads with the model has not done this.

The last twenty percent still takes the time. A working version appears fast enough to be misleading. Then come the edge cases, the error handling, the thing that breaks when two people do it at once, the review process, the deployment. That part has not got much faster, and the gap between a demo and something you can put in front of customers is where optimism goes to die.

Somebody still has to decide what to build. This has got harder, not easier. When building was expensive, the cost filtered out bad ideas before anyone started. Now they get built. Judgement became the bottleneck.

It needs maintaining. Your business changes. Prices move, policies change, products launch, a model gets deprecated. A system nobody updates becomes a system that confidently gives last year's answers.

What It Costs

Three ways in, and the first one exists partly so you can find out you do not need the others.

A one hour call, $100. You describe the business, I tell you where I think the money is leaking and what shape a fix takes. You leave with a direction whether or not you build anything. Book it here.

A full Nexus build, $4,999 plus $299 a month. Custom system, your infrastructure, your code, your keys. The subscription keeps the knowledge current. It does not keep the thing switched on, so cancelling leaves you with everything, still running.

Enterprise, from $9,999. Multi-agent systems, real integrations, automation across a whole operation. Scoped first, always. Start that conversation here.

And the part that costs me money to put in writing: a full build is not the right answer for every business that asks for one. If the honest first step is an hour on a call, I will say so. If the honest answer is that you do not need me yet, I will say that too.

Where To Start

Not with the technology. Start with a week of your own time.

Write down what you actually did, in half hour blocks. At the end of the week, mark everything you would hand to someone else if you could. That list is the brief. It is more useful than any requirements document, because it is real, and because you will be surprised by it.

Almost everyone finds the same shape. The thing eating the week is never the thing they thought.

Frequently Asked Questions

What does building apps with AI actually mean in practice?

Writing the design yourself and having the AI execute it against a written brief, with tests that run on the real path and a rules file it may not break. It does not mean asking a chat window for features and pasting what comes back. The second approach produces something that works for a fortnight and that nobody can maintain.

Can one person really replace a development team?

For a contained system, yes. For a platform with twenty people depending on it, no, and anybody telling you otherwise is selling. What changed is the floor, not the ceiling. The things that were too small to justify a team are now worth building, and that is a much bigger category than people expect.

How long does a custom AI system take to build?

One to two weeks from kickoff to live, for a full Nexus. That covers the knowledge base, the system prompt, the security work, the styling and testing against real questions. Larger integrations take longer and get scoped before anyone commits.

What is the biggest mistake businesses make with AI projects?

Starting from the model. The things that kill a build are integration with existing systems, data quality and change management, in that order. The model is third or fourth on that list. The second biggest mistake is shipping a demo and calling it a system.

Do I own what gets built?

Yes. Your infrastructure, your repository, your API keys, your domain, and the knowledge base built from your business. The monthly subscription keeps it current and maintained. It does not keep it switched on. Cancel and everything stays yours and keeps running.

What if I do not know what I need yet?

That is the normal state and it is what the hour is for. Most people arrive asking for a chatbot and leave having identified something behind it that matters more.

Is my data safe in a custom build?

Each deployment is isolated: separate hosting, separate keys, separate repository. Your data never touches another client's system and is never used to train anything. The agent also cannot spend money, delete data or execute code, so there is nothing worth hijacking even if someone gets a message through.

Related Reading

• What a Custom AI Agent for Business Actually Does.
• Building an iPhone Game in Unity From My Thrillers.
• I Built a Shopify App Alone in Four Weeks. The Idea Took Three Months.
• AI Agents Just Went Mainstream. What It Means for Your Store.