The SDLC Explained for Business Owners: 6 Stages Before You Pay

If you are planning to pay a vendor to build an app, there is one concept worth understanding before you sign: the SDLC, or Software Development Life Cycle. It sounds technical, but the idea is simple: the sequence of stages an app goes through from idea to daily use and maintenance. Understanding the SDLC as a business owner is not about becoming a programmer. It is about knowing what is reasonable, what you need to prepare, and when to be suspicious.

At Rancangin Aja (RAT) we run these stages on every project, for clients and for our own products such as Cuplikin and KosPro. In this article we explain the six stages from your point of view as a business owner.

Why does the SDLC matter to you, not just to developers?

Software projects that fail rarely fail because the programmers cannot code. They usually fail because:

• The requirements were never really clear.
• The client only sees the result at the end, and it does not match what they imagined.
• There was no testing, so bugs show up once customers are using it.
• Once it is built, nobody maintains it.

All of those are process problems, and the SDLC is a process designed to prevent them. If your vendor cannot explain their stages, that is an early signal worth noting. We cover other warning signs in our checklist for choosing a software house.

Stage 1: Discovery (understanding the problem)

What happens: the vendor asks a lot of questions. Who are the users? What problem are we solving? How does the process work today? What systems already exist? What does success look like?

What you need to prepare:

• The story of your current business process, including the "ugly" or manual parts.
• Real sample data: Excel files, chat screenshots, photos of receipts.
• A list of systems already in use (marketplaces, POS, accounting).
• Who will use the app, and how comfortable they are with technology.
• Constraints: budget, deadlines, internal rules.

Reasonable deliverable: a short document covering the problem, goals, users, prioritised feature list, and the things deliberately left out for now. Plus an initial estimate of cost and time.

Where it usually goes wrong: the client arrives with a feature list instead of a problem. The result is an app full of features that solves nothing. A good vendor will "annoy" you with "why?" questions at this stage.

Stage 2: Planning and design

What happens: the requirements from stage 1 are turned into a design: user flows, wireframes (rough sketches of screens), visual design, and technical architecture (which technology, how data is stored, what it integrates with).

What you need to prepare:

• Time to review the design and give feedback. This is the cheapest stage to change your mind.
• Logo, colours, and brand assets if you have them.
• Decisions on priorities if some features have to be sacrificed.

Reasonable deliverable: wireframes or a clickable prototype, visual designs of the main screens, and a short technical document. For a small project this can be quite simple.

Where it usually goes wrong: the design is approved without really being looked at, and then when the app is built: "why is the button here?". Changing something at the design stage takes minutes. Changing it after it has been coded takes days.

This is also when the scope of the first version is decided. In our experience, a small first version that works is far better than a big one that never ships. We cover how to decide in MVP vs full product.

Stage 3: Development (building)

What happens: developers write code based on the design. In a good team this is done in sprints: short work cycles (usually 1–2 weeks) that end with a demo.

What you need to prepare:

• Attend the demos. Seriously, this is the most important thing you can do as a client.
• Answer questions quickly. A developer waiting 3 days for an answer means 3 days lost.
• Real content and data: product photos, price lists, page copy.
• Required access: marketplace accounts, payment gateway, WhatsApp Business.

Reasonable deliverable: an app you can try at the end of every sprint, a short progress report, and code stored in a repository (for example GitHub) that you have access to.

Where it usually goes wrong: no regular demos, and only at the end does it become clear the direction drifted. Or the client keeps requesting changes without realising the impact on schedule and cost. Both can be prevented with a weekly demo rhythm and clear rules about changes.

Honest note: mid-project changes are normal and often good, because you only truly understand your needs once you see the app. The problem is not the change itself, but when its impact on time and cost is not discussed openly. At RAT, we answer every change request with "yes, it will take X days and cost Y, do you want to proceed?" rather than "yes" followed by a quiet delay.

Stage 4: Testing and QA

What happens: the app is tested from many angles: do the features work, does it handle odd input, does it run on various phones and browsers, is the data secure, is it fast.

There are two kinds of testing that should both be present:

• Automated testing by developers: code that tests code. So new changes do not break what already works.
• Manual testing by your team (often called UAT, User Acceptance Testing): you and your team use the app as you would day to day.

What you need to prepare:

• People from the team who will actually use the app, not just the owner.
• Real scenarios: "try processing an order from chat through to shipping".
• Clear bug reports: what you did, what you expected, what happened, a screenshot.

Reasonable deliverable: a list of tested scenarios, a list of bugs found and their status, and a "release-ready" version of the app.

Where it usually goes wrong: this stage gets cut because time ran out. The result is that customers find the bugs. When a vendor offers a much cheaper price, this is often the stage that has been dropped.

Stage 5: Deployment (launching)

What happens: the app is installed on the production server, the domain is pointed at it, the mobile app is submitted to the Play Store and App Store (review can take several days), old data is migrated, and your team is trained.

What you need to prepare:

• Hosting, domain, Google Play, and Apple Developer accounts in your name, not the vendor's.
• A transition plan: switch everything at once, or part of it first?
• Time for team training.

Reasonable deliverable: the app live, user documentation, a list of handed-over accounts and credentials, and a short guide for what to do if something goes wrong.

Where it usually goes wrong: the vendor holds the accounts and the code. If the relationship sours, you have nothing. Make sure from the discovery stage that ownership of code and accounts sits with you.

Stage 6: Maintenance

What happens: the app is monitored, newly discovered bugs are fixed, the system is updated to keep up with Android/iOS/browser changes, and new features are added based on user feedback.

What you need to prepare:

• A monthly or annual budget. A common range is about 10–20% of the build cost per year, depending on the agreement.
• One point of contact on your team to report problems and collect feedback.

Reasonable deliverable: periodic reports (uptime, bugs fixed), responses within agreed timeframes, and a feature roadmap if there is ongoing development.

Where it usually goes wrong: it is considered unnecessary. An app that is not maintained usually starts having problems within 6–12 months: outdated libraries, third-party APIs that change, security falling behind.

For a picture of the cost of each stage and the monthly costs after launch, see our app development cost breakdown for Indonesia.

Summary: what you need to prepare at each stage

How does AI change the SDLC?

If your project involves AI (a chatbot, a document assistant, automation), the stages are almost the same, with a few additions:

• In discovery: a data audit. AI cannot work without data, so there are extra questions: what data exists, how clean it is, who maintains it.
• In design: designing "what happens when the AI is wrong". The escalation path to a human has to be designed from the start, not patched on later.
• In development: an extra cycle called prompt iteration and evaluation. The instructions for the AI are tested against real data, measured for accuracy, improved, and repeated. It resembles testing, but happens continuously throughout development.
• In testing: besides testing features, there is quality testing of the AI's answers against a set of real questions from your business.
• In maintenance: monitoring API usage costs and answer quality over time, because customer questions change.

If you already have a working app and want to add AI without rebuilding, the process is slightly different and we explain it in our roadmap for migrating an existing app to AI.

How we run the SDLC at RAT

In short: free discovery at the start, a design you review before a single line of code is written, sprints with weekly demos, automated testing plus UAT with your team, a launch with every account in your name, and optional maintenance afterwards. Everything is done by our own team, and you talk directly to the engineers doing the work. Details of our services are here.

Next steps

Understanding the SDLC lets you evaluate vendors with more confidence: you know what is reasonable, what to prepare, and when to ask questions. If you have an app idea and want to know what the stages would look like for your case, book a free consultation or contact us on WhatsApp. We will walk you through the stages, the estimated timeline, and what you need to prepare.