How we run an 8-week custom software build, week by week

In 2021 we built a web portal for short-stay hosts in Johor, with an admin console for the operations company’s staff, and its first three weeks produced no working software. Week 1 went on requirements with the company. Week 2 produced a clickable prototype of the portal and the console, and week 3 revised it before the build. Weeks 4 to 7 built both on one catalogue, and in week 8 we deployed them, with two-step verification on every administrator account.

Every Sedang Bahagia custom build runs on that plan. Week 1 gathers requirements, week 2 produces a clickable prototype, week 3 revises it with the people who will use it, weeks 4 to 7 build the product on the client’s real data, and week 8 deploys it and hands it over.

Each phase ends with something the client can check:

Week	What happens	What the client receives
Week 1	Interviews, the current process and a look at the data	A one-sentence problem statement, the users and their roles, confirmed data access
Week 2	A clickable prototype, tried by a handful of users	The prototype and the testers’ comments
Week 3	Revisions with the people who will use it	A revised prototype and a signed-off scope
Weeks 4–7	The product, built on the client’s real data	A staging demo every week
Week 8	Data moved in, training and launch	The live product, the source code and the documentation

1. The plan puts three of the eight weeks before the build

The team’s first client projects ran on this plan in 2017, before the company was founded in 2018: a hotel loyalty app for a hospitality group in Indonesia and a fuel rewards app in Malaysia. Every custom build after them has followed it too.

The end date is fixed, and that changes the scope conversation. Once the date can’t move, “what else could we add?” turns into “what has to work in the first week of use?” A build covers one workflow for the people who own it, taken all the way to production, and the rest goes on a backlog (section 7).

One workflow can still need several apps. The skin teleconsultation app we built in 2020 for a clinic group in Indonesia came to four: patient apps on phone and web, a doctor app and a web dashboard for the doctors. A consultation can’t happen without both sides, so all four went live together in week 8.

2. Week 1 gathers requirements from the people who will run the product

The first week goes on interviews and a close look at how the work is done, or how the client means it to be done. On the skin teleconsultation app that meant the clinic group, and on the fuel rewards app the programme team. For the bank-backed marketplace for mums we built in Singapore in 2018, week 1 mapped a mum’s needs from pregnancy to preschool with the bank’s team.

We ask people to walk us through the last time they did the job, step by step, instead of describing the system they want. That brings out the workarounds: the spreadsheet updated by hand at the end of the week, the details typed into two places for one job. Each workaround is a requirement no one has written down.

By the end of the week there is:

• one agreed sentence naming the user, the task and the outcome;
• a list of users and roles, and what each role does in the product;
• every data source the workflow needs, with read access confirmed or a named person who can grant it;
• the other systems the workflow has to read from or write to;
• a first scope draft, to be tested against the prototype.

Data access decides more of the timeline than any feature does. The build runs on the client’s real data from week 4, so week 1 has to find out where that data lives, what state it is in and who signs off access to it. A build whose data is still waiting for approval in week 4 has nothing real to run on.

The problem statement names the user, the task and the outcome

The sentence has to be specific enough to build against and short enough to repeat in every meeting. Written in those terms, the skin teleconsultation app’s first release came to this:

A patient sees a doctor on duty by video call or chat, and the consultation ends in a skincare plan the patient can buy in the same app.

“A teleconsultation app” names none of the three. The longer sentence says who the first release was for, what they had to be able to do and when the job counted as done. It also put the purchase inside the first release, which matched the client’s brief: every consultation was to end in a skincare plan the patient could buy.

3. Week 2 puts a clickable prototype in front of a handful of users

A clickable prototype is a set of linked screens with no working software behind them. On the skin teleconsultation app it covered the video call, the patient brief the doctor read before answering and the product recommendation built during the call. The news app we built for an Indonesian news broadcaster in 2018 had clickable morning, midday and evening editions of its home. Linked screens are quick to make and quick to change, which is why they come first.

A handful of testers is enough. In Jakob Nielsen’s analysis, the first test with five participants found 85% of a design’s usability problems, and a product with two distinct groups of users needed 3 or 4 testers from each (Nielsen Norman Group, 2000). When a product has customers on one side and staff on the other, people from both groups try the prototype before the scope is signed.

Testers try to finish a real task without help and say out loud what they expect each tap to do. Where they hesitate, the screen needs changing, however tidy it looks.

