Can Cursor Start from Scratch Go Live Directly? 2026 Acceptance Checklist

The browser preview works, but nobody can explain where the secrets, build command, or recoverable source state lives.

The fastest fix is to treat Cursor Start from Scratch as a rapid prototype path, then block production release until repository ownership, reproducible builds, automated tests, secret isolation, human review, and rollback are all proven. Projects that require Xcode or Apple SDKs must also move into an independent Mac environment for validation.

Who should read this: Independent developers need a boundary between a demo and a maintainable project. Startup teams using Cursor Cloud Agents need clear repository, review, and release gates. Platform engineers need evidence that a project can leave the Agent session and run in a controlled CI or Mac environment.

Operational reminder: A successful preview proves that one execution path produced a visible result. It does not prove that the project is secure, reproducible, supportable, or ready for production traffic.

Last updated August 28, 2026. Feature status and integration scope were checked against the Cursor changelog, Origin documentation, and Cloud Agents documentation.

Prototype scope before generation

The first acceptance decision happens before you ask the Agent to write code. Define what “good enough” means for this project, because a one-time demonstration, an internal tool, and a public service carry different failure costs.

Write down these boundaries in the task brief:

• One-time demo: The goal is a visible flow that supports a product conversation. Temporary data and limited error handling may be acceptable if the project is clearly disposable.
• Internal tool: The project needs named users, access control, data retention rules, an owner, and a recovery path. A small audience does not remove the need to protect internal data.
• Public service: The project needs a maintained repository, tested deployment path, secret management, logs, rollback, and an accountable person or team.

Also record the intended framework, data types, external APIs, authentication model, and final runtime. Mark any dependency on Xcode, Apple SDKs, signing, simulator tooling, or another macOS-only component before generation begins.

Cursor’s official materials confirm that Start from Scratch can initiate a Cloud Agent without a connected third-party source-code repository, create an Origin project, and provide a browser preview. Those capabilities define the starting point. They do not establish production security, compliance, test coverage, availability, or a specific Apple-toolchain workflow. Origin is documented as early beta, so access and behavior should be rechecked before relying on it for a team process. See the Origin feature scope for the current boundary.

Acceptance rating: scope clarity

• Strong: The project type, data sensitivity, runtime, owner, and exit condition are written down.
• Conditional: The interface is clear, but data handling or deployment ownership is undecided.
• Return: The team calls a project “production-ready” only because the page opens.

Generated files versus generated context

After the first generation, inspect the project as if you were taking over from a contractor. The central question is not whether the Agent produced many files. It is whether another developer can understand, run, change, and review those files without access to the original conversation.

Check the following before accepting the generated result:

• The directory structure separates application code, configuration, tests, scripts, and generated assets in a recognizable way.
• Dependency manifests and lockfiles exist where the selected stack expects them.
• The start, build, test, and migration commands are written in project documentation.
• Environment variables are listed by purpose, while real credentials remain outside the repository.
• Core business rules exist in versioned files rather than only in prompts, Agent memory, or temporary runtime state.
• The generated diff is reviewable. Remove sample credentials, placeholder identities, fake production records, and debug endpoints.
• Error handling distinguishes invalid input, unavailable services, failed authentication, and persistence errors.

This is where many AI Coding projects fail quietly. The output may look complete because the Agent remembers assumptions that are not represented in the files. A new developer then guesses the missing setup, changes an unrelated dependency, or recreates a behavior that was never documented.

Use a clean handoff note containing the repository path, required environment variables, local commands, known limitations, test data policy, and open risks. If the note cannot be written from the files and logs, the project is not ready to leave the prototype stage.

Preview behavior versus application behavior

A browser preview is useful because it exposes the visible path quickly. It can confirm that the interface renders, that a route responds, or that a basic interaction reaches a result. It cannot, by itself, verify every layer behind that result.

Test the application in separate passes:

Static interface. Confirm routes, assets, responsive states, loading indicators, empty states, and visible error messages. A page that looks correct may still contain hard-coded data or a dead submission path.

Server behavior. Exercise authentication, authorization, validation, rate boundaries, external API failures, and unexpected response formats. Record the request path and the resulting error rather than accepting a generic success message.

Persistence. Create a record, refresh the page, restart the service, and retrieve the record again. If the data disappears after a restart, the project may still be using an in-memory store or preview-only state.

External services. Test missing credentials, expired credentials, slow responses, malformed responses, and service outages. An API call that works once with a permissive development key is not evidence of a safe integration.

Recovery. Stop and restart the preview, repeat the same user flow, and compare the state. Save build logs, test output, screenshots of failures, and the exact input that caused them. These artifacts form the evidence for the next gate.

The difference between “preview passed” and “function passed” is usually state. Normal input tests the happy path; restart and failure tests reveal whether the application has a real operating model.

Repository ownership and Origin handoff

Once the prototype has enough evidence to justify preservation, create the formal code boundary. The repository is not merely a backup. It assigns responsibility for review, changes, access, and recovery.

Cursor’s Cloud Agents guidance describes the Agent workflow and its relationship with source repositories. Use that documentation to verify the current connection and permission model instead of assuming that a generated project inherits the controls of your wider organization.

