New evidence deserves a decision, not an automatic feature
A pilot customer asks for team accounts halfway through a build. Sales wants the feature for a demo. Engineering says it touches permissions, invitations, billing, and tests. Calling it “one small change” hides the decision the founder must make.
Protect the first useful product loop while making room for evidence that changes it. A change process should help you decide, not make every discovery wait for a committee.
The AI MVP acceptance criteria guide explains how to define the original baseline. This guide covers what happens when a request arrives after that baseline is agreed.
First classify the request fairly
Compare the observed behavior with the approved requirement and acceptance test. If users cannot do what was agreed, record the failure as a potential defect. If they want another capability, record it as new scope. When the requirement is unclear, resolve that ambiguity jointly before assigning a price or blame.
For a hypothetical AI document product, “the approved file type cannot upload” may be a defect. “Support a new file type” may be new scope. “The output is not good enough” needs the agreed evaluation examples and criteria before either label is fair.
Somnio’s fixed-price and ownership policy separates verified defects from changed requirements. Its 30-day post-delivery correction window concerns custom code that does not function as specified; it is not unlimited feature work or protection against third-party service changes. The signed agreement controls the terms.
Use one short request record
Avoid a long specification for every idea. Capture enough information to make a decision:
| Field | What to record |
|---|---|
| Evidence | User observation, failed task, or changed requirement |
| Requested behavior | What the user must be able to do |
| Launch relevance | Why the original release cannot meet its goal without it |
| Dependencies | Data, permissions, integrations, screens, and tests affected |
| Options | Swap scope, defer, or add work |
| Impact | Estimate, uncertainty, cost, and revised dates where applicable |
| Decision | Approver, date, rationale, and revised acceptance test |
A feature request from one prospect is evidence of one prospect’s need. Ask whether it serves the intended launch audience or creates a different product. A paid pilot commitment may change that judgment, but it does not remove implementation work.
If you have no delivery lead, first list the data, roles, billing behavior, and external services the request changes. Take that list to the developer who will implement it, or commission a bounded technical assessment before committing to price or date. A new screen is not automatically small work, and an AI-generated estimate is not a delivery commitment.
Choose between three real options
Swap: Remove a lower-value item and add the requested behavior. Ask the delivery team to assess the entire trade, including work already completed. A screen removed late may save little, while new permissions can affect the whole application.
Defer: Keep the request with its evidence and a condition for reconsideration. “Revisit after pilot teams need shared access” is more useful than an undated backlog item. Tell the requester what the first release will actually support.
Add work: Approve the extra cost and timing effect explicitly. If the launch date cannot move, identify which other constraint can change. Do not treat overtime or skipped testing as the default answer.
Some changes invalidate the launch premise rather than adding a feature. If the target users cannot use the product without a different data source, pause the affected work and re-scope. Continuing toward the wrong release does not protect runway.
Work through the team-account example
Suppose the approved pilot supports individual accounts. A customer now needs a manager to review several employees’ work. This is an illustrative planning example, not a Somnio client result.
First ask whether individual access still lets the pilot test its core value. If it does, the founder may defer shared review and agree a temporary, permitted process. Do not solve it by sharing passwords or exposing another user’s records.
If shared review is essential, define the smallest version: who can invite members, who can view which records, and how access is removed. Check what happens to existing data. Then estimate that specific version, including permission tests and support implications. A “team account” label is not enough to price.
Keep the baseline and demo honest
After approval, update the scope, acceptance criteria, delivery plan, and decision log together. Tell the team which version now governs the work. Record rejected and deferred requests too, so they do not return as presumed promises during acceptance.
Review open decisions at a regular project checkpoint. Give urgent launch blockers a named escalation route. Developers should not have to choose between conflicting instructions from a founder, a salesperson, and a pilot user.
Somnio’s focused AI MVP package has a 12-week delivery target when requirements fit its scope. Integration access, data requirements, and timely buyer feedback affect that target. A new request needs an impact assessment; the published timeline is not a guarantee that expanded scope fits unchanged.
Before the next demo, take your three most important open requests and complete the record above. Decide which one changes the launch outcome. That is a useful preparation step whether you continue with your current team or discuss a scoped build with Somnio.
