DEV Community: Olivia Craft

The Freelancer's Guide to Cursor Rules: One File Per Client

Olivia Craft — Sun, 05 Apr 2026 05:46:29 +0000

Have you ever started a new freelance project and spent the first 3 days just explaining your setup to the AI?

Your stack, your coding style, your client's requirements, your preferred patterns — over and over again, with every new conversation.

I did. Then I stopped.

The Freelancer's Context Problem

When you're juggling 3-4 clients at once, each project has its own:

Tech stack and versions
Code style preferences
Business logic quirks
Naming conventions
Things the client explicitly hates

Most freelancers handle this by re-explaining everything every session. Senior freelancers keep a mental model. Smart freelancers build systems.

One File Per Client

Here's the setup that changed how I work:

I keep a file in every client project. Not a generic one — a specific, living document that captures everything Cursor needs to know to produce useful output immediately.

any

Why This Pays Off Compoundingly

Session 1 with this file: Cursor writes code that fits the project without me explaining anything.

Session 10: The file has grown. It includes patterns we established, decisions we documented, things we discovered broke.

Session 50: I have institutional knowledge captured in a file. When I onboard a subcontractor, I hand them the file. When the client asks why we made a decision 3 months ago, the answer is there.

The Proposal Angle

Here's something most freelancers miss: a well-maintained file is also a scoping tool.

Before I write a project proposal, I spend 30 minutes building a draft based on the client's requirements. It forces me to think through:

What stack decisions need to be made upfront
What context I'll need during development
What patterns the client will likely insist on

By the time I write the proposal, I actually understand the project. My estimates are better. My questions to the client are sharper. I win more projects.

The Freelancer's Cursor Setup

If you're billing by the hour, AI context efficiency directly affects your margin. Here's what I run:

Per-client rules (in each project ):

Client business context
Tech stack decisions
Things that are live and untouchable
Current sprint focus

Global rules (in Cursor settings):

Your personal coding style
Your preferred patterns for common tasks
Your default error handling approach
Languages/frameworks you hate and why

The combination means Cursor knows you + knows the client. Output quality goes up. Revision cycles go down.

The Real Unlock

The dirty secret of freelancing with AI is that most people use it like a search engine with autocomplete. They ask questions. They paste code. They explain the same context 50 times.

The freelancers who are quietly doubling their output are the ones who invested 20 minutes building proper context infrastructure.

Your file isn't a configuration file. It's a knowledge system.

If you want a head start, I put together a Cursor Rules Pack with 7 production-tested templates for common freelance scenarios — client onboarding, API integrations, SaaS projects, and more. Check it out here.

Why Your Cursor Rules Are Being Silently Ignored (And How to Fix It)

Olivia Craft — Sun, 05 Apr 2026 00:47:47 +0000

If you set up your .cursorrules file weeks ago and Cursor still feels like it hasn't changed — this is for you.

Most developers write cursor rules once, check the box, and move on. Then they wonder why Cursor keeps suggesting the wrong patterns, ignoring their preferred stack, or generating code they immediately rewrite.

The rules aren't broken. They're being ignored. Here's why.

1. Your rules are too vague to act on

Compare these two rules:

Bad: "Write clean code"
Better: "Prefer early returns over nested conditionals. Functions should do one thing. Max 40 lines per function."

Cursor is a language model. It responds to specific, unambiguous instructions — not abstract goals. Vague rules get averaged into the model's general behavior and disappear.

Fix: Rewrite every rule as a constraint with a measurable outcome.

2. You're fighting the model's defaults

Some things are deeply embedded in the model's training. Telling it "never use console.log" might work 80% of the time — but under pressure (complex debugging, long context), it reverts.

The rules that stick are the ones that redirect behavior, not fight it head-on.

Bad rule: "Never use any" (TypeScript)
Better: "When you would use any, use unknown instead and add a type guard. If you truly cannot avoid it, add an inline comment explaining why."

The second version gives the model an acceptable path forward.

3. Your rules file is too long

There's a practical context limit. A .cursorrules file with 200 lines competes with your actual code for attention in context.

