How to start a software project with Claude Code

Start a software project with Claude Code by choosing the working folder, explaining the purpose and constraints, and agreeing on a small first milestone before implementation. Ask it to examine any existing files and show evidence of the checks it runs.

For a founder, the most useful starting question is often “What is the smallest suitable approach for this outcome?” rather than “Can you build the entire app?” The answer should help you make a decision you understand.

Understand the workflow you are choosing

Claude Code works with development projects. This guide focuses on its terminal workflow; use Anthropic's official quickstart for current installation and authentication instructions.

After installation and sign-in, the quickstart shows starting a session from your project directory with claude. The directory matters because it identifies the workspace you intend to work in. Check the working location before requesting file changes.

You do not need to memorise terminal commands to describe your project. You should still understand consequential actions and examine requests involving sensitive access, production changes or deletion. Available permission behaviour depends on your setup; review it rather than assuming every action will ask you first.

Give Claude a project it can reason about

Prepare a short overview with:

• The person who will use the software.
• The outcome the first version should deliver.
• Inputs, outputs and important access restrictions.
• Required services or an existing technology you must retain.
• What is outside the first version.
• One useful result you can check with sample data.

A local script can have a small foundation. A shared app or an unattended integration needs additional decisions about access, saved state and operational responsibility. Avoid forcing the same architecture onto all three.

The project brief template helps organise those facts without pretending every requirement is already settled.

Begin with inspection and an approach discussion

Consider a fictional tool that reads a workshop's CSV export and previews jobs awaiting assignment. Start with this prompt:

I need a tool that reads a workshop jobs CSV and previews
the jobs that have no assignee. One coordinator will run it.
The original CSV must stay unchanged.

I have sample data and know the expected selected rows.
Do not add accounts, scheduled processing or messaging yet.

Inspect the workspace and identify existing work first.
Propose a proportionate implementation approach and one
checkable milestone. Clarify only decisions that materially
change that approach. Do not implement yet.

The sample names a boundary and a checkable result. It does not specify a language without a reason. If your environment requires a particular language or platform, state that as a confirmed constraint.

Anthropic's best practices recommend separating exploration, planning and implementation for work that benefits from planning. Use that capability instead of assuming the agent must immediately edit files.

Store the context you want to keep

Keep the overview and approved decisions in readable files. For persistent project guidance, consult Claude Code's project memory documentation, which explains CLAUDE.md and how instructions are loaded.

A useful working guide can identify the authoritative plan, explain what should remain unchanged and point to real verification commands once those commands exist. It should not claim a test command works before anyone has run it.

Avoid duplicating the whole plan in several instruction files. Keep the main requirement in one place and refer to it. Revisit the guidance after a meaningful project change so the builder does not receive outdated instructions.

Implement one milestone with explicit boundaries

After you approve the approach, give a bounded request:

Implement the CSV preview milestone we agreed on.
Use a sample file rather than live customer data.

Show the selected unassigned jobs and explain invalid rows.
Do not change the input file or send any messages.

Check a missing assignee, an assigned job and a malformed row.
Compare the actual report with the expected sample result.
Report the commands that ran and what remains unverified.

Define how a missing value should be interpreted. A blank field and a malformed field are not automatically the same thing. If a fallback is required, make it explicit and include a check for it.

Before changes, retain a recoverable checkpoint. After changes, review what was added or modified. If the agent proposes an unrelated rewrite, ask what requirement makes it necessary before proceeding.

Ask for evidence when the tool says it is done

Review the output yourself using the agreed sample. Confirm that important inputs were preserved and that a failed row does not silently become a valid result.

For an interface, inspect the actual screen. For a script, compare the output. For a connected service, distinguish local checks from real authentication and delivery checks. The milestone testing guide provides a verification worksheet you can reuse.

If the implementation differs from the plan, record the difference and decide whether to correct the code or consciously revise the requirement. Avoid silently rewriting the expected result to make a test pass.

Carry the foundation into later work

Keep completed milestones, accepted choices and remaining decisions visible. Start the next task with that context and a clear outcome. More features should follow the project direction, rather than emerge from unrelated suggestions in each conversation.

PenguinKit can help you prepare that project foundation before the Claude Code session. It provides planning and build guidance; it does not implement the software or certify the agent's output.