The AI SDLC: How an Idea Becomes a Live Product in 80 Hours
Naresh Shanmugaraj
Software is built differently now, and AI is the reason. We call the new process the AI SDLC, and it collapses the distance between an idea and a working product: a venture capital CRM went from idea to live product, web app and native iOS app included, in about 80 hours. The same product would have taken 8 to 9 months the traditional way.
This article explains how the AI SDLC works, what the example build showed, and what founders and product teams can take from it.
The tools change every five years. The process has not.
Anyone who has worked in software for a few decades has seen the waves: desktops, new programming languages, the cloud, mobile, and now AI. Major shifts arrive roughly every five years.
One thing has stayed almost constant for 40 to 50 years: how software gets built. The process is called the software development life cycle, or SDLC. There is a user and an idea of what that user needs. A team of designers, developers and QA engineers turns the idea into a product. Companies vary the details, but almost every app in daily use came out of this same model.
We believe AI will change the SDLC itself, and that this goes beyond code generation. Code generation is valuable, but the larger shift is that the distance between an idea and a working product is collapsing.
How the traditional SDLC works
Take an e-commerce app. A typical build moves through five stages.
- User profiles. However large the product, it usually has only one or two user profiles. An e-commerce app has a buyer and a seller. The team identifies their problems and the major journeys each profile takes. For the buyer, the main one is to search for a product, view a list, compare, shortlist and buy. Smaller journeys include adding to a cart, leaving a comment or changing an address.
- UI/UX design. Designers turn those journeys into screens, as wireframes or a Figma prototype.
- Backend. The backend team builds the databases and APIs. The tech stack depends on how many users and how much data the product has to handle.
- Frontend. A web or mobile developer wires the screens to the backend, so the product can finally be seen from the user's side.
- Testing and audit. QA and security checks close out the process.
A build like this takes a minimum of 6 months to a year. The diagram below sets it next to the AI SDLC described in the next section.
The AI SDLC: three components, one laptop
The AI SDLC has three components: an AI product manager, Claude Code, and MCP. All three run from one laptop.
The AI product manager. This is a conversational assistant. You give it your idea and it asks about user profiles, user journeys, features and how your product compares with competitors. A common setup is a custom GPT in ChatGPT that takes you through seven stages. Early questions include whether you are building for one company or a product anyone can sign up for, what the signature features are, and how you compare with the competition. At the end of the seventh stage it produces a Claude Code prompt as a Markdown (.md) file.
Claude Code. You hand the whole file to Claude Code and run it. Claude Code is not a tool for small prompts. The file runs to 600 or 700 lines and defines the features, user profiles and journeys, and a single run produces a web app on localhost. You then use it as a user would and keep asking for changes, such as moving a feature or fixing a journey, until it is right.
MCP. MCP (Model Context Protocol) is a standard way to connect an AI model to another system's tools and data. Once you have an account on a cloud platform, you take that platform's MCP connection and give it to Claude, and Claude builds the backend. In the demo it mapped the web app's features onto the platform's existing modules, wrote custom modules where needed, and created workflows and blueprints.
From idea to live product in seven moves
The example build can be broken into seven moves. They are separate from the seven stages of questions inside the AI product manager.
Plan (moves 1 and 2). You describe the idea to the AI product manager, answer its questions, and receive the build spec. Everything downstream depends on this file, so this is where the thinking happens.
Build (moves 3 and 4). You run the spec in Claude Code and get a working web app on your own machine. Then you iterate in real time: move a feature, correct a journey, make the layout work on mobile. Keep iterating until you are happy that everything is right before connecting anything.
Connect and launch (moves 5 to 7). You sign up for a cloud platform and connect it through MCP, so Claude maps the app to the platform's modules, workflows and blueprints. Finally, you host the web app and connect sign-in with OAuth. From that point anyone can sign up and use the product.
A worked example: a venture capital CRM
The example product was a CRM for a venture capital investor. In the example, an investor named Kumar has backed 20 to 25 companies. The product has two user profiles, the investor and the founder, and both can log in.
Every three months a founder can upload financial documents for the investor's team to view. When a founder has good news, such as an engineering milestone or a new customer, they can post it in the product instead of sending a message on WhatsApp. The investor can message all the founders he has backed at once, while his team works on the financial and legal side.
The same product was also built as an iOS app, again using Claude. It is native Swift, not a progressive web app and not built with Expo or Capacitor. The investor can keep it in his pocket, check details and send messages.
80 hours instead of 8 or 9 months
By the build team's account, the venture capital CRM would have taken 8 to 9 months under the old SDLC. It took 80 hours. The result was production grade, with security audits done and both the web app and the native iOS app covered. A production version existed at about half that time, around 40 hours, with the rest spent iterating.
Our own client work points the same way. For Milta, a Belgium-based telecom company, we built Bereload, a telecom app with local and international top-ups, SIM swaps, secure payments and real-time order management, shipped in three months. We also built MILTA RMS, a retail management platform that digitized retailer onboarding for a telecom provider, in seven weeks.
The 80-hour figure above is as reported by the team behind that build. Treat it as one team's result, not as a benchmark for every project.
Why understanding the user matters more now
If AI can write code for you and for a competitor, and you both take the same product to market, whose product wins? The answer comes down to who understands the user better, because everything else has become a commodity.
That fits how the process works. The quality of the spec decides the quality of the build, and the spec can only be as good as your picture of the user profiles and their journeys. The AI product manager asks the questions. In our view, the answers about who your users are and what they need still have to come from you.
Who this approach is for
The AI SDLC suits anyone with an idea worth building. Here are a few examples of the kind of people it fits.
- A school student who, after a visit to Kennedy Space Center, wants to build an app that monitors space debris.
- A Gen Z founder working on the next viral app.
- Product managers and partners of software companies whose daily work is building apps for customers.
- Professionals such as lawyers, doctors and finance consultants who have a strong idea and no development experience.
These are examples, not a shortlist. The pattern is the same in every case: an idea that has sat in someone's head for years becomes a working product without a development background.
What this means for your business
We see this shift as a strong signal about where product building is heading, not as a recipe that fits every project. A few practical points follow from it.
- Write down your users and their main journeys first. The whole process depends on them, and no tool can supply them for you.
- Treat the spec as the product. A 600 to 700 line file defines what Claude Code builds, so time spent on it pays back in the build.
- Review before you ship. Security, data handling and long-term maintenance still need experienced engineers, whatever the tools produce.
- Start with one focused product. The example was a single CRM for one kind of user. A narrow first version is easier to check and to improve.
At Cogntix, we design, build and ship AI products for founders and product teams. If you have an idea you want to test quickly, our MVP in 3 Days sprint is a fixed-scope, fixed-price way to put a live product in front of users, and our team can help you plan, design and engineer it properly. To talk through your idea, book a discovery call.
