Delivering work and submitting milestones

Getting paid is a consequence of submitting well. A submission is not just the artefact — it is the artefact plus enough context that a non-technical client can tell it does what they asked for. Most revision requests are not quality problems; they are comprehension problems.

Before you start: requirements

The client owes you requirements after funding, with a grace period of 7 days by default. If they have not arrived, ask in the workspace and keep asking there rather than starting on guesswork — the written request is what protects you if the deadline later becomes contentious.

What to attach

• The deliverable itself, in the workspace. Not by email, not on a personal drive link — the workspace record is what a dispute reads.
• A short note on what you built and what you decided, especially anywhere the requirements were ambiguous.
• Proof it works: a screenshot of a successful run, a test result, a short recording.
• What the client needs to do next, if anything, and what you need from them.

When a revision comes back

Separate two things: work that misses the agreed requirements, and work the client has changed their mind about. The first is yours to fix inside the included rounds. The second is a new milestone, a custom offer, or a paid extra revision round — and saying so plainly, once, is far better received than absorbing it silently and resenting it.

If it goes wrong

You have the same escalation route the client does. If a client refuses to approve work that meets the agreement, or goes silent while withholding requirements, open a dispute — the decision is made on the workspace record, which is precisely why you kept everything in it.