Build your business app with AI in 2026?
AI can write working software in 2026. But there's a sharp line between a build that lasts and a demo that falls over by month six. Here's how to tell the difference before you commission anything.
The question we keep getting
The question lands in the inbox once a fortnight now. Some version of: "Can we just build it with AI? Surely it's cheaper?"
Short answer: yes, but the way you mean and the way that actually works are two different things. AI in 2026 can write working software faster than any developer could three years ago. It can also produce confident-looking code that quietly leaks customer data through an auth flow no one thought to check. The difference between those two outcomes is entirely about how the AI is used, not whether it was used.
This is our perspective. What AI builds well, what it doesn't, and where the real cost gets hidden.
It's a tool, not a tradesperson
Anyone can walk into Bunnings and buy a trowel. That doesn't make them a plasterer. Hand the same trowel to someone with thirty years on the wall and they'll skim a room in an afternoon, and you can shine a light across it without seeing a thing. Hand it to a weekend DIYer and they'll spend three weekends on the same wall. Shine a light across it and you'll see every ridge, every missed spot, every bit they didn't quite catch.
AI is the trowel. Same tool, available to everyone. The outcome lives entirely in the hands holding it. The studios charging $5,000 for an AI-built app and the studios charging $50,000 are using more or less the same AI. The first is selling you the trowel. The second is selling you the plasterer. The build you get six months in is wildly different.
That's the article in one analogy.
What "build with AI" actually means
When someone says "let's build it with AI", they usually mean one of three things, and the three are wildly different in price, risk, and shelf life.
1. Prompt-only build (sometimes called "vibe coding"). Someone, usually not a developer, pastes prompts into a chat interface or a no-code AI tool until something resembling software appears. We've written separately about why this falls over by month six. Short version: it demos beautifully, then collapses the first time a real edge case shows up.
2. AI plus an experienced engineer (developer-led AI). A developer uses AI as a fast peer: writing first-pass code, reviewing it, refactoring it, writing tests, owning the architecture. The AI accelerates the work; the engineer owns the outcome. This is what we do at Urban Lightbulb. The majority of our modern code is AI assisted, and none of it ships without review.
3. AI inside the product you're building. Different question entirely. You're not asking how to build the app, you're asking whether AI should be a feature inside it. Document summarisation, intelligent search, smart triage, drafting. Worth doing for the right problems, dangerous when bolted on as marketing.
This article is mostly about the first two. The third we'll cover separately.
What AI builds well in 2026
The unromantic stuff is where developer-led AI shines. Day to day, it handles a big chunk of the typing on:
- CRUD forms, admin panels, internal dashboards
- Schema-to-API boilerplate (database table to Laravel controller to Vue component, the kind of repetition that used to soak up a week)
- Tests, particularly the unit and integration tests that developers historically rushed
- Migrations and data shape changes
- Documentation drafts for handover
The work in each of those is well-understood, the patterns are stable, and a senior developer can spot a bad output in seconds. The AI does the keystrokes; the engineer does the thinking, with the end game in mind.
A medium build that would have taken twelve weeks in 2022 might now ship in eight, with better test coverage than the older version would have had, because writing tests is no longer the boring tax that gets cut at the end of the project.
Where the supervision earns its keep
Five things go wrong on a build when AI's left unsupervised. They're also the five places a developer earns their keep. Without supervision, they're the failure modes you've heard about. With it, they're just managed risks.
Architecture decisions. AI is good at writing code inside a chosen pattern. It is mediocre at choosing which pattern to use for the long horizon. The developer holds the five-year picture in mind — what the app looks like at ten times the data, the third integration, the second user type. Get this wrong and you're staring down a rewrite eighteen months later. With a developer in the seat, the AI generates within a pattern the developer chose, not the other way around.
Security and auth. Plenty of AI-generated auth flows look plausible and have a quiet hole somewhere — default permissions too open, tokens stored where they shouldn't be, CSRF protection assumed and not implemented. A developer with security in mind catches these in review. Our internal prompts and review checklists are built around exactly these patterns, so the AI rarely gets the chance to ship them in the first place.
Long-context coherence. Code that depends on constraints set hundreds of lines away in a different file. The AI doesn't always carry that thread cleanly across the codebase. The developer does — and the tooling (tests, linting, type checking) makes the gaps visible before they ship.
Domain edge cases. AI generates the average version of a problem. It doesn't know that NZ businesses calculate GST a specific way, that your industry has weird billing cycles, that one client always pays late and the workflow has to handle that. A real developer asks the right questions in discovery and then steers the AI through them.
Maintenance. Code with no human author is hard to fix when something breaks at 9 PM the night before a demo. With developer-led AI, the engineer who reviewed it understands it and can patch it. With prompt-only, you're hoping you can re-prompt your way back to a working state.
None of this is set-and-forget. Working with AI takes a lot of time. We run prompts, read what comes back, correct it, run it again. We spend as much time steering the AI now as we used to spend typing. The shape of the work has changed. The discipline hasn't.
The cost question, where the maths actually lands
Most cost arguments about AI miss the point because they compare "$250 of AI tokens" against "$40,000 of developer time" and conclude AI is the obvious choice. It isn't, and that's the wrong comparison anyway. You're not buying tokens. You're buying a working business application that has to last.
A five-year picture for a medium build looks like this:
Prompt-only build: Around $250 in prompt credits if you DIY it. Closer to $5,000 if you hire one of the cheap freelancers now branding themselves as AI builders — often the same operators who've been installing WordPress themes for years without ever writing a line of code. They can run prompts. They can't read what the AI gives back. When something breaks, neither side knows where to look. When real users arrive, you're looking at a rebuild from scratch. The foundation was software, just built badly.
Developer-led AI build: Roughly the same cost as a non-AI build a few years ago. Sits within our normal pricing bands at $30,000 to $75,000 for a medium project. AI hasn't slashed our prices. What it's changed is what fits inside the band: more features, better tests, deadlines we actually hit. You pay about the same and get a better build out of it.
Pure human build (no AI at all). Increasingly rare in 2026. Slower and more expensive than developer-led when you do find it.
The hidden cost of option one is rework. Always. Option two costs you what feels like extra: paying a real studio instead of a $50-a-month subscription to a no-code tool. Option three quietly costs you speed and quality.
What you should actually ask
If you're commissioning a build and you want to use AI properly, a handful of questions sort the studios who know what they're doing from the ones running prompts and hoping. None of these are gotchas. A studio that's serious about developer-led AI will answer them all happily. They sit alongside the broader set of questions to ask any developer before you sign.
-
How does AI sit in your workflow? A good answer talks about how the developer drives the AI, where the AI helps, and where the developer overrides it. A weak answer treats AI as a black box that hands back finished software.
-
Who reviews the code the AI produces, and how? Look for named developers, code review, tests, and tooling like linting and type checking. If review sounds optional or the AI is described as self-correcting, that's a flag.
-
Tell us about a recent build where the AI got something wrong, and how you caught it. A studio actually using AI in real projects will have war stories ready. A studio running prompts on top of a no-code platform will give you a vague, non-technical answer.
-
When something breaks in production, who reads the code and fixes it? The right answer names a human and describes what they actually do. If the response is "we go back to the AI and re-prompt", or "we don't really need to read the code", the build is vibe-coded under the hood.
Our short version: AI should be in the build, not the builder.
Where we sit
Urban Lightbulb runs heavily on developer-led AI. Claude Code is part of our daily workflow. Most of our modern code is AI assisted. None of it ships without an engineer reviewing it, testing it, owning the architecture around it, and being there when it breaks.
That's our line, and it's the line we'd recommend to any NZ business owner considering an AI-built app. Human in the loop. Always. Not as a marketing claim, as the actual reason your software still works in year three.
If you're weighing this up, whether to commission a build at all, or which approach makes sense, that's a free initial conversation. We're as comfortable telling you to buy a SaaS instead as we are quoting a custom build. We've written about that decision too.