The prototype has limits, and the testers hear them up front. It has no real data behind it, so it can’t show how a screen behaves with a year of records, and the other systems the product will connect to appear as screens with no connection behind them.

A comment in week 2 changes a drawing. The same comment in week 6 changes the database, the screens that read from it and the tests around them, which is why a whole week goes on screens with nothing behind them.

4. Week 3 revises the prototype and signs the scope off against its screens

We go through the testers’ comments with the people who made them, change the screens and walk them through again.

A scope signed against screens leaves less to argue about later. A line such as “manage bookings” can mean one thing to the client and another to the developer, while a screen shows one meaning that both sides have tried.

The sign-off covers six things: the screens and steps in scope, everything deferred with a one-line reason each, the integrations and who grants access to each, the existing records to move at launch, the first team or site to go live, and what the product has to do on real data for the build to count as finished.

A revision round ends when the people who will use the product can finish their job on the prototype without asking how. The plan gives that one week, which goes on rebuilding the screens the week 2 comments point at.

5. Weeks 4 to 7 build the product on the client’s real data, with a demo every week

Sample data hides problems that the client’s own records show on the first day of week 4: missing fields, codes entered in more than one format, the edge cases the client’s team already knows about.

Four weeks of build cover the workflow and the integrations it can’t run without. On the fuel rewards app that meant linking members’ payment cards through a certified payment processor, the directories of partner shops and stations, and the QR code that station cashiers scan to redeem points. The marketplace for mums needed one catalogue fed by the retail partners, clinic bookings and a queue for lactation consultations that called a telehealth partner’s API.

Each week ends with a demo on a staging link, a private copy of the product the client’s team can use between demos. The demo shows the screens finished that week, what has changed since the last one, and the scope calls the build is waiting on. Questions go straight to the technical lead who is building it.

Every integration adds build and test time, and needs access from whoever runs the other system. That is why week 1 lists them, with the person who can grant each one.

6. Week 8 moves the data in, launches the product and hands it over

Launch week starts with the data and the accounts. On the marketplace for mums we connected the partner feeds and loaded the first curated picks and articles before launch. The supplies portal for short-stay hosts went live with two-step verification on every administrator account.

Training happens on the live product, one role at a time, and the documentation written during the build doubles as the training notes.

The handover closes the build:

Item	What it means for the client
Source code	The repository, with its full history
Documentation	How to run, deploy and change the product, written for the next developer
Admin access	Credentials for hosting, databases, app store listings and third-party services, under the client’s accounts
Backlog	The deferred features, each with a rough size and the reason it waited

The fuel rewards and hotel loyalty apps went out on the App Store and Google Play in their week 8, handed over with their source code and documentation.

The test of a handover is whether another team can pick up the product from the code and the documentation alone. Accounts are part of that test. A product whose hosting or app store listing sits under a vendor’s name is one the client doesn’t fully control, so the accounts go under the client’s name.

7. Requests that don’t fit wait on a sized backlog

Eight weeks hold one workflow taken to production. The items that usually wait are admin screens with no user in the first month, integrations that can run as a CSV export for now, rare edge cases someone can handle by hand, reports with no specific question behind them, and settings screens whose options can sit in a documented configuration file.

Nothing on that list is dropped. Each item goes on the backlog with a rough size, the workflow it belongs to and who asked for it. Real use after launch shows which ones matter.

A request that comes up during the build has to pass three questions:

1. Does it serve the workflow signed off in week 3?
2. Would the product be unusable on day one without it?
3. Is there a manual or CSV workaround for the first month?

It joins the build only if the first two answers are yes. A workaround for the first month usually means the second answer is no, and the request goes on the backlog with a note on who asked for it and why.

8. Takeaways

Three weeks of requirements and screens come before any build. A comment on the prototype changes a drawing, and the same comment after week 4 changes the database, the screens and the tests. Signing the scope off against revised screens lets weeks 4 to 7 go on building.

A handful of testers from each user group is enough. A build with two groups of users puts the prototype in front of both before the scope is signed.

Data access sets the pace. The build runs on real data from week 4, so access has to be confirmed in week 1, while there is still time to chase it.

The handover closes every build. The source code and documentation go to the client at the end of week 8, and the backlog says what waited and why.

We run the same eight weeks for web apps and mobile apps. How much the first release holds depends on whether it is there to test an idea or to be used every day, which MVP vs MLP sets out.