Build, Buy, or Fix the Process First?

When a client asks for extra work, agreeing on a price is only part of the job. Someone also needs to update the project record so the people doing the work know what has been agreed.

For example, a consulting firm might agree to add two workshops to a client project. The account lead and client settle on a higher fee and sign a revised agreement. Later, the project manager opens the firm's project software to plan the work and finds the old amount. Before assigning staff to the workshops, they have to find the agreement and check with the account lead that the extra work is approved.

This is a change in project scope: the work the firm has agreed to deliver. The team has recorded the agreement in one place, but the people planning the project need it reflected in another. If this happens regularly, the firm has a clear reason to improve how it tracks those changes.

The fix could involve assigning responsibility for the update, using a feature in the existing software, or connecting the signing service to the project system. Buying a product or building a missing capability could also make sense. These choices can work together.

We favor the approach that meets the firm's needs and leaves the team with the least work to manage afterward. That means considering both the software and the time people will spend keeping records current, resolving problems, and maintaining the system.

Find the requirement that changes the choice

For this firm, a useful solution would put the revised amount and a link to the signed agreement against the correct project. It would also make any missing update visible, so staff could resolve it before it caused confusion.

The project managers already rely on the project system for budgets and delivery plans. Their project budgets record the agreed fees as well as the costs of doing the work. Keeping that information there lets them continue working in the same place. It makes the project system the authoritative record: the place everyone should check for the current budget. Any proposed solution must keep that record up to date.

That one decision can disqualify an otherwise impressive product. A tool might have an excellent approval screen and an AI summary of every agreement, yet require an employee to copy approved amounts into the project system. If eliminating that transfer is essential, the tool needs a suitable connection before it qualifies.

Be equally specific about other requirements. “Good permissions” is difficult to compare. “A project manager can see changes for their projects without seeing another client's commercial terms” gives you something a vendor or developer can answer. “Integration available” is vague; creating a project record and updating its budget are different operations, and a connector may support only one.

Before comparing options, write down the requirements that could rule one out:

• The record people rely on. Where must the final status, amount, owner, and supporting agreement live?
• The exact update. Which fields must change, and can the proposed connection perform that operation?
• Access boundaries. Who can read, change, and approve each part of the record?
• Incomplete work. How will the team identify an approved change that hasn't reached the project system?
• Evidence afterward. What must be retained to establish which agreement caused a budget change?
• Daily use. Can staff do the work from a queue or screen they can reasonably manage?

Keep preferences separate. A familiar interface might be worth paying for, but it has a different role in the decision from preventing one client's data from appearing to another team. A single failed essential requirement can outweigh a long list of attractive features.

A good answer about a document still needs a current record

The signed agreement creates a tempting shortcut. If AI can read every project document, perhaps people could ask it for the current budget whenever they need it.

That would help with questions such as which additional deliverables the client agreed to, or where the revised fee appears. A document assistant can retrieve relevant passages and use them to prepare an answer. This approach is commonly called retrieval-augmented generation, or RAG. Microsoft's explanation of retrieval-augmented generation describes how retrieved information provides context for a model's response.

But the operational question also involves events outside the text. Was this version signed? Does it supersede an earlier change? Has the revised amount reached the budget? Has somebody cancelled the change since the document was stored?

Those facts need explicit records and update rules. Microsoft's guidance on grounding data describes a search index as a copy designed for retrieval, while the original system continues its primary job. Our practical conclusion is that finding the agreement and recording its effect should remain distinguishable responsibilities, even when one application provides both.

For this firm, the document assistant could explain the signed change and link to its source. The project record would establish the current budget and whether the update completed. An assistant answering a current-status question could consult that live record, provided it has an appropriate connection and permissions. Putting documents into a searchable library alone doesn't establish that connection.

This distinction helps keep a useful knowledge project from quietly becoming an unreliable tracking system. It also narrows what you might need to buy or build. The missing capability may be a dependable update to an existing record, rather than a new AI workspace.

Combine the pieces around the work that remains

