A small client wanted an e-commerce frontend built in 6 weeks: product catalog, cart, checkout, order history, account management. Backend was their existing Magento Headless API. I took it on as a fixed-scope build with Cursor as my primary tool.

The project shipped on time. About 18k lines of Vue 3 + TypeScript. This is the breakdown of how Cursor actually fit the work — what it accelerated, where it didn’t help, and what I’d change next time.

The setup

• Stack: Vue 3.4 + TypeScript, Vite, Pinia, Vue Router, Tailwind, shadcn-vue components
• Backend: Magento Headless GraphQL (existing, not in scope)
• Tool: Cursor 0.45 with Claude 3.5 Sonnet
• Configuration: project-specific .cursor/rules/ covering Vue 3 conventions, Pinia patterns, and component conventions
• Test framework: Vitest + Vue Testing Library
• Coverage target: 70%+ on critical paths (cart, checkout)

The .cursor/rules/ directory was set up week 1 and refined throughout. About 80 lines total across general, components, composables, and stores rules.

Sprint structure

Six weeks, six sprint themes:

1. Setup + product catalog — scaffold app, list and detail views
2. Cart + cart drawer — add/remove/quantity, persistent across reloads
3. Checkout flow — multi-step form with payment
4. Account + auth — login, signup, account management
5. Order history + reordering — past orders view, reorder flow
6. Polish + a11y + SEO — final touches

Where Cursor was a clear win

Product catalog (week 1)

The product list and detail views were classic CRUD-shaped work. List view with filters, detail view with image gallery and add-to-cart button. Cursor produced clean components from briefs like:

Build src/components/product/ProductCard.vue. It takes a Product prop 
(type defined in @/types/product.ts) and renders the product image, name, 
price, and an "Add to Cart" button. Match the styling pattern in 
ProductSummary.vue. The Add to Cart button emits an `add-to-cart` event 
with the product as payload.

Composer produced a 35-line component on first try. Reviewed, accepted, moved on. About 20 minutes per major component including tests. Without Cursor, my estimate is 35-45 minutes each.

For the catalog phase, Cursor saved roughly 8-10 hours over the week. Tokens spent: ~1.2M input across the week, ~$36 retail-equivalent (covered by my Cursor Pro flat rate).

Cart + cart drawer (week 2)

Pinia store work fit Cursor well. The store handled cart state, persistence to localStorage, sync with the backend, and exposed actions for add/remove/update.

Build the cart store in src/stores/cart.ts using setup syntax. State: items 
(array of CartItem), totals (subtotal, tax, total). Actions: addItem, 
removeItem, updateQuantity, clear, syncWithServer. Persist to localStorage 
with key 'cart-v1'. On addItem, if the product is already in cart, increment 
quantity instead of adding a duplicate.

Cursor produced a clean store that handled all the cases. One issue: the initial implementation used reactive() on the items array, which broke the destructuring patterns in components. I asked for ref() instead and Cursor refactored. Total: about 90 minutes for the store + cart drawer component.

The cart UI (drawer with quantity steppers, total, checkout button) was another 2 hours, mostly Cursor-driven.

Account management (week 4)

Profile editing, address management, password change. Standard form work that Cursor handled cleanly. The profile form (5 fields with validation) took 30 minutes including tests; a similar form by hand would have been about 60 minutes.

The address form had a quirk: addresses in Magento have country-specific validation rules (postal code format, required fields). Cursor’s first attempt had generic validation; I gave it the rule set explicitly and the second pass was correct. Total: 90 minutes.

Where Cursor was useful but slower than expected

Multi-step checkout (week 3)

Checkout was harder than catalog work for predictable reasons: more state, more validation, more edge cases. Cursor produced a workable scaffold but I had to do more iteration.

The first Cursor draft of the multi-step form had:

• Form state in a Pinia store (good)
• Step navigation with router (correct but awkward — refresh broke state)
• Per-step validation (correct)
• Submit calling the backend (correct shape, but error handling was thin)

I refined over 3-4 iterations:

• Persisted form state across refreshes (asked Cursor explicitly)
• Better error handling for failed payment validation
• Address validation that handled the same country-specific rules as the address form
• Testing for the navigation between steps with form state intact

Total time on checkout: about 14 hours over 3 days. Without Cursor, my estimate is 18-22 hours. Real savings, but smaller percentage than the catalog work.

Auth flow (week 4)

Login and signup were fast (Cursor handled them in standard form). Where I lost time: the integration with Magento’s auth tokens, refresh tokens, and the route guards.

