1. Confirm Payment Landed
Verify the deposit reached the correct wallet and network before treating the sprint as active.
Open Public Payment Follow-Up Open Payment PagePost-payment kickoff page
After payment, keep kickoff compressed so work starts instead of drifting.
Once the deposit is confirmed, the next step is simple: send the tx hash, project name, short brief, and any relevant links in the same thread. That is enough to confirm scope and begin the sprint. If the buyer is not actually ready for the full-sprint startup packet yet, do not fake kickoff discipline. Reset to the teardown as the smaller paid first step instead. If the paid lane is really ongoing support on something already live, route into the retainer instead of pretending a fresh sprint kickoff packet is the right shape.
- 1 tx hash required
- 1 usable startup packet
- 24h target kickoff confirmation
- 72h standard sprint framing
Kickoff Map
Use one repeatable sequence from confirmed payment into active work.
2. Collect The Minimum Startup Packet
Ask for the tx hash, project name, short brief, and only the links that matter to the current scope.
Open Public Tx Hash Open Startup Packet3. Keep Scope Narrow
Kickoff should confirm the paid package, not reopen the whole sales conversation or widen the delivery boundary.
Open Public Approval Open Public Pricing3B. Use Teardown Instead If The Full Kickoff Is Not Ready
If the buyer still cannot support the full startup packet or full sprint discipline, do not drag a larger package through weak kickoff. Reset to the teardown and keep the paid start smaller.
Open Public Teardown Open Public Terms3C. Use Retainer Instead If The Paid Lane Is Ongoing Support
If the buyer already has a live asset and the paid work is really steady upkeep, optimization, or monthly operator support, do not force a new-sprint kickoff packet. Move into the retainer lane.
Open Public Retainer Open Public Renewal4. Name The Owner Route
If questions or assets need approval, identify one decision owner so execution does not stall across multiple people.
5. Start Fast, Then Ship Inside The Sprint
Target a kickoff confirmation within 24 hours after the startup packet arrives. The standard framing stays a short sprint, usually around 72 hours once scope is clear.
6. Use FAQ Only For Remaining Friction
If payment, timing, or revision questions keep coming back, send the FAQ once instead of rewriting the same answers in chat.
Open Public FAQ7. After Delivery Approval, Close Out Through Remaining Balance
When the sprint is shipped and the only next move is the last transfer, route to balance collection instead of reopening scope.
Open Public Balance Collection Open Public Scope BoundaryStartup Packet
Ask for the smallest packet that still lets execution start cleanly.
Minimum Packet
tx hash
project name
chosen tier
brief or short summary
relevant URLs
decision owner
Short Buyer Reply
Payment is in. I just need the tx hash, your project name, a short brief, and the links that matter so I can start.
Network Note
Preferred asset is USDC on Base. If the payment used Ethereum instead, include the network and asset in the same kickoff note so confirmation stays clean.
Not Ready Yet Line
If we are not actually ready for the full sprint kickoff packet yet, I would rather reset to one paid teardown than start a larger sprint on weak inputs.
Retainer Instead Line
If the paid work is really a recurring live-support lane, I would rather package it as a retainer than fake a fresh sprint kickoff.
Kickoff Route
Use the same wallet route across approval, payment, and kickoff.
Consistency is what removes post-payment doubt. Keep the wallet, preferred network, and startup request identical everywhere the buyer can see. The same wallet can also take the $90 teardown deposit if the route needs to step back to a smaller paid start, or the first retainer month if the lane becomes ongoing support.