Cancellation and Complaints Policy
How to request changes, pause or cancel an engagement, and how DEVELOPMENT considers service concerns and possible refunds.
1. Scope of this policy
This policy covers requests relating to DEVELOPMENT’s remote software development and digital services. It provides a general approach to cancellations and complaints. The written proposal, statement of work or maintenance agreement may contain additional terms suited to the engagement. Mandatory legal rights remain available and are not removed by this policy.
Preparing a brief in the public browser form does not create a contract or payment obligation. A locally generated reference code does not reserve work, start a subscription or trigger a cancellation fee. A formal engagement begins only through the acceptance steps identified in the applicable agreement.
2. How to make a request
Send a cancellation, pause or complaint request to projects@developmentdigitalsoftware.com. Include your name, business, the relevant project or invoice identifier if one exists, a clear description of the issue and the outcome you are seeking. If you prepared a browser reference, explain when and how the brief was actually shared so we can locate received correspondence.
Use an authorized contact for requests that change a business engagement. We may ask for proportionate confirmation of identity or authority before disclosing project information or changing access. Avoid including passwords, full payment card details, private API keys or unrelated personal information in your request.
3. Before work begins
If you want to cancel before work starts, contact us as soon as possible. We will review what has been agreed, whether any preparatory work has already been carried out and whether an approved non-cancellable third-party commitment has been made for the project. A scheduled start date is not, by itself, evidence that every prepaid amount has been earned.
Unused advance payments should be distinguished from charges for documented work and approved commitments. Any deduction should be explainable against the agreement and work actually performed. This policy does not declare all deposits or advance payments automatically non-refundable.
4. After project work has started
A request to stop an active project should identify whether you want an immediate pause, a revised scope or termination. We will assess the current stage, completed work, work in progress, access arrangements and any dependency on client or third-party action. Where practical, we will confirm a stopping point that avoids creating an unnecessary operational risk.
The financial review should account for fees properly due for completed work, reasonable documented work in progress and approved non-cancellable commitments, subject to the agreement and applicable law. Any remaining unused advance payment can then be assessed for refund. We should explain the basis of the calculation rather than apply an unsupported blanket deduction.
5. Pauses and rescheduling
A temporary pause can be appropriate when requirements, content, approvals or access are not ready. The parties should record what is paused, what remains accessible, any necessary maintenance activity and how the project can restart. A pause does not automatically guarantee that the same delivery slot will remain available indefinitely.
If a pause changes dependencies or requires work to be revisited, the scope, cost and schedule may need review before resumption. A client should be told about material proposed changes before additional work is authorized. We will aim to distinguish genuine restart work from work already included and paid for.
6. Consulting sessions and maintenance plans
For a scheduled consulting session, request a change as early as possible. Any specific rescheduling window or cancellation charge must be communicated in the booking or engagement terms. A completed session is generally treated as delivered work, while unused prepaid time should be assessed according to the agreement and applicable rights.
A maintenance plan should identify its billing period, included work, renewal arrangements and cancellation notice if one is required. To stop future billing, submit the request before the next period under those agreed arrangements. Cancellation does not automatically include a migration, a new feature, emergency remediation or third-party subscription cancellation; those tasks should be separately identified.
7. Complaints and useful evidence
If you are dissatisfied with work, describe the agreed requirement, what occurred, when it occurred and the effect on your project. For a technical issue, include reproduction steps, the affected environment and screenshots or logs where appropriate. Redact sensitive information and do not send credentials in the complaint.
We aim to acknowledge a clear complaint within five business days and provide a substantive update within twenty business days where reasonably possible. These are handling targets, not a promise that every technical issue can be resolved in that period. If more information, testing or third-party input is needed, we should explain the next step and expected update.
8. Assessment and possible outcomes
The review considers the written scope, approvals, delivery history, available evidence and any corrective work already attempted. A reproducible failure to meet an agreed requirement is different from a new feature, a change of preference or a defect introduced by an unrelated modification. That distinction helps identify a suitable response without dismissing a valid concern.
Depending on the circumstances, an outcome may include clarification, correction, re-performance of affected work, a revised plan, a fee adjustment, a partial refund, termination or another agreed remedy. We do not guarantee a particular outcome before reviewing the facts. Any statutory remedy that applies remains available even if it differs from a commercial proposal.
9. Refund handling and third-party charges
If a refund is approved, we will confirm the amount, the reason and the intended payment method. Where practical, refunds should use the original payment channel or another verified arrangement. Payment processors and banks control their own posting times, so the date funds appear may be later than the date a refund is initiated.
Third-party costs must be considered separately from DEVELOPMENT service fees. A provider may have its own refund rules, but we should identify the relevant commitment and whether any credit or refund can be obtained. A claim that a charge is non-cancellable should be supported by the actual arrangement and prior approval where required.
10. Access, handover and unresolved concerns
On an agreed ending of work, the parties should address access removal, client-owned accounts, deliverables available for handover, outstanding fees and any remaining obligations. Ownership or licensing of work follows the project agreement. A cancellation should not be used to justify retaining access that is no longer authorized or exposing confidential information.
If you believe a concern has not been adequately addressed, reply to the written outcome and identify the point that remains unresolved. We will consider further relevant evidence. You retain the ability to seek independent advice or use any complaint, payment or legal process available under applicable rules. This policy does not require you to waive a non-waivable right.
Contact DEVELOPMENT
Email: projects@developmentdigitalsoftware.com
Address: 88 Inverness Cir East, Englewood, CO 80112
Phone: +19432385407