Before the first baseline merge, verify:

• The repository owner is a person or organization that will still exist after the prototype phase.
• Visibility matches the sensitivity of the code and data.
• Members have the minimum access required for their work.
• Privacy Mode and Agent permissions are understood by the project owner.
• Reviewers, merge approvers, and integration maintainers are named.
• Pull requests, commits, and changed files provide a traceable history.
• The repository can be cloned, changed, pushed, and restored using standard Git operations.
• The first baseline has a human review record, including known limitations and excluded files.

The Git clone documentation is a useful reference for testing whether the repository can be reconstructed outside the original environment. Run the clone from a clean directory, not from a folder that already contains dependencies or generated artifacts.

Repository decision table

The most important distinction is between an Origin project and a production repository. The former can accelerate creation. The latter must support independent maintenance.

Clean builds and CI evidence

The next gate is reproducibility. Start from a new working directory or isolated runner. Install dependencies from the committed manifests, run the documented build command, execute the tests, and compare the result with the browser preview.

A clean rebuild should answer these questions:

• Does dependency installation work without an Agent cache?
• Does the build require an undocumented local tool?
• Are environment variables named and injected through the correct mechanism?
• Do tests run without manually preparing hidden state?
• Can a failed build identify the changed file and the failed check?
• Is the generated artifact identifiable and recoverable?
• Can a developer reproduce the result from the repository alone?

Place formatting checks, unit tests, integration tests where applicable, dependency review, secret scanning, and release checks into CI. Keep the checks proportionate to the project type, but do not remove them simply because the prototype is small. A small application can still expose credentials, destroy data, or publish an unreviewed change.

Separate environments by responsibility. The Cloud Agent may be useful for creating and modifying code. CI should provide an independent verification path. Production should receive only an approved artifact or commit that passed the required gates.

For a web project connected to a Git-based deployment provider, confirm which branch or event causes deployment, which credentials are available to the integration, and how a previous revision is restored. The Git integration documentation can help verify provider-side repository behavior, but it does not replace your own application tests or access review.

Mac toolchain and release proof

A project that depends on Xcode, Apple SDKs, signing certificates, simulators, or macOS-specific build tools needs a separate acceptance path. A browser preview can show a web surface while saying nothing about whether the native target compiles, signs, archives, or installs correctly.

Move the repository into an isolated Mac environment and validate:

• The required Xcode and SDK setup is documented.
• Dependencies can be installed without the original Agent session.
• The target builds from the committed source.
• Signing identities and provisioning material are injected securely.
• Build logs identify the commit and environment.
• The archive or package can be handed to the next operator.
• A failed signing or export step has a documented recovery path.

Apple’s distribution signing and export documentation explains the signing and export process. Use it as the authority for the release procedure, then add project-specific evidence from your own environment.

If you need a temporary isolated Mac runner, compare the required build workflow with the remote Mac development capacity guide. If the team needs a longer-running CI node rather than an occasional validation machine, the Xcode continuous integration environment guide is the more relevant next step.

Environment comparison table

Release decision and first-week monitoring

Use a three-way decision instead of forcing every prototype into a binary launch choice.

Pass to formal release only when the code is independently maintainable, the clean build succeeds, the required tests run, access is explainable, secrets are isolated, and rollback has been exercised.

Approve a limited pilot when the remaining gaps are known and the exposure is controlled. Restrict access, use non-sensitive data where possible, define an owner, and set a date for closing each gap. A pilot is not a substitute for a missing repository or an unknown credential path.

Return for remediation when the application depends on the Agent session, cannot be rebuilt, has unreviewed secrets, lacks an owner, or has no credible recovery path. Do not widen access while those conditions remain.

For the first week after a pilot or release, record failed Agent tasks, manual fixes, build duration, dependency changes, environment differences, deployment failures, and rollback attempts. These are operating signals, not vanity metrics. If the same manual repair appears repeatedly, convert it into a test, script, policy, or documented handoff step.

Cursor Start from Scratch acceptance is complete only when the evidence chain survives a handoff: another operator can obtain the source, understand the project, rebuild it, test it, deploy it within the approved scope, and restore the previous state.

Current workflow versus an isolated Mac

Keeping everything inside the Agent and preview workflow is attractive for speed, but it has real limits. The team may lack a durable repository boundary, depend on hidden workspace state, and discover too late that the target build requires macOS tools unavailable in the original environment. Permission review can also become ambiguous when code generation, integration, and release approval happen in the same flow.

For a short-lived web demo, that trade-off may be reasonable. For an application moving toward production, an independent execution environment gives you a cleaner place to rebuild, inspect credentials, run CI jobs, and validate Apple-specific tooling. When you need temporary capacity or a controlled Mac test environment, renting a Mac through MacPull can be more practical than purchasing hardware before the workflow is proven.

Do the clean rebuild before you click publish. If the project depends on Xcode, Apple SDKs, or a persistent macOS build node, use an isolated Mac validation path and keep the release decision tied to evidence rather than to a successful preview.

FAQ