Scoping a First App Version in Four Weeks: How to Avoid an Oversized First Build

Most first custom builds do not fail because the builder cannot build. They fail because the first version quietly became the final version: every idea anyone had, every report the accountant might want, every role, every integration and every polished screen, all promised for launch day. The result is a long project, a large quote and a launch that keeps slipping while the people who needed a simple tool wait.

This guide is for a non-technical owner commissioning a first app or business system who wants a small, launchable first version. It shows how to shrink an idea to something that can go live and be used, using plain steps you can do on paper before you talk to any builder. It uses a four-week time-box as an example planning exercise, not as a promise from any supplier. It is general guidance; how long a real project takes depends on its size, and the only reliable figure is the one in a written quote. For what drives duration, see how long a custom business system takes.

Why first builds balloon

The same few things happen again and again, and none of them are anyone's fault. Knowing them helps you spot them early.

• Everyone adds one thing. Each person who is asked what the system should do adds a favourite feature. Nobody removes anything, so the list only grows.
• "While we are at it" thinking. If a screen exists, it seems cheap to add a button. Every button needs design, building, testing and explaining, so it is rarely cheap.
• Fear of a second round. Owners worry they will only get one chance, so they ask for everything now. A smaller first version that works is the surest way to get a second round.
• Vague words. "Easy to use", "complete" and "flexible" cannot be tested, so they never finish. Concrete tasks can be finished.
• Guessing instead of watching. Features chosen before anyone has used the system are guesses. Real use shows which ones matter.
• Hidden extras. Features that sound small, such as several languages, many user types, links to other software or a mobile app as well as a web app, can each carry large hidden work.

Step one: write the problem in one sentence

Before listing features, write a single sentence of the form: "[Who] has trouble with [what], which costs us [what], and we will know it is fixed when [observable change]." If you cannot say it in one sentence, the project is still several projects.

Compare two versions. "We want an app to manage the business" is a wish; nobody can tell when it is finished. "Customers keep phoning to ask whether their repair is ready, and staff lose time finding the paper ticket, and we will know it is fixed when staff can find any job in a few seconds and tell the customer its status" is a problem you can build against and test.

Keep this sentence at the top of every document and every meeting. When a new idea does not help solve it, the idea belongs on the later list.

Step two: the "one user, one job" cut

Most business ideas involve several kinds of people: the owner, a manager, staff, customers, suppliers. A first version that tries to serve all of them is where size explodes, because every kind of person needs their own screens, rules and testing.

Instead, choose one user and one job:

• One user: the person who will touch the system most often, or who feels the pain most. If the system works for them, you have proof of value.
• One job: the single task that user must be able to finish from start to end, such as taking in a repair job and finding it again later.
• One finish line: an outcome you can watch someone achieve, with real information, without help.

Everything else, including the owner's overview, the customer's own view and reports, is valid but comes later. Leaving other users out does not mean forgetting them. It means asking the builder to avoid choices that would block them later, then building them when the first job works. Who may see and change what is a topic of its own: user roles and permissions in a custom business system.

Step three: sort the ideas into must, should and later