Some of the scope-change problem may disappear with a small process repair. Perhaps staff send signed changes to two different administrators, both of whom assume the other updates the project. Assigning that update to one role removes the ambiguity. If someone maintains a separate budget spreadsheet merely to prepare a weekly email, replacing the email with the existing project report may remove a whole reconciliation step.

Make those repairs as part of the implementation. There's no need to turn a selected workflow into a prolonged redesign exercise. Once responsibilities are clear and redundant work is removed, examine the transfer that remains.

Configuration is worth checking next because the necessary capability may already exist. The project application might support a change register, attachments, approval states, and rules for updating a budget. Its current configuration could be the limitation. Using those features would keep the workflow close to where project managers already work.

An existing subscription doesn't guarantee that every connection is included. For example, Microsoft's Power Automate licensing documentation distinguishes standard connectors from premium and custom connectors, with different entitlements for different uses. Verify the particular workflow and account arrangement before putting zero incremental software cost into a comparison.

Buying a specialist product makes sense when it supplies a substantial missing capability well: perhaps an external approval experience, a change register that staff find easy to use, or document handling that the owned application cannot support. Its value depends on how much useful work it removes after installation. A second well-designed screen can still create another place to keep current.

The options can be collected into a short guide:

Repair the process. A good reason to use it: Conflicting responsibilities or redundant steps cause the problem. What can make it insufficient or unsuitable?: Necessary repetitive work remains after the repair

Configure owned software. A good reason to use it: Existing features can support the required record and actions. What can make it insufficient or unsuitable?: A required operation, permission, or user experience is missing

Buy a product. A good reason to use it: A specialist product handles a substantial part of the job well. What can make it insufficient or unsuitable?: It leaves essential work in another system unresolved

Connect products. A good reason to use it: Suitable applications exist, but information must move between them. What can make it insufficient or unsuitable?: Their available connections cannot perform the required updates reliably

Build the missing part. A good reason to use it: An important requirement survives the other options. What can make it insufficient or unsuitable?: The firm cannot fund or obtain the ongoing capability to maintain it

Look closely at what happens between applications

For the hypothetical firm, connecting the signing service to the project application looks promising. It can retain both familiar products and remove the manual transfer.

Follow one approved change through that connection. The signed file is saved, the project budget is updated, and the change is marked complete. If the file saves but the budget update fails, somebody needs to see the incomplete work. If the connection tries again, it must recognize the same change rather than add the amount a second time.

These details influence the implementation choice. One integration product may already support the required identification, retry behavior, and failure queue. Another may need a custom step. A cheap connection that requires an administrator to compare two reports every morning has transferred work back to the firm.

It's reasonable to ask why this takes more thought than updating fields on one screen. Within a database, developers can group related changes into a transaction, so they succeed together or are cancelled together. PostgreSQL's introduction to transactions explains that behavior. Updates across separate products need their own coordination; connecting them doesn't automatically give the whole sequence the same guarantee.

Usage charges also follow the work performed. Under Zapier's task-accounting rules, successful ordinary action steps consume tasks. One change passing through several actions can therefore use several tasks. Products and action types can have different billing rules, so count the designed workflow before choosing a plan.

An integration proposal should make the remaining operational work visible. Who sees failed updates, how much reconciliation remains, and which product supplies that view? You can then compare a standard connector with a custom connection on the actual job each would leave behind.

Build only the capability that earns its place

A custom connection could be justified if the project system exposes the required update through an API, a software interface, but the available integration products don't support it. A developer might build that connection while retaining the signing service, document storage, and project screen.

Custom work can also reduce the number of awkward steps people manage. If staff must repeatedly move between several applications to resolve one change, a small shared screen could be less burdensome than elaborate configuration across all of them. That possibility deserves a fair comparison, especially for work that occurs frequently.

The build still depends on the systems around it. If the project application provides no supported way to update a budget, custom code doesn't create permission or a dependable interface by itself. The firm may need a different application, an accepted manual step, or a separately assessed approach to controlling the existing screen. Owning code won't remove that constraint.

Be precise about which requirement justifies the custom component. “Our business is different” gives a developer little guidance. “The approved change must update these budget fields together, and the available connectors can't do it” defines a useful engineering problem.

The appropriate amount of product engineering might be that single missing connection. It could also be a larger application if the required experience and rules cannot be supported sensibly by existing products. The size should follow the unresolved work.

Compare the cost of operating qualifying designs

Once two designs meet the essential requirements, compare what the firm would spend and do over time. Keep disqualified options outside the cost ranking. A standalone product that never updates the project budget doesn't become the best solution because its subscription is inexpensive.

The worksheet below compares two hypothetical implementations of scope-change tracking. Every amount is an illustrative assumption in US dollars, including software allowances; none is a vendor quote or a Foregrounds project result. Both preserve the project system as the authoritative record and handle incomplete updates. In the first, staff resolve those updates using information from both products. The second includes a custom connection that gathers incomplete changes and their supporting details into one working queue in the project application. We assume that this reduces residual administration; the hours below illustrate the difference, rather than report a measured result.

Initial design, setup, and implementation. Connected standard products: $8,000. Custom connection with owned application: $20,000

Annual software and usage allowance. Connected standard products: $2,400. Custom connection with owned application: $1,200

Annual maintenance and support. Connected standard products: $3,000. Custom connection with owned application: $4,800

Annual residual administration at $50/hour. Connected standard products: $3,000: 5 hours/month. Custom connection with owned application: $600: 1 hour/month

First-year modeled cost. Connected standard products: $16,400. Custom connection with owned application: $26,600

Three-year modeled cost. Connected standard products: $33,200. Custom connection with owned application: $39,800

The calculation is setup plus the number of years multiplied by annual software, support, and administration. The administration line covers operating the tracking workflow, including exceptions and reconciliation. Commercial negotiation and approval of the change remain outside this comparison because neither design replaces that work.

Under these assumptions, we'd choose the standard connected products. They meet the requirements and cost $6,600 less over three years, with $12,000 less needed for initial implementation. The custom option leaves four fewer administrative hours each month and gives staff one place to resolve incomplete changes. Its higher modeled cost already credits that time reduction at $50 an hour. Paying the remaining premium would require a reason to value the easier daily operation beyond that allowance.

For your worksheet, include internal setup time as well as supplier fees. Add any required license upgrades, document or AI usage, staff training, and the work of investigating failures. Avoid counting the same work under both administration and support. This example holds rates flat and excludes tax, financing, inflation, and exit costs; add relevant amounts before using it for a budget decision. If exit cost is unknown, leave it marked unknown rather than silently treating it as zero.

Changes in the workload or support arrangement can alter that choice:

• Volume: If the workload doubles with the same mix of cases and handling time, the administration component doubles. That adds $9,000 to the first design's three-year cost and $1,800 to the second's. Software and usage allowances also need checking at the new volume.
• Exceptions: If more difficult cases add three hours of administration each month to the first design, its three-year cost rises by $5,400. An attractive automation rate can coexist with expensive remaining work.
• Maintenance: Doubling the second design's maintenance allowance adds $14,400 over three years. Confidence in the maintenance estimate matters as much as confidence in the initial build quote.

In the doubled-volume scenario, those administration changes put the standard design at $42,200 over three years and the custom design at $41,600, before repricing software usage. Custom now appears $600 cheaper, but that narrow difference could disappear with a small change in usage or support costs. On this evidence alone, we'd keep the lower-upfront-cost standard design as the preference. Custom becomes more compelling if its simpler daily operation is itself worth paying for, or if firmer cost estimates establish a meaningful advantage.

These are choices within an illustrative model, not predictions of business performance. Valuing staff time helps compare demands on the team; releasing those hours doesn't necessarily reduce payroll.

For the scope-change workflow, begin the next comparison with one real approved change and the project record it should update. Map which existing component can perform each required action, then mark any gap that needs a purchase, connection, or custom work. Price the two feasible combinations, including the work left with your team. You'll have a decision about the system your firm would operate, with a specific reason for every part you add.