Build Scope And Requirements Meeting Guide

Build Scope And Requirements Meeting Guide

Build Scope And Requirements Meeting Guide

Last updated: 2026-05-29

Use this document when discussing a "Numeo-like" project.

The goal is to avoid vague scope. Do not accept "build something like Numeo" as a requirement.

1. The main clarification

Ask this first:

What exact software are you paying for today, and what exact parts do you want to replace?

Then ask for:

  • Product name
  • Monthly/annual cost
  • Screenshots or demo
  • List of features they actually use
  • List of features they do not care about
  • Data export options
  • Integration list
  • Number of users
  • Number of trucks
  • Number of MCs
  • Number of loads per month

2. Possible project sizes

Small project

This is realistic for a small team or strong full-stack developer.

Examples:

  • Chrome extension for DAT/Truckstop workflow improvements
  • Email templates and one-click broker outreach
  • Profit calculator
  • Load detail copier
  • Saved searches
  • Simple alerts
  • Basic broker notes and blacklist
  • AI email drafts with human approval

Likely timeline:

  • Prototype: 4-8 weeks
  • Useful MVP: 2-4 months

Main dependencies:

  • Chrome extension
  • Backend
  • Auth
  • Email integration
  • Customer testing

Medium project

This needs a small team and careful integration planning.

Examples:

  • Multi-board load search
  • Load normalization
  • Load scoring
  • Load Radar alerts
  • Email reply tracking
  • Basic dispatch board
  • AI search assistant
  • Rate confirmation parsing

Likely timeline:

  • MVP: 4-8 months
  • Reliable paid product: 6-12 months

Main dependencies:

  • Load-board access
  • Broker portal access
  • Email integration
  • Data freshness strategy
  • Background jobs
  • Strong domain advisor

Large project

This is a company-level build.

Examples:

  • Full TMS replacement
  • Dispatch board
  • Fleet management
  • Driver management
  • Accounting and invoicing
  • Safety/compliance
  • ELD/telematics integrations
  • Document automation
  • Multi-tenant enterprise roles
  • AI Track and Trace
  • Broker update automation
  • Migration from current TMS

Likely timeline:

  • First serious version: 12-18 months
  • Mature replacement: 18-36 months

Main dependencies:

  • Engineering team
  • Domain experts
  • Customer onboarding
  • Data migration
  • Security process
  • Support team
  • Vendor partnerships

3. Questions to ask about users

  • Who will use it every day?
  • Dispatchers only, or drivers, accounting, managers, and safety staff too?
  • How many daily active users?
  • How many trucks?
  • How many loads per week/month?
  • How many MC numbers?
  • Are users in one office or distributed?
  • Do they need mobile access?
  • Do drivers need an app?
  • What is the current workflow from finding a load to getting paid?

4. Questions to ask about current software

  • What software do they currently pay for?
  • What does it cost?
  • Why do they want to replace it?
  • What do they like about it?
  • What do they hate about it?
  • Which features are business-critical?
  • Which features are just nice-to-have?
  • Can data be exported?
  • Are there APIs?
  • Are there contractual limits?
  • What happens if the replacement fails for one day?

5. Questions to ask about load sources

  • Do they use DAT?
  • Do they use Truckstop?
  • Do they use broker portals?
  • Which broker portals?
  • Do they already have API access?
  • Do they have written permission to automate or integrate?
  • Are they expecting browser extension automation instead of API access?
  • How fresh does load data need to be?
  • How many searches per day?
  • What filters matter most?
  • What makes a load "good" for them?

6. Questions to ask about booking and negotiation

  • Do dispatchers negotiate by email, phone, portal, or all three?
  • Should AI only draft messages, or send messages?
  • Who approves an offer?
  • Can AI ever book a load automatically?
  • What is the rate floor?
  • What rules must never be violated?
  • What should happen when a broker replies?
  • How should the system track negotiation status?
  • Do they need call transcription or voice AI?

Recommendation:

Start with AI drafts and human approval. Do not start with fully autonomous booking unless the customer deeply understands the risk.

7. Questions to ask about TMS replacement

If they say they want to replace their current TMS, ask:

  • What is the current TMS?
  • What modules are used?
  • Dispatch only, or accounting/fleet/safety too?
  • Do they need invoicing?
  • Do they need driver settlement?
  • Do they need factoring integration?
  • Do they need QuickBooks integration?
  • Do they need ELD/telematics integration?
  • Do they need document storage?
  • Do they need rate confirmation parsing?
  • Do they need BOL/POD matching?
  • Do they need customer/broker portals?
  • Do they need custom reports?
  • Who owns data migration?

Important:

Replacing a TMS is much bigger than building a Numeo-style assistant.

8. Technical architecture for a realistic v1

Recommended v1 stack for your background:

  • React web app
  • Chrome extension
  • Node.js or Python backend
  • Postgres database
  • Redis or queue for background jobs
  • S3 for documents
  • Cognito or another auth provider
  • Email integration through Nylas, Google API, or Microsoft Graph
  • Maps/routing API
  • LLM API for drafting and extraction
  • Audit logs for AI actions

Core v1 tables/entities:

  • Company
  • User
  • MC
  • Truck
  • Driver
  • Load
  • Broker
  • SavedSearch
  • Alert
  • EmailThread
  • Negotiation
  • Document
  • AuditLog

9. Technical architecture for a full product

A mature product may need:

  • Multi-tenant SaaS backend
  • Role-based access control
  • Chrome extension
  • Web dashboard
  • Mobile app
  • Load-board integrations
  • Broker portal integrations
  • Email/calendar integrations
  • ELD/telematics integrations
  • Accounting integrations
  • Factoring integrations
  • Document OCR pipeline
  • AI workflow engine
  • Notification system
  • Reporting warehouse
  • Customer onboarding and migration tools
  • Support/admin console
  • Security/compliance process

10. Where service-rep/vendor outreach appears

Low vendor-contact version:

  • Chrome extension
  • Email sending
  • Basic maps
  • User-side workflow helpers

Medium vendor-contact version:

  • Official DAT/Truckstop access
  • Broker portal integrations
  • Factoring checks
  • Rate data
  • Toll/routing APIs
  • Nylas or email provider approval

High vendor-contact version:

  • Full TMS replacement
  • ELD/telematics
  • Accounting
  • Factoring
  • Payments
  • Insurance/compliance tools
  • Enterprise customer security reviews

Ask directly:

Who is responsible for getting API access and vendor approval: me, you, or someone else?

Important context:

DAT and Truckstop both advertise integration/API products publicly, but that does not mean every developer can instantly self-serve production access the way they can with Stripe. Treat vendor access as a requirement to verify early, not as an implementation detail to solve later.

11. Red flags

Be careful if they say:

  • "It should be just like Numeo."
  • "We can scrape DAT and Truckstop."
  • "AI will handle negotiation automatically."
  • "We do not need a dispatcher involved."
  • "We want to replace the TMS quickly."
  • "There are no edge cases."
  • "We will figure out integrations later."
  • "We do not have time for discovery."

These are signs that the project may be under-scoped.

12. Green flags

Good signs:

  • They can show the current workflow.
  • They have dispatchers available for interviews.
  • They know which features are must-have.
  • They already have vendor/API access.
  • They are willing to start with a narrow MVP.
  • They understand that full TMS replacement is a long project.
  • They can provide test data and real examples.
  • They accept human approval for early AI features.

13. Suggested meeting agenda

  1. Ask them to demo their current software.
  2. Map the current workflow from load search to payment.
  3. Identify the top three painful steps.
  4. List all integrations they rely on.
  5. Separate "must replace" from "nice to improve."
  6. Decide whether v1 is an assistant, extension, dashboard, or TMS.
  7. Confirm who owns API/vendor access.
  8. Confirm timeline and team expectations.
  9. Confirm what failure would cost operationally.
  10. Agree on a discovery phase before fixed implementation scope.

Given your background as a full-stack developer, React/backend/AWS/OAuth/Chrome extension experience maps well to an MVP.

You can realistically own:

  • Chrome extension
  • Web dashboard
  • Auth/team accounts
  • Backend APIs
  • Email integration
  • File storage
  • AI draft/extraction features
  • Background jobs
  • Basic alerts

You should avoid personally promising, without partners or a team:

  • Full TMS replacement
  • Official load-board aggregation across many sources
  • Fully autonomous negotiation
  • Accounting-grade workflows
  • Safety/compliance workflows
  • Enterprise integrations
  • Data migration from unknown current systems

Best practical framing:

I can help discover and build a focused first version. Before estimating the full build, we need to map the current software, current workflow, integration access, and which part of Numeo they actually mean.

15. Decision checklist

Before accepting the project, make sure you know:

  • What current software is being replaced
  • Whether it is a small workflow tool or full TMS
  • Who the daily users are
  • Which integrations are required
  • Whether API access exists
  • Whether browser automation is acceptable
  • Whether AI can send messages or only draft them
  • What data migration is needed
  • What timeline they expect
  • What team/resources they will provide
  • Who owns domain decisions
  • Who will test with real dispatchers

If most answers are unknown, propose a paid discovery phase first.

Built with LogoFlowershow