Build Process

02

How We Scope A New Build

How we scope a new development build from first conversation to approved plan.

Here the diagram flow with all the steps.

Step 1: Discovery

Who: The AI Strategist
Purpose: Align on the business problem and why it matters.
Do: Confirm the outcome, who uses it, when they use it, and what breaks today. Pick a rough solution form (app, workflow, agent).
Output: Problem, Business outcome, Rough solution direction
Done when: Everyone can say the problem in one sentence and agree it ties to a measurable outcome.

In this first step of the process, the client won't have a clear solution in mind.
The goal of the discovery is to align on:

  • ●Problem
  • ●Business outcome
  • ●Rough solution direction

And to identify the biggest unknowns.

a) What problem we are solving

The more vague the understanding of our problem, the more likely the pain we'll have to suffer down the line (longer times to deliver final version of the tool, lower client satisfaction, lower margins on the specific project)

  • ●The Request: "Sales performance dashboard."
  • ●The Shaped Problem: "Sales reps are missing 20% of follow-ups because they can't see who to call next. The client needs a view that ranks leads by 'last contacted' date."

B) Rough Solution

At this point, it's unlikely the client will have a clear vision of what the solution should be. Our role will consist in guiding them through what's possible.
The aim is to walk away from the meeting with the form and a general idea of what the solution will be:

“We will build a [workflow / dashboard-report / app / assistant /agent] for [primary user] so they can go from [start situation] to [done result] by [2 to 3 key moves].”

Step 2: Output Definition

Who: The AI Strategist + Client
Purpose: Make the target output real and testable.
Do: Collect examples or build the “ideal output” together manually. If the output is fuzzy, use a quick wireframe to confirm what the output should look like.
Output: Ideal Output docs (criteria, examples, files) + Notes on prototype (if built) + Open Questions
Done when: We have specific criteria, examples or outputs we can use as a reference to judge success (and the client agrees it’s the target).

In this step the Strategist will work with the client to collect specific examples, outputs or answers that will help us form a better idea of what the solution will be.

To set a clear direction, we might also draft a prototype or a proposed solution that could help us collect early feedback before starting the build.

A question that could help at this stage:

“If this worked perfectly, what would you be able to do in one sitting that you can’t do today? Walk me through it like a short story: where you start, what you click or type, what it pulls from, and what you get at the end.”

This is important: our client won't do this by default. It's unlikely they will give us the details of what they actually want. They will be vague, because the solution they have in mind is still not formed. It's our job to ask them to refine it, to link their goals to their problem and think what they would want our tool to do for them.

Step 3: Shaping

Who: The AI Strategist
Purpose: Turn the approved output into a bounded build.
Do: Define key features, acceptance criteria, non-goals and data needs
Output: key info inside the scoping doc
Done when: the scoping doc clearly defines the output, required inputs, and boundaries (non-goals, size, validation rules) enough for the Solution Engineer to review and turn it into phased work without guessing.

Before starting any build, we should have a clear understanding of all the below.

a) What solution we will build

At this point the solution should be more defined. Details to collect include:

  • ●Form: app, workflow, assistant, dashboard, agent (should come from discovery process)
  • ●Core Flow: 1) User starts by… 2) Tool does… 3) User gets…
  • ●Key Features: Ex.
    • ●In-dashboard conversational assistant that accepts text and voice input, maps each query to an intent, pulls required CRM and booking data, and returns a response within 2 to 5 seconds.
    • ●Pattern analysis that computes outreach and conversion performance by channel, timing, account type, and campaign, and returns exact findings like percentage lift, best days, and benchmarks.
    • ●Cross-sell identification that scans booking history across sister properties, matches accounts by company and contact, and outputs a ranked list of specific accounts and properties to target next.
    • ●Proactive account recommendations that detect inactive accounts based on last-touch rules, score accounts by booking likelihood using historical data, and preserve conversation context across follow-up questions.
  • ●Example Use Cases:* ex. “Analyze patterns in my prospecting and help me increase my conversion ratio.” or “Show me accounts in my database that haven’t been touched in 60 days.”

b) What good looks like from a client perspective (acceptance criteria)

Each must be measurable and reference a source of truth or ideal output doc (from Step 2).

Avoid vague words like “accurate”, “clean”, “fast”. If client provides vague criteria, we should challenge for more specificity.

c) What we won't do (non-goals)

Non-goals are goals someone with limited knowledge might think we want to achieve with the solution but we do not.
They will help clarify scope with devs.

Here we should:

a) List explicit areas we do not plan to address
b) Explain why they are not goals

These are as important and clarifying as the goals

ex. Some non-goals for Proper's prospecting dashboard

  • ●Forecasting number of bookings per seller for coming months
  • ●Compare hotel performance with competitors