Now write down every idea, from everyone, without judging. Then sort each one. This is a plain-words version of a common project-management method known as MoSCoW (must, should, could, won't). Four buckets are more than a first version needs, so here there are three.

Be strict with the must column. Sources on this method note that "must" and "later" are easy to agree on, while "should" is where people argue. If your must list has more than a handful of items for one user and one job, ask the harder question again: could they finish the job without this? If yes, it is a should.

Also ask the builder to mark any item that looks small but is not, such as a link to another system or a second language. Surprises are cheapest when they appear before the quote is accepted.

A worked example (made up): a repair shop's job-tracking app

This example is invented to show the method. It is not a real customer, a real project or a real price. Imagine a small repair shop with one counter and two technicians that fixes phones and small appliances. Jobs are written on paper tickets and customers ask for updates by phone and WhatsApp.

• Problem sentence: customers keep asking whether their repair is ready, and staff lose time finding the ticket; it is fixed when any job can be found and its status told within a few seconds.
• One user: the counter staff member.
• One job: take in a repair and, later, find it and tell the customer where it stands.

The first version is five musts. It is not impressive, and that is the point: it can be tested on a real counter within days of being built, and the shop will learn which later item it truly misses.

An example four-week time-box

This is an example planning exercise, not a Gotka promise and not a typical duration. A time-box means you fix the time first and then shrink the scope to fit, instead of fixing the scope and hoping the time follows. You can ask any builder to scope your must list against a time-box like this, then compare their answer with a written quote. If a builder says your musts need longer, ask which items drive that, and cut the list before you squeeze the schedule.

Notice what the example protects. The testing week is not squeezed when the build runs long; instead, the must list shrinks. Your own answers also matter: slow decisions in week two stretch any schedule. For how to run week three properly, see how to review and test a custom business system before you accept it.

What to defer, and why

Four groups of features are most often asked for on day one and are most often better later.

• Reports and dashboards. A report needs real data to be useful, and you do not yet know which numbers you will want. Export a list to a spreadsheet at first. When the questions become clear, see business dashboards and reporting.
• Links to other systems. Each connection to accounting, e-commerce, messaging or e-invoicing adds work on both sides and new things that can break. Keep a manual step first and automate once the process is stable.
• Extra roles and approvals. Start with the owner and one kind of staff. Add managers, branch limits and approval steps when real use shows they are needed. If your business already needs strict separation, say so in the brief.
• Polish. Custom colours, animations, fancy onboarding and extra languages make a system pleasant, but they do not prove it works. Aim for clear and tidy now. Polish what real users complain about later.

Two decisions deserve their own thought before you cut them: whether it should be a web app or a mobile app (see web app vs mobile app) and whether it must work without internet (see offline use). Both change the size of the build, so decide them in week one, not week three. Security basics are not polish either; see security basics for a custom business system and keep them in the must list where they apply.

How to say no to scope creep

Scope creep is the slow addition of "small" requests after the scope is agreed. It rarely arrives as a demand. It arrives as "can we just..." in a chat message. Saying no is easier when you have words ready and a place to put the idea.

• "Yes, and it goes on the later list." The idea is respected, not lost, and not built now.
• "What do we take out to fit it?" If something new goes in, something of similar size comes out, or the date moves. Say this to yourself as well as to the team.
• "What problem does it solve for our one user?" Look back at the problem sentence. If the answer is unclear, it waits.
• "Can we do it by hand for a month?" A manual workaround costs nothing and shows whether the feature is really needed.
• "Let's see it after launch." Real use gives better answers than meeting-room guesses.

Ask one person, usually you, to own the scope. If five people can approve additions in chat, nobody is in control.

A change-request habit

Not every change is bad. Real learning during the build is a good reason to change the plan. The habit is to change it on purpose and on paper. A change request is a short written note, and it can fit on half a page:

• What: the change, in one or two sentences.
• Who asked and why: the problem it solves for the one user.
• What happens if we do not do it: the honest cost of waiting.
• Effect on price and date: filled in by the builder before anything starts.
• Decision and date: approved, swapped for another item, or moved to later, with the name of who decided.

Hold a short weekly review of open requests rather than reacting to each one. Keep the later list in the same place so the answer to "where did my idea go?" is always visible. How changes are handled after launch is covered in bugs vs changes after launch, and how different pricing models treat changes is in fixed price vs hourly rate.

Write acceptance criteria before the build

Acceptance criteria turn "done" into statements anyone can test. Write one or more for each must, in plain words, with real tasks and no adjectives. For the repair shop example:

• A counter staff member can create a job with name, phone, item and fault, and the system gives it a job number.
• A staff member can find that job again by phone number or by job number.
• A technician can change the status from received to in repair to ready, and the counter sees the new status.
• Each of the three staff signs in with their own login, and the job shows who last changed its status.
• After closing and reopening the system, all jobs entered earlier are still there.

Avoid criteria such as "fast", "easy" or "user-friendly" unless you attach a task and a person: "a new staff member creates a job unaided after a five-minute explanation" can be tested; "easy to use" cannot. Accept the first version when the musts pass, not when every wish is delivered. The whole routine is in the acceptance testing guide.

Questions to ask your builder

Take this list to the first meeting. Good builders welcome these; evasive answers are useful information too.

• Can you scope my must list against a time-box I choose, and tell me what does not fit?
• Which of my must items are bigger than they look, and why?
• What would you leave for version two, and will you avoid choices that block it?
• How are changes requested, priced and approved? Can I see a sample change request?
• What does the quote say is out of scope?
• What will I be able to see and test, and when, before the final date?
• How many rounds of testing and fixes are included, and what counts as a fix rather than a change?
• What do you need from me, and how quickly, to keep the schedule?
• What happens to the later list: do you keep it, and can I use it for a second quote?
• Who owns the code and the data at the end? See source code ownership.

When quotes arrive, line them up on scope first; how to compare custom software quotes shows how, and what to prepare before your first conversation covers the information to bring.

Common mistakes

• Calling everything a must. If everything is a must, nothing is. Use the test question.
• Choosing the time first and the scope never. A time-box only works if the scope shrinks to fit.
• Squeezing the testing. Skipping real-user testing to save time moves the problems to launch day.
• Testing with the owner alone. The person who understands the system best is the worst test of it.
• Agreeing changes in chat. Verbal "small" additions are how budgets and dates drift.
• Never writing the later list. Ideas that are discarded come back as complaints; ideas that are written down can wait.
• Treating launch as the end. The first version is the start of learning; book a review a few weeks after launch.

Where Gotka Technologies fits

Gotka's App & System Development service builds mobile apps, web apps and business systems, with indicative starting prices of RM8,000 for web apps and dashboards, RM12,000 for business systems and integrations and RM15,000 for mobile apps, each confirmed by a written quote once your needs are scoped. This guide is general advice and does not describe any Gotka delivery time. The four-week plan above is an example you can use with any builder; a real timeline comes only from a written quote. If you want to talk through your must list, get in touch.

Related reading on cost and fit: what drives mobile app cost and signs you need a mobile app.

Key terms used in this guide

• First version (version one): the smallest release that lets one user finish one real job.
• Scope: the written list of what will and will not be built.
• Scope creep: the slow growth of scope through small unrecorded additions.
• Must, should, later: a plain-words sort of ideas, based on the MoSCoW method (must, should, could, won't).
• Time-box: a fixed period within which the scope is shrunk to fit, rather than the other way round.
• Change request: a written proposal to add or alter something after the scope is agreed, with its effect on price and date.
• Acceptance criteria: plain, testable statements that define when each must is done.
• Punch list: the list of problems found in testing, sorted into fix now and can wait.