Feature lists are easy. Everyone has them — usually three pages long, copied from a competitor's site and padded with "AI dashboard" because it sounds modern.
What actually keeps custom software projects on track is scope boundaries defined before anyone writes code — what is in v1, what is explicitly out, who decides when something new is in, and what problem v1 must prove it solved.
Philippine SME projects often struggle not from bad developers but from unspoken expectations. Scoping is how you make expectations speakable.
Start with the operational problem, not the screen list
Before features, name the pain in business terms:
- How many hours per week does this manual process cost?
- What errors happen and what do they cost?
- What customer promise breaks because systems do not talk?
- What cannot scale if you open a second branch or hire three more staff?
If you cannot answer those, you are not ready to scope — you are ready to discover. That is fine, but call it discovery, not fixed-price build.
We turn pain into outcomes — "reduce double-bookings to zero" beats "add calendar module."
Define users and permissions before workflows
Who uses the system daily? Who approves exceptions? Who only reads reports? Who must never see payroll or cost fields?
Role clarity prevents scope creep disguised as "just one more button." It also surfaces integrations — if finance never logs in, maybe they only need an export, not a full module.
Document:
- Primary users and their goals
- Approval chains
- What each role can create, edit, delete, export
Draw workflow states, not just features
Features are nouns. Workflows are verbs with states.
Instead of "booking module," define:
- Requested → confirmed → paid → completed → cancelled
- Who moves each transition
- What triggers notifications
- What happens when payment fails or customer no-shows
States expose edge cases early — the source of most "we forgot to account for that" moments. Our approach to modeling this before code is covered in Why We Model the Domain Before Writing Controllers.
Explicit in / explicit out
Every scope document should have two lists of equal importance:
In v1:
- Core workflows that remove the main pain
- Integrations required to go live (payment, SMS, accounting export — only if truly blocking)
- Roles and permissions agreed above
- Migration of essential historical data (if any)
Out of v1 (written down):
- Nice dashboards and analytics
- Mobile apps (unless mobile web covers v1)
- Every report finance might someday want
- AI features, chatbots, loyalty programs
- Integrations that are "good to have" but not blocking daily ops
When a new request arrives mid-build, you point to the out list and ask: replace something in v1, add budget and time, or defer to phase two?
That conversation is awkward once. It is expensive without it.
Integrations: required vs eventual
Philippine businesses often assume "it should connect to everything." Each integration is scope — API quirks, auth, error handling, mapping fields, support when the vendor changes their API.
For each integration ask:
- Does staff manually work around this today?
- Does launch fail without it?
- Is there a CSV export bridge for v1?
Sometimes a nightly export beats a six-week API project for month one.
Data migration: how much history matters
Not all spreadsheet rows deserve to live forever in production. Scope migration separately:
- What records must be live on day one?
- What can stay archived as read-only export?
- Who validates migrated numbers before go-live?
Migration is often underestimated. Name it in scope to avoid launch-week surprises.
Success metrics and change control
Scope should end with how you know v1 worked — hours saved, errors down, no shadow spreadsheet. Vanity metrics ("system launched") do not justify phase two.
Agree who approves scope changes and how timeline and cost adjust. Without that, the loudest voice becomes the product owner by default.
Scope before quotes, not after regret
If you have a long feature wish list but no boundaries, talk to us before you commit to a vendor or a number. We will help you cut v1 to something shippable in 90 days that proves value — and document what waits. That is how our custom systems & web applications engagements stay predictable.
