Architecture Decision Sprint

Illustrative example / No client data

Fieldline Ops

Architecture Decision
Sprint

Fictional field-service platform

Web + mobile + partner APIs + AI

Decision window: five working days

Own the workflow spine. Buy the commodity edges. Keep AI advisory.

Fieldline should build a narrow scheduling and job-state core, integrate proven identity and messaging services, and keep AI recommendations behind an explicit dispatcher decision until enough operating evidence exists.

Build nowJob state and scheduling rules
BuyIdentity, messaging, and maps
DeferAutonomous dispatch and route optimization

One workflow with explicit state ownership

01Dispatch deskHuman decision
02Workflow coreJob state + rules
03Partner adapterExternal APIs
04Technician appField execution
05Evidence logOutcome + exceptions

Primary constraint: job state must remain authoritative inside the product. Partner systems can propose or report changes, but cannot silently become a second source of truth.

Four decisions make the first release buildable.

D-01 / Boundary

Start with a modular monolith and one durable job queue

WhyThe team is small and the core workflow is still changing. Independent services would create deployment and debugging costs before ownership boundaries are proven.

TradeoffModule boundaries must be enforced in code and data access, even though deployment remains shared.

Trigger to revisitSplit only when one module has a distinct scaling, availability, or ownership need supported by production evidence.

D-02 / State

The product owns job state and transition rules

WhyCRM and partner APIs model partial views of the workflow and cannot represent Fieldline-specific exceptions reliably.

TradeoffAdapters must translate external events and tolerate delayed or duplicated delivery.

Rejected pathUsing the CRM as the operational database would make critical behavior depend on vendor-specific fields and webhook timing.

D-03 / AI boundary

AI recommends. A dispatcher commits.

WhyThe first release lacks enough labeled outcomes to evaluate autonomous assignment safely.

TradeoffThe product captures recommendation, human override, reason, and eventual outcome as training evidence.

Validation gateAutomation can expand only after accuracy, override rate, and exception cost are measured by job type.

D-04 / Integration

Every partner call is an explicit workflow step

WhyPartner APIs have different retry, timeout, and consistency behavior.

TradeoffThe adapter layer adds structure but keeps vendor failures from leaking into the domain model.

Required evidenceCorrelation ID, request state, retry policy, and operator-visible failure reason for each external action.

Thirty days, in order.

  1. Days 1-3Prove the riskiest contracts

    Spike the two partner APIs, document failure behavior, and validate the technician sync constraint.

  2. Week 1Ship the job-state core

    Implement the state machine, permissions, audit trail, and concurrency tests before UI breadth.

  3. Week 2Connect one thin path

    Run one job from dispatcher creation through technician completion and evidence capture.

  4. Weeks 3-4Add exceptions and signals

    Handle retries, offline work, partner delays, overrides, and the smallest useful operational dashboard.

Want this level of clarity
before the build?

Send me the decision