# From prototype to team use

Pretectal · https://pretectal.com/workflows/prototype-to-team-tool
Updated October 2, 2026

Use this record to plan a limited trial and give the next owner enough context to operate the tool. A completed record describes work performed; the responsible owner decides whether to release or expand the tool.

Tool:
Builder:
Trial owner:
Version / location:
Review date:

## 1. Define the trial

- Task the tool supports:
- Participants and their agreed roles:
- Start and review dates:
- What is included in this trial:
- What is outside the trial:
- Existing way to finish the task:
- Observable useful result:
- Information needed for comparison:
- Baseline observation, task conditions, and collection method:
- If no baseline exists, what can this trial establish instead?

| Question to answer | Observation or measure | Who records it | When reviewed |
| --- | --- | --- | --- |
| | | | |

Checkpoint: the owner and participants understand the scope and how the trial will be evaluated.

## 2. Set data and access boundaries

Use sample records while unresolved decisions are being reviewed. Do not put passwords, API keys, or private records in this document.

| Data received | Why needed | Stored or sent where | Who can access or change it | Removal process | Owner decision |
| --- | --- | --- | --- | --- | --- |
| | | | | | |

- External services or models used by the actual implementation:
- Actions that require a person's confirmation:
- Access roles and permissions:
- Organizational requirements confirmed by:
- Real-data use agreed by and on:
- Unresolved decisions and their owners:

Checkpoint: the implemented data flow and permissions match the owner's agreed use.

## 3. Test the released experience

- Exact tested version:
- Where users will open the tool:
- Known working version to return to:
- Existing process or fallback if unavailable:
- How work can be recovered:

| Test case | Expected result | Observed result | Pass / open issue | Owner |
| --- | --- | --- | --- | --- |
| Complete the core task | | | | |
| Leave a required input empty | | | | |
| Try an unauthorized action | | | | |
| Submit an action twice | | | | |
| Lose the connection or encounter a service failure | | | | |
| Recover or correct incomplete work | | | | |
| Complete the task with a keyboard | | | | |
| Complete the task on a smaller screen | | | | |

### Only if the product has an AI feature

Using AI to build a product does not mean the product uses AI at runtime. Mark this section not applicable when it does not.

- Model-dependent task:
- Representative inputs and expected qualities:
- Unacceptable outputs:
- What the person can inspect, correct, or reject:
- Behavior when the model fails or produces an unusable answer:
- Limits explained to users:
- Evaluation performed and results:

Checkpoint: material failures have been resolved for the agreed trial, and the tested version matches the version being shared.

## 4. Observe the team trial

- How participants learn the core task:
- How they report issues:
- Where authorized feedback is recorded:

| Date / version | Task attempted | Completion and corrections | Confusion or support required | Work still done elsewhere |
| --- | --- | --- | --- | --- |
| | | | | |

### Results and interpretation

- What was directly observed:
- Feedback or preferences people expressed:
- Any measured change, with sample size and task conditions:
- What cannot be concluded from this trial:
- Most important change to make:
- What can wait:
- Reason to stop the trial, if present:

Checkpoint: distinguish observed task performance from hopes, opinions, and wider adoption claims.

## 5. Hand over and decide

### Run and maintain

- Source location:
- Setup and run instructions:
- Hosting or delivery location:
- Account owners (references only; no credentials):
- Dependencies and update responsibilities:
- Ordinary use instructions:
- Common issues and recovery steps:
- Support contact and response expectations:
- Where AI instructions, reusable skills, and examples are maintained:
- Next review date or trigger:

### Try the handoff

- Person who tried the instructions:
- Date and version:
- Task they completed:
- Recovery step they tried:
- Questions or missing steps corrected:

### Release decision

- Decision: expand / revise / continue limited trial / retire
- Evidence supporting the decision:
- Remaining limits:
- Responsible owner and decision date:
- Next action, owner, and date:

Final checks:

- [ ] Scope and participants are agreed.
- [ ] Data use and access have been checked with the responsible owner.
- [ ] Test results identify the actual delivered version.
- [ ] Recovery instructions and a usable fallback are included.
- [ ] Trial observations and unresolved issues are preserved.
- [ ] Another owner has tried the instructions.
- [ ] Support, maintenance, and the next decision have an owner.

## Starting prompt

Help me plan a limited team trial for the prototype described below. Draft the task and participants, observable success criteria, baseline information still needed, data and access questions, test cases with expected results, a recovery path, a feedback log, and a handoff outline. Separate confirmed facts from open decisions. Include model-output evaluation only if an AI feature is part of the tool. Do not infer permission to use real data, claim measured savings, or mark the tool ready for release. End with the decisions the responsible owner must make.

Prototype, verified behavior, and team constraints:
