SF

Signal Foundry

Public Refund And Reschedule
Offer Page Public Links Hub Public Command Center Public Terms Public Teardown Public Retainer Public Deposit Lock Public Payment Guide Public Payment Follow-Up Public Kickoff Public Balance Collection Public FAQ Payment

Public policy page

Show cancellation, rescheduling, and payment-change rules before money moves.

This page keeps the default commercial handling visible before a buyer pays: what happens before kickoff starts, what changes once work begins, how rescheduling should be written, how scope changes are separated from refunds, and how payment issues stay in one written thread. If a specific deal uses different rules, write them before payment instead of assuming them later. If the buyer wants a lower-risk paid first step before a bigger sprint, the teardown is often the cleaner route than arguing about refund edge cases on the full package. If the real need is ongoing support on a live asset, a bounded retainer can be cleaner than turning every timing change into a sprint-cancellation debate.

  • 1 written thread for policy changes
  • Pre kickoff changes stay flexible
  • Start work begins after confirmation
  • Same wallet route when payment still moves
1. Write The Starting Condition Put scope, deposit logic, and kickoff condition in writing before payment. Open Public Terms
2. Separate Pre-Kickoff From Started Work The cleanest refund or reschedule decisions depend on whether work actually started. Open Public Deposit Lock
3. Route The Next Move Clearly Either keep payment active, move to teardown, move to retainer, move to balance close-out, or rewrite the next sprint explicitly. Open Payment Page

Policy Map

Use one visible sequence for refunds, reschedules, and payment changes.

1. Before Kickoff Starts, Rewrite The Path In Writing

If payment landed but kickoff has not started and no work has begun, the clean default is to reschedule or agree a written payment adjustment instead of letting the thread drift. Network fees or completed admin steps are not part of an automatic reset.

Open Public Terms Open Public Deposit Lock

2. Once Kickoff Starts, The Deposit Covers Reserved Capacity

After kickoff begins, the deposit is attached to reserved time, started work, and the agreed sprint boundary. The default next move is to finish, tighten inside scope, or rewrite remaining work in writing instead of treating started work as unused credit.

Open Public Kickoff Open Public Scope Boundary

3. Rescheduling Needs A Written New Window

If timing changes, ask before the reserved sprint window opens. Once that window is already active, the delivery queue may need a new position rather than the same priority.

Open Public Deposit Lock Open Public Terms

3B. Use Teardown If The Buyer Wants A Lower-Risk Paid Start

If the buyer wants to reduce upfront risk before the fuller sprint, move into the teardown: one workflow, $299 total, $90 deposit, same wallet route, and a smaller commercial commitment.

Open Public Teardown Open Public Terms

3C. Use Retainer If The Payment Path Changes Into Ongoing Support

If the sprint is no longer the right shape because the real job is steady optimization or upkeep on something already live, rewrite the lane as a retainer instead of forcing a refund fight over the wrong package shape.

Open Public Retainer Open Public Renewal

4. Revisions Stay Inside Boundary While New Scope Becomes New Work

One light tightening can stay inside the original sprint. A new deliverable, new workflow, or new bottleneck is not a hidden refund debate. It is a new scope discussion.

Open Public Scope Boundary Open Public FAQ

5. Payment Problems Stay In One Written Thread

If the amount, asset, network, or receiving address is in question, keep the fix in writing with the tx hash, project name, amount, and wallet route. Wrong-network transfers can delay confirmation and may not be reversible.

Open Public Payment Guide Open Public Payment Follow-Up

6. Delivered Work Closes Through Approval And Balance

After delivery, the clean path is approval, one light revision if needed, then remaining balance through the same wallet. A new bottleneck after delivery becomes a fresh sprint instead of a refund fight over completed work.

Open Public Balance Collection Open Payment Page

6B. Ongoing Work After Delivery Becomes Retainer, Not Refund Logic

If the buyer is not disputing delivered work but wants steady support after launch, the clean move is a retainer lane rather than re-litigating the original sprint terms.

Open Public Retainer Open Public Balance Collection

Short Lines

Keep the policy easy to send without turning it into a legal essay.

Pre-Kickoff Line

If kickoff has not started, I would rather rewrite the timing or payment handling clearly than let the deal drift.

Started Work Line

Once work starts, the deposit covers reserved capacity and the sprint already in motion.

Reschedule Line

If timing changes, I want that written before the reserved window opens so the queue stays honest.

Payment Issue Line

If there is a payment problem, keep it in one written thread with the tx hash, network, and amount instead of guessing.

Lower-Risk Start Line

If the full sprint still feels like too much commitment, I can start with one paid teardown first instead of forcing the bigger package and then arguing about refund edge cases.

Retainer Instead Line

If the real need is recurring support on something already live, I would rather rewrite the path as a retainer than argue about changing a sprint into the wrong shape.

Wallet

When payment still moves, keep the same wallet route visible.

Refund and reschedule clarity works best when the payment route is explicit too. If the commercial path changes, write it before another transfer instead of improvising after funds move. The same wallet can also take the $90 teardown deposit when a smaller paid start is the safer move, or the first retainer month when the lane shifts into ongoing support.