Fix: Keep your rules file under 80 lines. Prioritize rules that address recurring mistakes — not aspirational guidelines.

4. The rules don't reflect your actual project

A generic .cursorrules template you found online will underperform a project-specific one you wrote yourself. The model can't know your business domain, your team's conventions, or which libraries you've banned unless you tell it.

Fix: After every session where you corrected the model, ask: "Could a rule have prevented this?" If yes, add it.

5. You set them up but never iterated

Cursor Rules are not a config file. They're a living document. Your project evolves. Rules that made sense in week 1 may be wrong in week 8.

The pattern that works:

Something breaks → add a rule
AI suggests wrong pattern → add a rule
You find yourself repeating context → add a rule

If you want a head start with production-tested rules — the Cursor Rules Pack v2 includes 35+ rules covering dependency discipline, error handling, TypeScript strictness, commit hygiene, and more.

The goal isn't a perfect .cursorrules file. It's a file that gets slightly less wrong every week.

Stop Re-Explaining Your Stack to Cursor: A Practical Guide to Cursor Rules

Olivia Craft — Sat, 04 Apr 2026 13:05:08 +0000

If you use Cursor daily, you've probably noticed something: the more complex your project, the more time you spend re-explaining context to the AI.

"We use TypeScript. We prefer functional components. Don't use classes. Keep functions under 50 lines."

Sound familiar? You're writing this in every chat window. Every new session. Every time the model forgets.

Cursor Rules fix this.

What Are Cursor Rules?

Cursor Rules (.cursor/rules/*.mdc files) let you define persistent instructions that Cursor applies to every interaction. Think of them as a permanent system prompt for your project.

Instead of telling the AI your conventions each time, you define them once:

# TypeScript Rules
- Use strict TypeScript. No `any` types.
- Prefer `const` over `let`. Never use `var`.
- All async functions must handle errors explicitly.
- Export types separately from implementations.

Done. Cursor reads this on every request.

Why This Actually Matters

The difference between a good Cursor session and a frustrating one usually comes down to context consistency. When the AI knows your stack, your conventions, and your constraints upfront:

Code suggestions fit your codebase immediately
You stop correcting the same mistakes repeatedly
Reviews get faster (AI already knows what "good" looks like for your project)
Onboarding new contributors becomes easier (the rules document your standards)

The Problem With DIY Rules

Writing effective Cursor Rules isn't obvious. There's no official template. Most developers start from scratch, iterate through trial and error, and end up with rules that are either too vague ("write clean code") or too rigid.

What actually works:

1. Layer your rules by scope

Global rules: apply everywhere (naming conventions, error handling)
Feature rules: apply to specific directories (API routes, components)
Task rules: apply to specific file types (tests, migrations)

2. Be explicit about what NOT to do
Cursor responds well to negative constraints:

- Never generate placeholder comments like "// TODO: implement this"
- Don't add console.log statements for debugging
- Never use default exports for utility functions

3. Include examples, not just descriptions
Rules with examples outperform abstract descriptions consistently.

A Starter Pack That Works

After testing across 15+ project types (SaaS, APIs, CLI tools, Next.js apps), the rules that move the needle most are:

Architecture rules — where things live and why
Code style rules — beyond what linters catch
AI behavior rules — how the model should approach uncertainty
Testing rules — what to test and how to structure it
Documentation rules — inline comments vs. external docs

This is exactly what the Cursor Rules Pack covers — 50+ production-tested rules across these categories, structured so you can drop them into any project and start seeing results in the first session.

Getting Started Today

Even if you don't use a pre-built pack, start with three rules in any project:

# Core Rules

1. Before writing any code, state your approach in one sentence.
2. If you're unsure about a requirement, ask before implementing.
3. Match the code style of the surrounding file, not your defaults.

These three alone reduce the most common friction points.

If you're already using Cursor Rules and want to compare notes — or if you've found rules that work particularly well for your stack — drop them in the comments. Always curious what's working for others.

The Cursor Rules Pack ($27) includes 50+ rules organized by project type with a setup guide. Built for developers who want results without the trial-and-error.