d) Where the data comes from (inputs)

Is it their CRM? Is it email? Is it sales calls? Is it X? Reddit? Websites behind paywall?

Knowing where the data will come from will make a difference in understanding how much time and money the build will require.

For each data source we should collect information on how to retrieve it and credentials (if access need to be provided by client)

If any of the above points aren't clear, we should go back and collect more information.
If even just one of the points is vague, it will likely to cause some damage in the later stages of the process. And we don't want that.
Do we need more info from the client? Do we need access to specific docs or data sources? Let's do it now!

All points are clear?
We sure?

Alright. Let's proceed.

Step 4: Review

Who: The Solution Engineer
Purpose: Feasibility check and risk surfacing before planning.
Do: Verify inputs/access, confirm the output is buildable, add questions/risks. Stop if anything is unclear.
Output: “Reviewed scoping doc with questions + risks.”
Done when: Unknowns are either resolved or explicitly called out as risks with a mitigation.

When planning out a new build, we should ALWAYS take into consideration an initial, short buffer period BEFORE we go back to the client explaining next steps.
This is where we will collect more info about what we'll be able to show to the client at the end of each phase (2 cycles) or cycle ( 2 weeks).

Before we plan out the full build, the Solution Engineer should validate the provided information:

  • ●Data: Are all data inputs clear? Do we access? Is the CSV export format correct?
  • ●Outputs: Are the solution requirements understood?
  • ●Validation rules: Are the validation rules clear?
  • ●Non-goals: Do we have any doubts on what the build SHOULD NOT do?
  • ●Risks: Identify the risks. "Reddit API might rate limit us." "The CRM data is messy."

If the data source or the outputs aren't clear, the project stops here. We don't start building until these are confirmed.

The output of this process will be a Reviewed Scoping Doc with added, questions and risks added to relevant areas of the original Doc.

Step 5: Plan and Estimates

Who: The Solution Engineer
Purpose: Convert scope into phases and estimated deliverables
Output: Phase breakdown + estimates.

1 Phase = 2 cycles

Each new build shouldn’t be more than 3 Phases (6 cycles). If the estimate turns out to be longer than 3 Phases, then it should be broken down into a smaller scope.

Phase = a client-visible output that delivers a “real thing” we can show, and that creates momentum
cycle = the team’s build cadence inside a phase (bi-weekly cycles with bi-weekly progress calls).
Issue = a Linear task small enough to finish inside a cycle and tied to a phase deliverable.

Phases do 3 jobs:

  1. Expectation control for longer builds (client sees what lands first, second, third).
  2. Offer modularity so we can more easily break down larger builds into scopes that fit contract length and requirements

For large builds, estimate each phase by doing this: create a short list of the big chunks needed for the full build (5–10 max), then estimate how many cycles each chunk would reasonably take.

At this stage, it's unlikely we will create all issues and estimate them properly. So the focus should go on defining boundaries and deliverables per phase and planning out cycles and issues for the first phase.

We will then build out next phases in detail as we get closer to the end of Phase 1.

Cycles, and specific issues will be tracked in Linear since they do not belong to the Scoping Doc.

In Linear, every issue should have Estimate Points (definitions present in the section below) and Due Date.


When defining Estimate Points and Due Date we should consider a buffer that takes into account potential blockers, risks, and eventual need for feedback from the client.

Step 6: Alignment

Who: The Solution Engineer, AI Strategist, Lead Dev
Purpose: Internal alignment, then client-facing confirmation.
Do: Alignment call (team), then client kickoff brief that mirrors the shaped scope and phases.

All key parties will discuss open questions and clarify last points before starting the build.
The Reviewed Scoping Doc will be our reference moving forward.

Step 7: Communication (AI Strategist)

Who: The AI Strategist
Purpose: Manage expectations with the client + provide clarity on build + ask final approval to guarantee alignment
Output: Approved Scope

Once info has been collected, Scoping Doc reviewed and we are all aligned on the build, we can proceed updating the client.
Given we'll now have estimated deliverables per phase, this step might also involve back-and-forth with the client to find alignment on what portion of the larger build we should focus on for Phase 1.

At this stage, the communication shouldn't be a scientific paper, but it shouldn't even be a 2 lines text.
We can use this moment to let the client into the complexity and nuance of what we're building.

When communicating to the client for the official build kick-off we should provide the same info we collected during our Shaping phase:

  • ●Problem the client wants solved
  • ●Description of what the tool should be (solution with key features)
  • ●Inputs (Data dependencies)
  • ●What good looks like from a client perspective (validation rules)
  • ●How the build will be broken down (phases with estimates, no details by cycle)

This will help us manage expectations with the client but it will also be a source of truth the client will sign on.
Functionality that will not be included in this communication will be considered as extra, and not as part of the original scope.