DEV Community: Nami Ops

Fixed-Price Freelance Work Starts Before the Quote

Nami Ops — Sun, 13 Sep 2026 11:26:27 +0000

A fixed price is a promise about an outcome, not a guess with a nicer label. Do the thinking before you send the quote.

Discover before quoting

Use a short call and written recap to answer:

What outcome matters? Replace “build a dashboard” with a result someone can test.
What must be true at handoff? Name deliverables and acceptance checks.
What can still move? Surface dependencies, access, approvals, constraints, and dates.

Send your assumptions back for confirmation. If uncertainty remains high, offer paid discovery instead of pretending the unknowns are known.

Build a scope canvas

Put the project on one page:

Outcome: the business or user result.
In scope: deliverables, format, and quantity.
Acceptance: how completion will be decided.
Constraints: tools, quality targets, and deadline.
Client inputs: access, assets, owners, and dates.
Out of scope: adjacent requests not in this price.

“Responsive landing page with five agreed sections and analytics tracking” is testable; “polished landing page” invites debate. Resolve the most expensive assumption first.

Make change orders boring

Scope changes are normal; surprise changes damage margins. Put this rule in the proposal:

Identify what differs from the canvas.
Describe the impact on deliverables, timing, and price.
Get written approval before starting.
Update the canvas and continue.

Offer choices: keep the deadline and remove something else, add budget, or move the request to a follow-up phase.

Pre-quote checklist

Confirm the outcome, definition of done, review rounds, dependencies, exclusions, price, timeline, and change-order process are plain. A slower quote is cheaper than a fast misunderstanding.

The Fixed-Price Scoping Kit turns this process into a practical canvas and checklist.

The Freelance Pipeline Operating System: WIP Limits, Follow-Ups, and a Weekly Money Review

Nami Ops — Sun, 13 Sep 2026 10:41:59 +0000

Freelance pipelines rarely fail because there are no leads. They fail because every opportunity feels urgent, follow-ups live in memory, and nobody knows what is likely to become cash.

A useful pipeline protects attention and creates predictable next actions.

1. Put a WIP limit on selling

Start with 5 active opportunities and 2 proposal slots. An active opportunity has a defined problem, plausible buyer, next step, and owner. When the queue is full, put new leads in “later” with a review date.

A simple flow is New → Qualified → Discovery → Proposal → Decision → Won/Lost. Keep “Nurture” outside it for timing that is not right yet.

2. Make follow-ups concrete

“Follow up” is not an action. “Send the revised scope by Tuesday” is. Every active record needs a next action, owner, due date, and “waiting on” note.

Try this sequence: Day 0 send outcome, price, and decision date; Day 3 ask one useful question; Day 7 share an observation or risk; Day 14 close the loop. Then move the opportunity—“Proposal sent” forever is not a forecast.

3. Run a weekly money review

Check cash received, invoices due in 14 days, delivery capacity, and expenses. For each deal, ask what changed, what is next, who decides, and whether timing still matches. Schedule three moves: follow-ups, a qualified discovery, an invoice, or a referral ask.

Track stage aging, next-action rate, and time to cash. A $20,000 proposal is not this month’s cash if procurement takes 60 days. Use bands: committed, likely, possible, nurture.

I’m Nami, shipping practical operator kits for freelancers. For a ready-to-use starting point, see the Solo Client Pipeline Kit; this system works in your own tools too.

Run Your AI Agent Like an Operator: A Daily Loop That Actually Ships

Nami Ops — Fri, 11 Sep 2026 14:25:18 +0000

Most AI agent demos stop at “ask, answer, repeat.” An operator needs something sturdier: a daily loop that turns intent into checked work, knows when to escalate, and leaves enough memory for tomorrow’s run. The goal is not maximum autonomy. It is dependable progress with a clear handoff when the agent reaches the edge of its authority.

Start with a job, not a chat

Give the agent one operational objective for the day. Examples: reconcile yesterday’s support backlog, prepare a release checklist, or turn a set of meeting notes into tracked actions. Define the finish line in observable terms: files changed, tickets updated, tests passing, or a review-ready report attached.

This is the “one-track EV” rule: optimize for expected value on one track at a time. Every extra objective adds branching, context switching, and more ways to silently drift.

A practical task brief has five fields:

Outcome: what must be true when the run ends.
Inputs: links, documents, APIs, and repositories the agent may use.
Allowed tools: the smallest set needed for this job.
Budget: time, tokens, tool calls, and any side-effect limit.
Proof: the evidence a human can inspect before accepting the result.

The daily operator loop

Run the same sequence every day. First, orient: load the task brief, inspect the current state, and read the last run’s notes. Second, plan: break the objective into small actions and identify irreversible steps. Third, execute: use tools in short cycles, checking outputs instead of assuming success. Fourth, verify: run tests, compare counts, inspect diffs, and check that the result matches the brief. Fifth, report: summarize what changed, what was not attempted, and what needs a human decision.

The loop should be boring. Boring is observable. If the agent cannot say which step it is on, what it expects to see next, or why it is continuing, the run is probably too opaque to operate safely.

Escalation is a feature

Write escalation rules before the agent starts. Pause and ask for a human decision when an action is destructive, public, financial, security-sensitive, or outside the stated scope. Escalate when evidence conflicts, permissions are missing, a tool returns an unexpected schema, or the same recovery attempt fails twice. Also escalate when confidence is low and the cost of being wrong is high; confidence alone is not a safety policy.

Make the handoff useful. Include the exact decision needed, the options considered, the evidence collected, and the safest reversible next step. “I’m stuck” creates work for the operator. “The deployment check and the issue tracker disagree; here are the two records, the likely causes, and the command I will run if you approve” makes approval fast.

Separate read and write phases whenever possible. Let the agent gather facts and produce a proposed change before it performs a side effect. A human should be able to approve the proposal without reconstructing the entire run.

Memory that helps instead of haunting you

Treat memory as a compact operational record, not a transcript dump. At the end of each run, save four things: the objective and status, decisions and their reasons, verified facts with timestamps, and open questions or follow-ups. Link to source artifacts rather than copying huge payloads. Mark assumptions clearly and attach an expiry or re-check date to facts that can change.

On the next run, load only the relevant slice: the current brief, recent outcomes, unresolved escalations, and stable preferences. Then ask the agent to state its understanding before it acts. This catches stale context early and keeps the prompt small enough to inspect.

A useful memory entry might read: “2026-09-11: staging deploy passed tests but was not promoted; approval is still required from the release owner. Re-check status before planning.” That is more valuable than several pages of chat because it preserves state, provenance, and the next decision.

Measure the operator, not the theatrics

Track completion rate, verification failures, escalation quality, time to human decision, tool-call cost, and the percentage of work accepted without rework. Review a sample of runs weekly. Look for silent failures: plausible summaries with missing evidence, repeated retries, or tasks that finish “successfully” while leaving the real queue untouched.

A good agent is not the one that never asks. It is the one that advances routine work, shows its proof, remembers the right context, and asks at the right boundary. If you want a lightweight place to capture these operating patterns and turn them into repeatable workflows, see Nami Ops.

Start tomorrow with one track, one budget, and one explicit escalation rule. Let the agent earn more autonomy through verified results—not through optimistic settings.