How to start building a software project with Codex

To start building a software project with Codex, choose the workspace, provide the project's purpose and boundaries, and request a reviewable approach before a substantial change. Follow with one useful implementation milestone and checks that show what actually works.

If you are a founder and each new prompt seems to send the project in a different direction, make the agreed context visible first. You need a shared understanding of the goal and constraints, not a more impressive-sounding prompt.

Choose the workspace deliberately

Use OpenAI's official quickstart for current setup and account guidance. When working with a local project, select the folder that contains the work you intend to change.

For the CLI, OpenAI's projects documentation explains that Codex uses the directory where it starts, or the directory specified with --cd. After installing and authenticating through the official instructions, a session can be started with:

codex --cd /path/to/your/project

Replace the example path with your actual project folder. Do not run it against an unrelated folder just because it is convenient to open. Account availability, permissions and usage limits should be checked in the current official setup.

This article uses prompts that can be adapted to your Codex surface. It does not depend on a particular model name or a promise of unattended implementation.

Explain the project before asking for a scaffold

Write down the user, one useful journey and the constraints you already know. For a fictional proposal tracker, the first version might let a founder record a proposal, update its status and see which proposals still need a follow-up.

Clarify whether only one person uses it or several people share records. Explain whether the information stays local or needs access from different devices. Leave email automation and payment processing outside the first milestone unless they are essential to its outcome.

Use the technology choice guide if the recommended framework or storage approach is unfamiliar. Ask for the reason and trade-off, not only a technology name.

Start with an inspection prompt

I want a proposal tracker for one founder.
The first version records a proposal, changes its status
and lists proposals that need attention.

I need the records to survive reopening the app.
Email sending, billing and team accounts are out of scope.

Read the project overview and inspect this workspace.
Describe existing work before proposing changes.
Recommend a suitable first milestone and its completion
checks. Separate assumptions from confirmed requirements.
Do not edit files yet.

For an empty workspace, say that explicitly. For an existing application, identify the behaviour you want to preserve. Codex's investigation of accessible files is part of the development workflow; it should not be replaced with guesses based on a screenshot alone.

If a proposed change depends on a provider account or service you do not have, record that dependency. It is reasonable to use sample data for a first milestone while keeping a real integration as a later check.

Keep the approved plan in files

Save the project overview, scope, decisions and milestone checks in readable documents. Name the files in the next request and ask Codex to summarise the important constraints before acting.

Keep decisions separate from preferences. “Use the existing database” is a confirmed constraint if you have chosen it. “Consider a hosted database” is a recommendation to discuss. Your builder should not quietly treat the second statement as approval.

Avoid giving conflicting versions of the plan. Update the authoritative record when you change the scope, and retain enough history to explain why the choice changed. The handoff guide includes a portable prompt for that process.

Request a bounded implementation

Once you approve the approach, use a task such as:

Implement the approved proposal-record milestone only.
Preserve existing behaviour and unrelated changes.

Check creating a proposal, changing its status and reopening
the app with the saved record intact. Reject a blank title.
Do not add the deferred integrations.

Report changed files, checks that actually ran, their results
and anything that still needs provider access or manual review.

Use a recoverable checkpoint before substantial edits. Review commands and permission requests according to their consequences. A natural-language instruction to avoid risky actions is useful guidance, but it is not a substitute for appropriate access controls and backups.

For a tiny local task, this workflow can remain light. Larger or more consequential software needs checks and recovery procedures that match its data and operating risks.

Examine the result before moving on

Ask for a demonstration of the agreed journey and meaningful verification output. Try a normal input, a boundary and an invalid input. A build succeeding does not establish that every access rule or connected service works.

Use the first-milestone testing checklist to record expected results, actual results and unverified areas. If a check fails, ask for the smallest justified correction and rerun the relevant check.

Keep the project plan current after implementation. It should distinguish completed behaviour from a proposed future feature. That gives the next Codex session a clearer starting point.

Prepare the foundation when the direction is unclear

Codex can help discuss and implement a project. PenguinKit offers a separate guided planning step when you want an organised foundation to review and carry into your implementation workflow. You receive planning documents and guidance, not a completed or independently verified application.