What a scope of work for software development should contain

That sentence, said mid-project, is what a scope of work exists to prevent. Without a written scope, a quote is a guess, and each side fills the gaps with its own assumptions. With one, the disagreement happens at the start, when changing your mind costs a sentence in a document instead of rework in code.

Copy this list and tick each item against any scope you receive.

• What is being built: specific enough that someone outside the project could tell whether it was delivered. “An inventory system” isn’t enough; name the users, the tasks they can do, and the screens or features behind those tasks.
• Price, with GST stated clearly as included or added.
• Payment schedule: if payment is split, when each part is due and what it is tied to.
• Delivery time, and what it depends on from your side, such as feedback, content or access to other systems.
• Extra costs: anything outside the quoted price you might be asked to pay, such as work caused by data supplied late.
• Total cost including third-party services, each marked one-time or recurring, even if the amount depends on usage. Our web app cost guide lists the usual running costs.
• Third-party accounts: in whose name they are opened. Accounts in your business’s name keep you in control.
• Users and roles: every type of user, and what each can see and do.
• Core flows, step by step: raise a quotation, convert it to an invoice, record the payment.
• Integrations: each system, what data moves, in which direction, and who provides access.
• Data migration: what comes in, from where, how far back, and who cleans it.
• Platforms: web, mobile browsers or native apps, and which browsers and devices get tested.
• Languages, and who provides translations.
• Content: who writes the text and supplies images and product data.
• Out of scope: a plain list of what isn’t included. Often the most useful section in the document.
• Assumptions behind the price: approximate volumes, number of users, third-party APIs working as documented.
• How each main feature will be checked as done.
• How you’ll see progress along the way.
• How new requests are handled and priced.
• Ownership and handover: who owns the source code and the repository, and what you receive at the end. At minimum, the code and access to the repository. With Microsive, both belong to you.

A Microsive scope always states these five: what we are building, the price, the delivery time, any extra costs, and the total cost including third-party dependencies. Those five make a good minimum test for any scope you receive.

Scopes often get approved by the owner and discovered later by the staff. Before you accept:

1. Walk through a normal day with the people who’ll use the software. Can they do everything they need with what’s listed?
2. Walk through a bad day. A payment fails, a customer disputes an invoice, an employee leaves. Is there a way to handle each?
3. Circle every vague word: “simple dashboard”, “standard reports”, “basic admin”, “user-friendly”. Ask what each includes.
4. Compare the out-of-scope list with your expectations. If something you assumed is there, raise it now.
5. Check the money: GST clarity, named third-party costs, a written change process.

• No out-of-scope section, so everything and nothing is included.
• Features listed as nouns (“reports module”) with no description of what they do.
• No third-party services mentioned, when the app clearly needs them.
• Delivery dates with no stated dependencies on your side.
• Nothing about who owns the code.
• “Minor changes included” with no definition of minor.

A detailed scope suits a fixed price, because both sides know what the price buys. If your work is a steady stream of small, unpredictable changes, another arrangement may fit better. For the factors that move the price inside a scope, see our guide to web app costs in India.

If you want something added or changed later, Microsive quotes it before doing it. The rest of the process is on our how we work page.