From idea to tool

The five stages: idea, concept, build, test, deployment

Everything this site describes was built the same way. An everyday irritant becomes an idea, the idea becomes a concept, the concept is built with Claude, goes through the test stage, then is put into service and maintained. Skipping a stage always costs more than doing it.

The five stages

1. Idea: the problem in one sentence

  • Write down the problem, not the solution: “every absence triggers a chain of emails and rooms are left empty”.
  • Check that it recurs: at least once a week, or the same instruction given three times.
  • Pick one first need; the others will wait.

Warning sign: wanting to automate everything at once. Start with what wastes the most time.

2. Concept: what the tool will be

  • Choose the form: a skill (know-how that Claude applies), an artifact (a page you consult), a routine (a scheduled task), a project (a workspace per hat), or an online tool (for people who do not use Claude).
  • Define the inputs, the output and the deliverable: what the tool reads, what it produces, where it stores it.
  • Write the safeguards before the first line: what it will never do without your approval.
  • List the open questions and settle them before building.

Warning sign: a specification that only one person understands. Have Claude review it: “what is ambiguous?”.

3. Build: what you ask Claude for

  • A minimal first version, then small successive requests.
  • Every delivery numbered (v1, v2…), the previous one archived.
  • Real data never embedded in anything that will be shared.

Warning sign: fixing ten things in a single request. One request, one change, one test.

4. Test: proving that it works

  • Test on a real case, then on an edge case (missing data, unknown name, unusual action).
  • Have Claude check what a human no longer re-reads: discrepancies between two sources, names, identifiers, links.
  • Fix nothing without approval: the test stage produces a list, not changes.

Warning sign: a test that passes on your computer proves nothing for your colleagues’ computers.

5. Deployment: deliver, publish, keep it going

  • Always deliver the same thing, in the same place, under the same name.
  • Write the publication procedure for someone who has never done it, including what they should see at the end.
  • Announce it to users with an email drafted in the conversation and sent by you.
  • Compress the discussion into a skill: difficulties already solved should not have to be learned again.

Warning sign: a tool with no owner and no procedure dies at the first failure.

The five stages, depending on what you build

Skill Artifact Routine Project Online tool
Idea An instruction given three times A question asked every day A check done every day Mixed-up conversations Colleagues who do not have Claude
Concept Name, triggers, steps, deliverable, safeguards, hand-offs One question per page; data in a database, not in the page A run plan written in a file; budget One hat per project; reference documents; boundaries Specification, tabs, architecture, access rights
Build Ask Claude to write the skill from the conversation Publish the page, then connect it to a database Create the task that reads the plan Create the project, add instructions and documents Build it version by version
Test Test it on three real requests Check on a phone and with several users Review the log of the first runs Check that a question goes to the right project Triple test, double check
Deployment Add it to the skills map Pin it; archive duplicates Monitor with status lights; notify only when action is needed Pin the useful conversations Publication in four clicks, announcement, skill

See a complete case