Charging the way the deal was actually closed
Cord already charges deposit-and-balance, and in even installments. What's missing is the real case for projects and implementations: payments tied to milestones, not a uniform calendar.
What we're building:
- Milestone schedule: define each stage with its name, its percentage or amount, and its condition ("on design delivery", "at production start"), instead of splitting the total into equal parts.
- Event-based release: a milestone's charge unlocks when that milestone is marked complete, not when an arbitrary date arrives.
- Visible to the client: the public link shows the full schedule: what is paid, what is next, and what remains, without anyone explaining it over email.
- Mid-flight adjustments: a project that changes scope should be able to renegotiate pending milestones without breaking the ones already charged.
Why it isn't here yet:
A milestone that can be charged before it's met is a money problem, not an interface one. The right order is the condition and its evidence first, the payment button second.
How it works
Define the name, amount or percentage, and condition for every milestone.
The client sees the full schedule and each stage status.
Payment unlocks when the condition is confirmed and retains evidence of the change.
Availability and scope
Future initiative for projects, construction, and implementations that do not fit deposit, balance, or even installments.
Clear limits
A milestone cannot be charged merely because a date arrived when its condition is unmet. Scope changes must preserve what has already been collected.