How Symbiont works: from an idea to a tested product

Begin with a brief you can change deliberately

Describe the person, their current workaround and the result you want to test. In the project workspace, ordinary Send continues the discussion. Answer this question switches the composer into an explicit answer mode; Save answer commits that answer. Skip for now records an unknown. These controls let you ask for help before choosing a direction.

You can ask for two possible audiences and the reasons to choose each. Do not assume that an assistant's suggestion has become your brief. Check Project context for the saved decision. A later recommendation built on the wrong audience can be internally consistent and still solve the wrong problem.

Personal OS runs the work behind the workspace

Symbiont is the user-facing workroom. Its server checks your sign-in and forwards project reads and actions to the Personal OS box API. The factory runs inside Personal OS; the website is not a second independent product-building engine. The project conversation and Files view read the results of that shared process.

There are different reasons for waiting. The project may need your answer or approval, be doing work, be waiting for available execution capacity, or have a failed step. Read the stage and its message before resubmitting. A second project would be a separate attempt, not a repair of the first. The duration depends on the work and review required; this guide does not promise a fixed completion time.

Research should narrow the product decision

Research examines the selected audience, alternatives, offers and constraints. The product-definition stage turns that material into a named hypothesis and a bounded product scope. Read the sources behind consequential claims. A competitor page can establish a listed price; it cannot establish that your customer would switch at that price.

Suppose you choose small agencies and one deliverable: a sourced competitor brief. The product canvas should retain that audience and job, state what the pilot will test and record what would make you stop. If it suddenly describes enterprise procurement, request a correction before approving. Otherwise the design and build may inherit a different business from the one you chose.

• Research: what is supported, uncertain or contradicted?
• Product definition: what are we testing and what will we deliberately not build?
• Review: does the next output preserve the approved audience and hypothesis?

Design the job before expanding the application

Product design describes the user journey, screens, states and interactions; brand work supplies the product's visual and verbal system. Use the prototype to review how a person completes the job, including empty, loading and failed states. A clickable screen helps answer usability questions, but it does not show that data saves or permissions work.

The build brief brings product, design and brand decisions into Personal OS's coding process. Review the resulting application against that brief. For a file-approval tool, the core result is a retrievable approval of the correct file version, not simply a login and dashboard. A request for a narrower change belongs in the existing project and should name the affected output.

Read the files, then check the release separately

Files is the directory of project outputs. Use its current status and version when reviewing material. The factory contract distinguishes pending, ready, failed and outdated work; approval is tied to the outputs being reviewed. When an output changes, an earlier approval must not silently stand in for review of the new version.

QA and release checks concern the running product. Follow the core journey with an authenticated test account, confirm the result survives a reload, and check access and recovery. A file count, deployed URL or successful build is insufficient on its own. The launch-readiness guide gives the concrete checks to use before inviting users.

Make the launch a measurable experiment

Go-to-market work describes the offer, audience, messaging and acquisition test. Payments and launch concern checkout, the promised delivery and the release setup. Operations concerns keeping that product usable after launch. Public promotion and paid spend need their own authorization; discussing an ad in chat is not permission to spend money.

Decide what result you will measure before opening the pilot. For a paid product, confirm payment and fulfilment separately: payment records willingness to pay, while completed work shows the promise was delivered. Then look for repeat use. Keep the observed result in the project so the next iteration responds to evidence rather than another round of attractive but unrelated files.