DEV Community: Michael Sacco

10 ChatGPT Prompts Every Freelancer Should Have Saved

Michael Sacco — Wed, 13 May 2026 17:00:38 +0000

Most freelancers use ChatGPT like a search engine: vague prompts, mediocre output. The ones saving hours every week are doing something different.

Here are 10 prompts that actually move the needle — organized by the situations you hit most often.

1. Proposal opener that doesn't sound like everyone else

Write a compelling 3-sentence opening for a freelance proposal for [project type] for a client who is [describe client/industry]. Make it sound like I deeply understand their problem, not just their task. Avoid generic phrases like "I am excited to apply."

Most proposals start with "Hi, I'm [Name] and I have X years of experience." That's the least compelling way to open. This prompt fixes that.

2. Scope creep response (saved me thousands)

A client has asked me to add [new request] which is outside our agreed scope. Write a professional, non-confrontational email that acknowledges their request, explains it's outside scope, and offers to do it as a paid addition. Keep the relationship warm.

Having this ready-to-deploy means you never awkwardly stammer through a scope conversation again.

3. Cold email that doesn't feel like cold email

Write a cold email to [business type] offering my [service] services. Keep it under 150 words. Lead with a specific observation about their business or a problem they likely have. End with a low-friction ask — not a sales call. My key result I can reference: [result].

The key: leading with observation, not "I'm a [service] who works with companies like yours."

4. Rate increase email (without apologizing)

Write an email to a long-term client announcing a [X]% rate increase starting [date]. Acknowledge the relationship, give advance notice, and frame it positively. Tone: confident but warm. Don't over-explain or apologize.

Most freelancers apologize for raising rates. This prompt keeps you confident.

5. Testimonial request that gets responses

Write an email asking a happy client for a testimonial for [project type], completed [timeframe]. Make the ask easy by suggesting they answer 3 simple questions: What was the situation before we worked together? What did we achieve? Who would you recommend me to?

The structured questions make it easy for clients to respond rather than staring at a blank page.

6. Project status update in 2 minutes

Write a weekly project status update email for [project type]. Completed this week: [list]. Next week I'll work on: [list]. Blockers: [list or 'none']. Keep it to 150 words or less. Professional but human tone.

7. Saying no without burning the bridge

Write a short, polite decline email for a project I don't want to take on. The project is [type]. Reason (internal only): [real reason]. The email should decline gracefully, not over-explain, and leave the door open for future work.

8. LinkedIn headline that actually works

Write 5 LinkedIn headline options for a freelance [service]. I help [target client type] achieve [outcome]. Headlines should be specific, benefit-focused, and under 120 characters. Avoid: "guru," "ninja," "expert."

9. Turn client feedback into usable testimonial copy

I received this client feedback: [paste feedback]. Rewrite it as: (1) a short LinkedIn post I can share, (2) a 2-sentence website testimonial blurb, (3) a bullet point for a proposal. Keep the client's voice but tighten the language.

10. Quarterly business review (the one everyone skips)

Ask me 10 questions to help me review my freelance business this quarter. Cover: revenue vs. goal, best/worst clients, time spent vs. billed, skills gaps, what to double down on, and what to stop doing. Then help me set 3 priorities for next quarter.

This one takes 30 minutes but will save you from repeating the same mistakes next quarter.

The pattern across all of these: specificity in → usefulness out. Replace every [bracket] with your actual details and the output quality jumps significantly.

I put together 50 of these covering proposals, cold outreach, client communication, pricing, invoicing, portfolio, personal brand, and business development — designed as a working reference you keep open, not something you read once: gumroad.com/l/ymugi ($9)

How I Render 100,000 Unity Objects With One Draw Call (38ms to 0.4ms)

Michael Sacco — Wed, 13 May 2026 13:53:19 +0000

If you've ever tried to render tens of thousands of objects in Unity — trees, rocks, enemies, particles — you know the pain. My scene had 100,000 simple mesh instances and was running at 38ms per frame (26 FPS). After switching to GPU indirect rendering, I got it down to 0.4ms. That's a 95x speedup.

Here's exactly how it works.

The Problem: CPU Bottleneck

Unity's default rendering pipeline sends one draw call per object (or per batch). Even with GPU instancing enabled, the CPU still has to prepare transform data and issue commands for each object. At 100k objects, that's brutal.

The frame breakdown looked like this:

CPU: 35ms (preparing transforms, issuing draw calls)
GPU: 3ms (actually drawing)

