From idea to launch: 5 project checks

1. Scope: what should the first version do?

Consider a fictional quote calculator for estimating your own costs. Enter a quantity, unit price and delivery charge, then display the total. The first version does not store client information or take payments.

Put that in the brief and add an example with a known answer: quantity 10, unit price 12 and delivery 8 should give 128. Both you and the AI can use it to check the calculation.

If you plan to add accounts, orders or payments, list their requirements separately and choose versions around the skills and time available.

2. Operation: can someone finish the task?

Follow the steps as a first-time user: open the page, fill in the fields, calculate, find the result, then change an input and calculate again. Check where the units, amounts and instructions appear.

Try the page on a phone. Does the keyboard cover the button? Is the result hard to find? Record the steps and inputs so you can repeat them after changes.

3. Errors: does the user know how to continue?

Try incorrect inputs: an empty quantity, a negative unit price or a fractional quantity. A message should identify what needs changing and let the user continue after correcting it.

If the project calls an outside service, try a failure or timeout. Does the page keep loading indefinitely? Can the user retry? Could the retry create duplicate records? Add checks for the features you actually have; a static calculator does not need an unused backend.

4. Data: what is stored, and who can see it?

Confirm whether input stays in the current browser or is sent to a server or third-party service. If business material is stored, define who can view or change it and try the rules with different accounts.

Hiding content in the interface is only part of the work: the server must check access to the data too. The fictional client-record example separates checking your own record from trying to read another account's record.

5. Publishing: does the online version still work?

Choose hosting that fits the project and record the build, publish and start steps. At the final address, check HTTPS, the phone layout, important links and page refreshes. Repeat the original input example. If there is a backend, check production settings, reading and writing data, and where to find errors.

Keep a working version before publishing and know how to restore it. If changes involve business data, retain a suitable backup and confirm how the data will be handled if the code is rolled back.

Keep the checks with the project

Save the requirements, a working version, test inputs, usage instructions and current unresolved questions. After launch, ask intended users to try it and record where they stop. Prioritise changes by impact and update the examples when you add a feature.

Download the full checklist. If you are still defining the first step, use the task brief template to set the goal and scope.

Questions

Can I start checking before every feature is ready?

Yes. Each time a small part can be operated, try it with known inputs. A problem is then easier to connect to recent changes, and you can keep a working version.

Do I need version records for a project I work on alone?

Keep a recoverable record. You can use Git or the version feature in your tool, and should try restoring an earlier version yourself.

What should I do after publishing?

Complete the main task again at the published address. Ask someone who intends to use it to try it, record difficulties and errors, and prioritise changes by their impact.

From idea to launch: five things to check