What we learned building around ten AI-assisted applications, and why the MVP turned out to be the cheapest part of the project.
A client messaged me last week. He had just finished a course covering Claude, GitHub, Vercel and Base44, etc. He was energised as he understood how HTML and system creation actually fit together from a non technical perspective. His question was direct: he wanted a part-time staff salary calculation system for HR to use, and could he just build it himself?
My answer was yes. Build it. That part is real and it isn’t a trick.
But I also told him what happens after the demo works, because that is the part the course doesn’t cover, and it’s the part we have now paid for – in cash and in calendar weeks – across roughly ten AI-assisted builds.
First, the part that’s true: the MVP is real
We are not arguing against AI assisted coding. We do it every day.
Our standard approach on a new build is two-pronged. We settle UI/UX in Figma first, using Figma Make and image generation to get the visual language right before a single component is wired up. Then we import that into Claude Code and build the rest – usually HTML and TypeScript on the front end, PostgreSQL behind it. On top of it, we have software engineers reviewing the code together with the AI assistant, this proves to be one of the most important piece as AI does not have context that human have. For e.g, a foresight that implementing additional access control is unnecessary for a local dev laptop use only with no port exposed.
Getting to a clickable, demonstrable, this actually works version is faster than it has ever been. Weeks became days. Days became an afternoon.
So if your goal is to prove a concept, test a workflow, or decide whether an idea deserves funding, build it yourself. You will get there quickly, and you’ll understand your own requirements far better for having done it.
The trouble starts when the demo is mistaken for the system.
Then you hit the details
We ran a live workshop on one of our own platforms. Forty participants, each logging in with their own account, all at roughly the same time. All regression tests passed, full user testing had no issues, concurrent scans and test cases passed, but we neglected one thing – security infrastructure. Session state were not captured correctly, which is a common loophole seen across vibe coding, that will only happen when multiple users login at the same time. Stuff like segregation of database were not implemented fully, found in a consequential in depth manual review with the tech lead and engineer.
The system kept serving the most recent session. Session state was only holding for about five minutes, and under concurrent logins the application resolved every request to the latest session created. Participants started seeing each other’s accounts.
That is not a cosmetic bug. That is a security incident – and it was invisible right up until the moment it wasn’t. With three people testing, it never surfaces. With forty concurrent logins, it surfaces in the first five minutes.
This is the pattern, and it is not “the AI wrote bad code.” The AI wrote code that works for the case you tested. Concurrency, session lifetime, token refresh, tenant isolation – these are the questions someone has to think to ask, because nothing in the build process raises its hand and asks them for you. Compared to how we built software traditionally, we setup the framework, architecture, discuss the approach of session management, concurrency, security issues that might surface especially in owasp, etc. before we build from foundation.
The second pattern is more grinding: you fix one thing and break another. A patch to a working module gets rewritten as collateral damage while the model is fixing something unrelated. You only find out later, usually from a user.
Which raises the question the course never gets to. How do you regression test an AI-generated codebase? What does the test suite look like? How do you prompt so the model constrains itself to the thing you asked about? How do you pin behaviour so that a fix stays fixed?
None of these are advanced topics. They are the fundamentals, and they are the real substance of prompt engineering – not clever wording, but disciplining a system that will cheerfully rewrite anything within reach.
The USD 3,000 lesson
We ran an early build on Replit. It came to roughly USD 3,000.
We then ported that codebase to Claude Code, stood up our own EC2 instance, configured SSH access and port rules, and built a pipeline running from local development through regression testing into production. Working that way on a Claude Max plan, with time-boxed activity, the same class of work costs a fraction of what the platform charged.
But the honest part of that story is the migration itself. We spent weeks undoing what had been generated. Hardcoded values where configuration belonged. Architectural decisions that had been made by default rather than by choice.
And we could not put all of that on the tool, because it was our first project of that shape and we did not yet know how to frame the questions. Which database. How services should connect. Where state should live. What belongs to the application versus the infrastructure. The platform picked defaults because we had not specified anything.
That is where the pricing model misleads. The build looks cheap. Refinement is where the cost lives, and refinement is where a system spends the overwhelming majority of its life.
The tax nobody quotes you: learning the basics
Even with AI doing the typing, someone still has to know:
- how to structure pages and menu links so a person can actually find things
- where the line falls between an admin page and a user page
- what to build first and what to configure later
- what belongs in a settings screen rather than in code
AI will help with every one of these – if you know to ask. That’s the catch. You cannot prompt your way to a question you don’t know exists.
For a team that has done this ten times, these are decisions made in an afternoon. For someone doing it the first time, they are weeks of trial and error, and that trial and error is invisible in any course, because a course hands you a finished structure and starts from there.
What actually changed on our side
This is the part worth understanding, because AI has changed our economics, just not where most people assume.
The old model. Maintenance was a fixed cost carrying real manpower: people eyeballing logs, applying updates, checking data by hand. Enhancements sat entirely outside that. Every request went through impact analysis and was quoted separately.
The current model. Maintenance costs less, because AI absorbs much of the eyeballing and patching. And enhancements can often be slotted into the same cadence at no additional charge. The only thing we pass through is client-paid API usage – if your application calls Claude or another AI service, that’s consumption and it’s billed as consumption.
What that allocation buys in a month with no new requests is worth spelling out, because it looks like unused credit and isn’t: numbered sprint cadences, regression testing, bugs we catch ourselves before you ever see them, data issue resolution, server and security updates, and monitoring.
So the value moved. It moved off writing the first version and onto keeping the hundredth version correct.
So, do you still need a dev team?
Here is how we’d split it.
Build it yourself when you’re proving a concept, testing whether an idea has legs, or solving something internal and low-stakes – few users, no sensitive data, and you’re the only one who has to live with the result.
Bring in a team when real people log in concurrently, when it touches payroll or personal data or anything you’d have to report if it leaked, when it needs to still work in eighteen months after four rounds of changes, or when someone other than you has to maintain it.
A agency specific use case sits right on that line. As a prototype replacing a spreadsheet, or a simple workflow, built over a weekend: go for it, and you’ll learn a lot. As a system HR depends on, holding staff pay data, with multiple people logged in at once – that’s the version that needs the unglamorous parts. Session handling. Access control. A test suite. A rollback path. We know that we strictly do not want employees to see payroll, or the competitor to see what you have. Which could be just a loophole when doing the AI Assisted coding.
The MVP was never the hard part. It was just the expensive part, and now that it isn’t, the difficulty of everything that comes after it is much easier to see.
iTechStudio builds and maintains AI-assisted applications for companies in Singapore. If you have an MVP you’d like reviewed, hardened, or taken over for hosting and maintenance, we’re happy to take a look with the experience we had built up and strong prompts with guardrails and RAG to ensure foundation are set right from the start.
