Software Development Stages: What Happens Each Week and What You Need to Do

Many first-time clients expect to hand over a brief, wait three months, and receive a finished application. It rarely works that way. A software project is a long series of small decisions, and a fair share of them can only be made by you. Below is what happens at each stage of a typical project for a small or medium business, how long each stage usually takes, and what the vendor will need from you along the way. Knowing this before you sign is the easiest way to keep the schedule.

SDLC Without the Textbook

SDLC stands for Software Development Life Cycle. Textbooks draw it as planning, analysis, design, implementation, testing, deployment, and maintenance, often as a neat circle. Real projects follow roughly the same order, but the stages overlap and the names change. In vendor proposals you will hear discovery, UI/UX design, development, QA and UAT, deployment, handover, and maintenance.

The order matters more than the labels. Decisions made early are cheap to change and expensive to change later. Moving a button in a Figma design takes minutes. Moving the same button after the backend, the app, and the tests are built can take days, and changing how approvals work after go-live can take weeks.

Waterfall, Agile, and What Fixed-Price Projects Really Do

Waterfall finishes each stage before starting the next. The budget is predictable, but you see working software late, and surprises arrive when they are most expensive. Agile works in short cycles called sprints, usually one or two weeks, and re-plans after each one. You see software early, but scope is flexible and billing is usually time-based, which makes finance teams nervous.

Most fixed-price projects in Indonesia sit in between, and ours do too. Discovery and design happen up front and get signed off, which fixes the scope and the price. Development then runs in sprints with a demo at the end of each, inside that fixed scope. New ideas either become a change request or replace something of similar size. Our honest view is that this hybrid suits most first projects. Finance gets a fixed number, and you get to see and correct the software long before the end.

Typical Stages and How Long They Take

The table below is for a small to medium project, such as an internal system with three or four user roles or a customer portal with a payment gateway. End to end, that usually takes three to six months. The durations assume you respond quickly, which is the assumption that breaks most often.

Discovery and Design: Where Your Time Counts Most

Discovery is usually two or three workshops of around two hours each. The vendor wants to know how the work is done today, including the exceptions nobody writes down, so send the people who do the work, not only their managers. A warehouse admin will tell you in five minutes that returns are recorded on a separate sheet, which a manager may not know. The output is a scope document with user flows and a firm estimate.

Design usually starts with wireframes, then moves to a clickable prototype in Figma that you can tap through on your phone. Two rounds of revisions are typical. Use them. This is the last cheap moment to change your mind, and it is also when everyone who can veto the system should look at it, including the director who has been too busy to attend so far.

Development in Sprints, With a Demo Every One or Two Weeks

Each sprint ends with a demo of working features on a staging environment. Staging is a copy of the system on a separate server that you can open in your browser or install on your phone, with test data instead of real data. Attend the demo, then try the features yourself. Twenty minutes of clicking on your own catches more than an hour of watching a developer.

Questions come up in every sprint. Should a cancelled order return the stock automatically? Who can edit an invoice after it is approved? If the answer takes a week, the developer either waits or guesses, and guesses get reworked. Integrations need early attention too. Payment gateway sandboxes such as Midtrans are quick to set up, but API access to an ERP, a bank host-to-host connection, or a partner's system can take weeks of paperwork on their side. Start those requests in the first week.

QA, UAT, and Go-Live

QA is the vendor's testers checking the system against the agreed acceptance criteria, on the browsers and devices your users have, including mid-range Android phones. UAT, user acceptance testing, is you and your staff using the system with real scenarios and deciding whether it is acceptable. Prepare for it: a real product list, a real customer list, and last month's transactions with personal data masked. Pick three to five people who will use the system daily, and give them time away from their normal work to test properly.

Deployment itself takes days: the production server, the domain, data migration, switching users over. Timing matters more. Avoid month-end closing for finance systems, avoid the weeks before Lebaran for anything customer-facing, and go live on a Tuesday morning rather than a Friday evening. For accounting or stock systems, running the old and new process in parallel for two to four weeks is worth the extra effort.

What You Need to Provide, and Why Delays Usually Start There

This is where many projects go wrong. In our experience, more schedule slippage comes from the client side than from the code. A decision waits for a director who is travelling. Product photos arrive two months late. An approval committee sees the app for the first time at UAT and asks for a different flow. A one-week delay in feedback rarely costs just one week, because the team moves to other work and needs time to come back.

1. 1Name one decision maker who can approve scope and design without a committee, plus a backup for when they are away.
2. 2Block two to four hours a week in that person's calendar for demos, questions, and reviews.
3. 3Agree on one channel for questions and a response time. Two working days is a reasonable target.
4. 4Prepare content early: texts, product photos, price lists, email and WhatsApp message templates, terms and privacy pages.
5. 5Request access to existing systems and third-party accounts in week one, such as the Accurate or Jurnal API, the payment gateway, the WhatsApp Business account, and the cloud account.
6. 6Prepare realistic test data and choose the people who will run UAT before development ends.
7. 7Bring everyone who can veto the system into the design review, not the UAT.

If you cannot free a decision maker for a few hours a week over the coming months, it is better to postpone the project than to start it. And if what you need is a simple company profile website, most of this process is overkill. A good template, your content, and two to four weeks is usually enough, and you do not need a software house for that.

Handover, Warranty, and What to Ask For

After go-live, a warranty period of one to three months is common. It covers defects against the agreed scope, not new features. After that comes a maintenance contract, typically a monthly retainer for monitoring, security updates, and small changes. Budgeting around 15 to 20 percent of the build cost per year is a reasonable starting point. Before the final payment, make sure you have these:

• Source code in a Git repository owned by your company on GitHub or GitLab, with access from the first sprint, not a zip file at the end.
• Credentials for the cloud account, domain and DNS, app store accounts, payment gateway, WhatsApp Business, and email service, all registered in your company's name.
• Documentation: how to set up and deploy the system, API documentation, and a user guide for admins.
• A staging environment that stays running after go-live, so future changes are tested before they reach real users.
• Database backups with a tested restore, and the Figma design files.
• The UAT report with your sign-off and the list of known issues, if any remain.

Signs a Project Is Drifting

• Demos get skipped, or show slides and screenshots instead of working software.
• Staging has not been updated for several weeks.
• A feature has been "90 percent done" for three sprints in a row.
• Nobody can tell you clearly what is left and how many sprints it will take.
• Questions to you pile up unanswered, or yours to the vendor do.
• New developers appear on the team without any handover, or the vendor hesitates to give you repository access.
• The bug list grows during UAT instead of shrinking.

Working software on staging every two weeks is the one progress report that cannot be dressed up.

At Salamun Teknologi this is how we run projects by default: a fixed-price discovery and design phase, two-week sprints with a demo on staging, code in a repository under your account from the first sprint, and a warranty period after go-live. If you are commissioning software for the first time, we can walk you through what the first month would look like for your project.