Most custom software projects start as a 60-minute conversation with a vendor. That's a sales call, not scoping. By the time you've talked to 3 vendors, you have 3 wildly different proposals and no clear idea why they differ.
Better: scope the project yourself before talking to any vendor. Here's how.
Why scope yourself first
Three reasons:
- Better proposals. Vendors who get a clear scope produce clearer, more accurate quotes. Comparisons get apples-to-apples.
- Better decisions. Working through scope yourself reveals what you actually need vs what sounds nice. About 30% of "must-have" features evaporate when you write them down.
- Faster sales cycles. Vendors who get clear scope move faster. Discovery time drops from 2 weeks to 2 days.
The 6-step scope process
Step 1: Write the "why"
One paragraph. Why this project, why now, what changes for your business if it works.
If you can't write this in one paragraph, you're not ready to start.
Step 2: Identify the users
For each user type:
- Who are they (role, context, frequency of use)
- What's their main job-to-be-done
- What devices/contexts they'll use it on (desktop primary, mobile primary, both)
If you have more than 5 user types in v1, you're trying to do too much. Pick 1–3 primary.
Step 3: List the screens / pages
Brainstorm every screen the software will need. Don't worry about design — just the list:
- Authentication screens (login, signup, password reset)
- Main dashboards per user type
- Detail pages
- Lists/tables
- Forms
- Settings/admin
Most v1 builds have 10–25 distinct screens. If you have 50+, you're scoping for v2 territory.
Step 4: Map the integrations
What systems does this connect to?
- Payment (Stripe, etc.)
- Email/SMS (SendGrid, Twilio)
- Auth (Google SSO, etc.)
- Your existing systems (CRM, ERP)
- Third-party data sources
For each: read or write or both? Real-time or batch?
Step 5: Define the data model
What are the core entities and relationships?
- User has many ___
- ___ belongs to ___
- ___ has status of ___
This doesn't need to be a formal ERD. Bullets work fine.
Step 6: Write the "out of scope" list
This is the most valuable scoping exercise. Explicitly list:
- Features you've considered and rejected for v1
- Features that are phase 2
- Edge cases that v1 won't handle well
- Integrations that aren't needed at launch
This list is what protects you from scope creep mid-build.
Sanity check before sending to vendors
When the 6-step output is done, sanity check it against these:
- Could a senior engineer read this in 30 minutes and explain what to build? If not, add detail.
- Is the user-experience visible? Does it describe what users see and do, not just what data flows?
- Are the integrations real (with API docs) or wishful thinking?
- Is the "out of scope" list at least as long as the "in scope" list?
If yes to all four, you have a real scope document.
What this gets you
Vendors who receive a scoped project will:
- Quote within 48–72 hours (vs 2–3 weeks)
- Quote with much tighter ranges
- Engage at a more senior level (because the project is more attractive)
- Skip the discovery phase or do a much shorter one
Self-scoping is the single highest-leverage activity in custom software procurement. 2–4 hours of your time saves weeks of back-and-forth and produces meaningfully better proposals.
For a transparent quote based on your scope, our cost calculator takes 60 seconds. Or contact us to discuss.