Cursor’s first attempt at the auth interceptor for axios was correct in shape but wrong in detail — it tried to refresh tokens too aggressively and caused a refresh loop on certain error responses. Caught in testing, fixed in 30 minutes by asking Cursor to handle specific status codes differently.

The route guards needed to handle three states: authenticated, unauthenticated, and “authenticated but token expiring soon.” Cursor’s implementation handled the first two cleanly and got the third wrong (it would refresh on every navigation rather than only when needed). Another 30-minute correction.

These weren’t bugs in the code Cursor produced; they were behavior gaps that only became visible when I exercised the flow. The lesson: for stateful flows like auth, expect to iterate more than for stateless ones.

Where Cursor didn’t help much

Payment integration (week 3)

Payments were the riskiest part of the project and the part where Cursor was least useful. Reasons:

• The payment provider (Stripe Elements) has specific integration requirements that change between versions
• The error handling required understanding what happens at the network layer when a card is declined vs. when the API is down
• The 3D Secure handling requires interaction with the browser in ways Cursor doesn’t have visibility into
• Bugs in payment flows are visible only at runtime in specific scenarios that are hard to test without sandbox transactions

I wrote payment integration mostly by hand, with Cursor helping only on the boilerplate (form rendering, basic state management). The core flow — create payment intent, handle 3DS challenge, confirm payment, handle errors — was hand-written, with Stripe’s documentation open the whole time.

Time on payment integration: 16 hours. Cursor’s contribution: maybe 90 minutes saved on form scaffolding. The rest was non-AI work.

A11y and SEO polish (week 6)

Cursor wasn’t useful for this either. Accessibility issues require knowing what assistive technology actually does — what a screen reader announces, what keyboard navigation expects, what color contrast thresholds matter. Cursor can add aria-label attributes, but it can’t tell whether your tab order is sensible or whether your live regions are announcing the right things.

I used the axe DevTools and manual testing with VoiceOver. Cursor helped on small things (“add aria-current to the active nav link”) but most of the polish work was hands-on testing.

SEO meta tags were the same. Cursor can generate plausible meta tags from a page’s content. The actual SEO decisions (canonical URLs, structured data, image alt text strategy) require thinking about your specific site’s needs and aren’t pattern-matchable.

Time on a11y + SEO: 12 hours. Cursor’s contribution: trivial.

The numbers

Saved about 22-25% of total project time vs. my honest estimate without Cursor. Project shipped on time at 144 hours actual vs. budgeted 168.

The cost was the Cursor subscription ($20/month for the engagement, prorated to ~$30 for the project) plus the upfront time spent setting up .cursor/rules/ (about 4 hours over the first two weeks). Both rounded down to free in the context of project economics.

What I’d do differently

Front-load the rules investment. I refined .cursor/rules/ throughout the project rather than getting it right week 1. Some of the early drift (inconsistent component patterns, mixing ref and reactive) could have been prevented with better initial rules.

Identify Cursor-resistant work earlier. Payments and accessibility were the two places Cursor didn’t help. I should have flagged these in the project plan as “manual work, budget more time” rather than implicitly assuming AI would lift these phases too. Net effect on schedule was small but I cut into evening time more than I needed to.

Use the test command Cursor knows about. Cursor 0.45 has a /test command in chat that runs the test suite and feeds results back. I didn’t use this until week 5. Could have saved 3-5 hours of “run tests, paste failures” loops.

Set up Storybook for component testing. Several components were correct in isolation but wrong in composition. A Storybook setup would have caught these earlier than my integration testing did. Cursor would have helped scaffold Storybook stories quickly. Hindsight.

What I’d tell another developer doing similar work

For a Vue 3 + TS e-commerce build with Cursor:

Cursor is a real productivity gain on the CRUD-shaped 70% of the work. Catalog, cart, account management, order history. Don’t underweight this; it’s most of the project.

Don’t try to use Cursor on payments. The risk profile and the runtime-knowledge requirements don’t fit. Plan the payment integration as manual work and budget accordingly.

Don’t try to use Cursor on accessibility. Hands-on testing is the work; AI doesn’t speed it up.

Use .cursor/rules/ from day 1. Two hours of upfront writing saves dozens of hours of manual style fixes across the project.

Vue-specific rules matter. The general Cursor defaults skew React. A Vue project benefits noticeably from Vue-specific rules covering the Composition API patterns, Pinia conventions, and component structure expectations.

For me, this project shipped well. Cursor was net-positive. The 25% savings was real. The fact that some phases didn’t benefit doesn’t undermine the case for using AI tools — it just means knowing which phases benefit and budgeting accordingly. Mismatched expectations would have produced a missed deadline; calibrated expectations produced an on-time delivery with less weekend work than I’d budgeted for.