Project Brief

Use 6 local note fields to sketch a software idea. The sample fields give simple starting prompts.

This new tool runs in your browser. It does not save or send your notes by itself.

These tools do not save or send brief notes to a server by themselves.

Example project notes

This example plan describes a camera preview app for a person reviewing live video, with the browser chosen as the platform. Features, Data and Success are left blank here, so you can fill them in with your own needs as they become clear. Please remember this is only an example plan, not a description of company work or of an actual running camera app.

Goal: A camera preview app.
Users: A person reviewing live video.
Platform: A browser.

Example project brief .txt output

This example preserves all six field labels with three empty values. The reader can hand their own filled brief to a developer.

Project Brief

Goal
A camera preview app.

Users
A person reviewing live video.

Platform
A browser.

Features


Data


Success

Open the example .txt

How to plan a software idea

This guide explains how to use the notes page. The tool keeps notes on the page for you. It never uploads or saves them automatically. You can download your actual notes as a TXT file. This writing space never opens cameras.

The main goal and users

The Goal field says what your app does. Keep it short. For a camera plan, write: 'Display live video in a browser.'

The Users field says who uses the app. Focus on their needs. Write: 'A person reviewing live video.' That sets your audience.

The platform and camera access

The Platform field says where the app runs. Pick the environment early. For a camera example, write: 'A browser.' Browsers are the standard web platform.

Public camera websites must use HTTPS. Localhost is also a trusted context, per MDN. Plan for permission denial or an undecided request. This notes tool itself never opens cameras.

Features and data storage

Features are user actions. Distinguish preview from recording. Showing a live feed is a preview feature. Saving a file is a recording feature. MediaRecorder handles that separate recording choice.

The Data field lists what the app stores. Decide what stays. A preview app might store nothing. If recording, list the file type saved locally. Be precise.

Defining success and clearing fields

Success means the project works for the user. Define clear results. For a camera plan, success is: 'The user sees the live video feed.'

The Clear button empties the current values in the six note fields. The fields stay on the page. It does not delete files you already downloaded.

Camera request decisions

A hypothetical camera preview app requests video without microphone. It uses navigator.mediaDevices.getUserMedia({video:true,audio:false}) to obtain a MediaStream. HTTPS remains essential for public deployment. Localhost serves as a trusted development environment. Users and features determine whether microphone audio becomes necessary.

A denied request triggers NotAllowedError. Show a clear permission error. A missing camera triggers NotFoundError. Show a device unavailable message. An ignored request may remain pending. Show a waiting state during that period.

Add a Stop button. Clicking it calls MediaStream.getTracks(), which lists this app’s tracks, then MediaStreamTrack.stop() on each to end them. A physical camera can still remain active for another track. Note: this notes page itself never opens the camera.

Choosing platform and features

A camera-based project can run on different platforms. The Apple App Store lists Daisy STS, developed by Blaster Digital, LLC, for iPhone and iPad. Apple's description says it works with a target system camera that sends shot data to a phone or tablet, with the physical target system sold separately.

In your brief, write native phone/tablet versus browser in Platform, and note whether extra hardware is needed in Features.