How We Scope a Bounded Software Pilot Before Asking for Production Data
Published August 2026 by Solarc Labs
Start with one expensive mistake, not a platform vision
A pilot becomes hard to evaluate when it begins with a broad promise such as automate operations or improve compliance. We start by naming one observable job: detect a failed customer journey, preflight one evidence corpus, review one access dataset, or process one bounded document flow. The narrower job gives both sides something concrete to inspect. It also prevents adjacent capabilities from being treated as included simply because they might exist in a future product.
Define the data path before real material arrives
Before production or sensitive data is introduced, the pilot should state what inputs are supported, where those inputs are processed, which people or systems can access them, what is retained and what is intentionally outside scope. This turns privacy and security from generic policy language into an operating boundary. If the data path cannot be described clearly enough for the buyer to understand, the pilot is not ready for the buyer to rely on it.
Acceptance criteria need observable states
Good acceptance criteria describe states the workflow can actually produce and verify. For example: a representative file either passes a defined preflight or returns a bounded blocker; a monitored journey either reaches its expected state or records a failure transition; a document extraction reaches ready_for_review but does not become automatically approved. We avoid acceptance criteria built from unsupported business outcomes such as guaranteed savings, universal accuracy or compliance. Those may become measurable later, but they are not substitutes for a verifiable first release boundary.
Write stop conditions as carefully as success conditions
A bounded pilot should say what causes the workflow to stop, escalate or return no-fit. Unsupported file types, unclear authority, missing source evidence, a security requirement outside the current deployment or a buyer need that exceeds the product boundary are all legitimate stop conditions. This protects both the product and the buyer. A no-fit result is better than silently stretching a small tool until it becomes an untested system of record.
Expand only after the first scope earns it
The first pilot is evidence for the next scope decision. If the workflow proves useful, the next iteration can widen inputs, automate a narrower class of decisions or integrate another system. If it does not, the bounded design makes the reason easier to see. That is the practical reason Solarc prefers small, explicit pilots: the first release should create information about whether expansion is justified, not commit both sides to a platform before the first job works.
Continue the job