Cursor

The editor we use during development. It speeds up implementation. Architecture and accountability remain with us.

Cursor is part of the development toolchain. It is an editor with AI assistance, and we use it to move more quickly through implementation: boilerplate, refactors, tests, and a first draft that a person then reviews. It is not a product we deliver, and it does not replace architecture or responsibility for the result.

The homepage states the same position. This page explains how that works in practice.

To discuss a project, start a conversation. The structure of an engagement is described in Project initiation.

At a glance


Kind	Development environment
Used for	Implementation inside a repository we maintain
Does not replace	Scope, architecture, integration decisions, or review
Delivered to you	The application. Cursor is not a runtime dependency

When we use it

Implementing work that has already been designed: a migration, a component, a test, or a repeated change across a module
Reading an unfamiliar part of a codebase during a takeover, so the first questions are more specific
Drafting repetitive parts of a change, so review time is spent on behaviour

We do not use it to decide the domain model, to choose an integration, or to produce an application from a short prompt.

What we rely on

The repository as the source of truth. Chat history is not the specification
Project rules that keep generated code within the stack and the project conventions
Review by a person before a change is treated as complete
Tests for the rules that matter, so an incorrect implementation still fails

Why it fits the work

Shorter implementation, with the same design. The time saved is in writing and in mechanical edits. The project sequence does not become shorter by skipping scope.
Faster review of an existing codebase. A stalled codebase can be mapped more quickly. The decision about what to keep is still made by a person.
No new production dependency. Cursor is not part of the runtime. Laravel, Nuxt, and Flutter do not require it to build or to run.
Cost stays with the delivery, not with the tool. The product does not include a tool licence, and the code does not depend on the tool to be understood. If we cannot explain a change, it is not complete.

How we build with it

The engagement follows Project initiation. Cursor is used during development. It does not come before scope and architecture.

Architecture. Written by the people on the project. An assistant may summarise it. It does not approve the design.
Development. Assistance is used on the implementation, and the diff is reviewed in the same way as any other change. Generated code that does not match the stack is not kept.
Hardening. Secrets stay out of prompts and out of the repository. Tests and review cover the change. Generated code is not merged because it was generated.
Release and support. Production is the application on AWS and Cloudflare. Cursor is not part of that path.

How it sits in the stack

Cursor is used while working in the repositories. It is not coupled to the delivered software. The delivered stack remains Laravel, Nuxt, Flutter, Tailwind CSS, MySQL, AWS, and Cloudflare.

Your team does not need Cursor licences to maintain the code afterwards.

In practice

On a new build or a takeover, the tool is used in the editor. The specification remains in the scope, the issues, and the code. dCommerce and client platforms are still designed and operated as software. The editor is one of the tools used to write that software.

Questions

Will AI write the application?

It may draft parts of the implementation. The process, the integrations, the data, and the first-release boundary are still decided and reviewed by us. A finished system produced from a prompt is a different service from this one.

Does our code get used to train a public model?

Commercial terms depend on the plan and the settings in use at the time. We treat client repositories as confidential. Code, conversations, and commercial detail stay private, which is the same standard as the rest of the engagement. If your policy does not allow a particular tool, please say so at the start. The work does not depend on this editor.

Can our own developers work in the repository without Cursor?

Yes. The result is standard Laravel, Nuxt, or Flutter. Any editor that can open the repository is sufficient.

Next step

If the question is about a platform, a stalled build, or an integration, start a conversation. The editor is part of how the work is done. The process is what the engagement covers.