Work
How I actually work
These situations come from running an independent freelance
Generative AI business on
Fiverr.
Client work itself is confidential, so what follows isn't a gallery
of finished output. It's the process behind it — the kinds of
situations that come up, and how I've handled them. The specific
client, brief, and deliverable have been generalized throughout;
the decisions and reasoning haven't.
Working principles
How I begin, and how I keep going
How I begin
By asking what "done" actually looks like before starting anything — a surprising number of problems are really unclear definitions of success.
How I gather requirements
By asking specific, closed questions rather than open-ended ones — "should this be A or B" gets a faster, clearer answer than "what do you want."
How I reduce ambiguity
By stating my assumption out loud before acting on it, so it can be corrected early and cheaply instead of discovered late.
How I communicate
Plainly, and in writing where it matters — a clear "no" or "not yet" is more useful to someone than a vague "maybe."
How I deliver
In checkable steps rather than one large reveal at the end, so a wrong turn is caught early rather than at the deadline.
How I learn and improve
By writing down what went wrong immediately after it happens, while the specific reason is still clear — not from memory a week later.
In practice
Five kinds of situations, generalized
A brief that didn't say enough
Situation
A project arrived with a general direction but no clear definition of what a successful result would look like.
Challenge
Starting work on an unclear brief risks building the wrong thing carefully rather than the right thing quickly.
Approach
I asked a short set of specific questions to pin down what "good" meant for this particular request, rather than proceeding on assumption.
Execution
I shared a small early version for confirmation before producing the full piece, so any misunderstanding surfaced while it was still cheap to fix.
Outcome
The brief became clear before real work began, and the final delivery matched expectations on the first pass.
Lesson
It's faster to slow down at the start than to fix a misunderstanding after the work is done.
A tight turnaround
Situation
A client needed a fast delivery, well outside the timeline that would normally allow for a slow, iterative process.
Challenge
Speed and quality usually trade off against each other, especially without a team to split the work across.
Approach
I identified the one element that would be hardest to fix late, and made sure that part was right first, before polishing anything else.
Execution
I worked in small, checkable stages and confirmed the highest-risk part early rather than assembling everything at once.
Outcome
The delivery landed on time without needing a rework cycle afterward.
Lesson
Speed under pressure comes from a repeatable process, not from working faster in a panic.
A revision that could have spiraled
Situation
A client came back after delivery with general dissatisfaction, without pointing to anything specific that was wrong.
Challenge
Vague feedback can turn into an open-ended revision cycle if it isn't narrowed down first.
Approach
I asked which specific part wasn't landing, rather than guessing and revising broadly.
Execution
Once the actual issue was identified, I addressed only that, instead of reworking the whole piece.
Outcome
A single, focused revision resolved it, and the working relationship stayed positive.
Lesson
Most revisions are a communication problem before they're a technical one.
A repeat client with a different need
Situation
A client who'd worked with me before came back with a request that didn't fit the same shape as the previous project.
Challenge
It's tempting to reuse the previous approach on autopilot rather than treating the new request on its own terms.
Approach
I re-scoped the conversation from the start, as if it were a new engagement, rather than assuming the old terms carried over.
Execution
Pricing and expectations were reset explicitly for the new request before work began.
Outcome
The relationship continued rather than being strained by mismatched expectations from a previous project.
Lesson
Repeat trust is built by treating each new request as its own conversation, not by assuming it.
Running several engagements at once, alone
Situation
Multiple client engagements were active at the same time, with no team to divide the load.
Challenge
Without a shared system, details or deadlines are easy to drop when everything depends on one person.
Approach
I kept a simple, consistent way of tracking commitments and deadlines — the same instinct behind writing maintenance procedures, applied to running things on my own.
Execution
I sent short status updates on my own initiative rather than waiting for a client to ask where things stood.
Outcome
No deadlines were missed across concurrent engagements, without a team behind me.
Lesson
Working alone reliably depends on process discipline, not on effort or memory.
Day to day
Generative AI tools for the work itself — including prompt
development for AI image and video generation, and models like
ChatGPT, Claude, Gemini and Grok for research, documentation and
workflow support — plain documentation for keeping process and
commitments straight, and ordinary written communication for
everything client-facing. None of it is the point — it's what the
process above happens to run on.