The GPU was sitting idle most of the time. All the cost was on the CPU.

The Solution: DrawMeshInstancedIndirect

Graphics.DrawMeshInstancedIndirect lets you tell the GPU "draw N instances of this mesh" — and the GPU figures out the rest from a buffer you've already uploaded. The CPU just issues a single command.

Here's the core setup:

public class IndirectRenderer : MonoBehaviour
{
    public Mesh instanceMesh;
    public Material instanceMaterial;
    public int instanceCount = 100000;

    private ComputeBuffer positionBuffer;
    private ComputeBuffer argsBuffer;
    private uint[] args = new uint[5] { 0, 0, 0, 0, 0 };

    void Start()
    {
        // Upload all positions to GPU once
        positionBuffer = new ComputeBuffer(instanceCount, 16); // float4
        Vector4[] positions = new Vector4[instanceCount];
        for (int i = 0; i < instanceCount; i++)
        {
            positions[i] = new Vector4(
                Random.Range(-500f, 500f), 0,
                Random.Range(-500f, 500f), 1
            );
        }
        positionBuffer.SetData(positions);
        instanceMaterial.SetBuffer("_Positions", positionBuffer);

        // Set up indirect args buffer
        argsBuffer = new ComputeBuffer(1, args.Length * sizeof(uint),
            ComputeBufferType.IndirectArguments);
        args[0] = instanceMesh.GetIndexCount(0);
        args[1] = (uint)instanceCount;
        args[2] = instanceMesh.GetIndexStart(0);
        args[3] = instanceMesh.GetBaseVertex(0);
        argsBuffer.SetData(args);
    }

    void Update()
    {
        // ONE draw call for 100k objects
        Graphics.DrawMeshInstancedIndirect(
            instanceMesh,
            0,
            instanceMaterial,
            new Bounds(Vector3.zero, new Vector3(1000, 100, 1000)),
            argsBuffer
        );
    }

    void OnDestroy()
    {
        positionBuffer?.Release();
        argsBuffer?.Release();
    }
}

The Shader Side

Your material needs to read the position buffer. In HLSL:

StructuredBuffer<float4> _Positions;

void vert(appdata v, uint instanceID : SV_InstanceID,
          out v2f o)
{
    float4 worldPos = _Positions[instanceID];
    float4 localPos = v.vertex;
    o.pos = UnityObjectToClipPos(localPos + worldPos);
}

The key is SV_InstanceID — this is the GPU-side index that maps each instance to its entry in the position buffer.

The Results

Approach	CPU	GPU	Total
Default (no batching)	35ms	3ms	38ms
Static batching	28ms	3ms	31ms
GPU instancing	12ms	3ms	15ms
Indirect rendering	0.1ms	0.3ms	0.4ms

The CPU time essentially disappears. The GPU is doing all the work, which is exactly what it's built for.

When to Use This

GPU indirect rendering is ideal when:

You have thousands of identical or similar meshes (foliage, particles, crowds)
Objects don't need per-frame CPU logic (or you can move that logic to a compute shader)
You want LOD handled on the GPU (you can encode LOD level in the args buffer)

It's not the right fit for objects that need individual per-frame C# callbacks, or highly unique meshes that can't share a draw call.

Going Further: Compute Shaders for Culling

The real power comes when you combine this with a compute shader that does frustum culling on the GPU. Instead of rendering all 100k instances, you dispatch a compute shader that writes only visible instances into the args buffer — entirely on the GPU, zero CPU involvement.

[numthreads(64, 1, 1)]
void CSMain(uint3 id : SV_DispatchThreadID)
{
    if (id.x >= _InstanceCount) return;

    float4 pos = _AllPositions[id.x];
    if (IsInFrustum(pos))
    {
        uint idx;
        InterlockedAdd(_ArgsBuffer[1], 1, idx);
        _VisiblePositions[idx] = pos;
    }
}

This can drop your rendered instance count from 100k to 8k depending on camera angle, with the cull happening in microseconds.

Ready-to-Use Starter Kit

If you want to skip the boilerplate and start with working examples, I've put together a GPU Indirect Rendering Starter Pack for Unity that includes:

Complete indirect renderer with frustum culling compute shader
LOD support baked in
Example scene with 100k instances running in real-time
Documented, production-ready C# + HLSL code

It's the foundation I wish I'd had when I started with this technique.

Have questions about GPU indirect rendering or hit a snag? Drop a comment below — happy to help.