Agree custom development work before it starts

Custom development needs a shared understanding of what will be delivered, what your business must provide and what the agreed price covers.

Start with the outcome

Describe the job you need to complete, who will use it and the systems involved. Qcom first needs to assess whether an existing feature or integration can meet the need. See Setup support and custom integrations.

An initial discussion is not approval to start development or a guarantee that the requested work is possible.

Review the proposal

Before agreeing to a quote, ask for the following to be clear in the written proposal:

• Deliverables: what will be built, where it will work and what is excluded.
• Your contribution: required information, permissions, provider accounts, test data and decisions your team must supply.
• Price and payment: what the quote includes, when payments are due and which external costs are separate.
• Timing: milestones, dependencies and how delays will be communicated.
• Acceptance: who will review the result, how it will be checked and how problems will be reported.
• Ongoing support: what maintenance, updates and post-delivery assistance are included or separately charged.
• Ownership and access: the rights to use the work, access to source code or other deliverables, and any third-party licence restrictions.

Ask about any missing item before approving. Do not assume that paying for development transfers all intellectual-property rights, includes source code or provides unlimited maintenance. Those terms need to be agreed for the project.

When the request changes

Describe the new requirement and ask how it affects the agreed deliverables, price and timeline. Confirm any revised proposal before additional work starts. A support conversation about a possible change is not approval of a new quote.

Keep the agreed version and the decisions made during review so both teams can check what is included.

Review delivery

Use the acceptance steps agreed for the project. Check the intended user journey, the resulting information and any required handover material. Report differences from the agreed deliverables with examples.

A demonstration is not automatically acceptance, and acceptance does not establish maintenance or ownership terms that were never agreed. Use the project's written agreement for those decisions.

When work cannot proceed

Your team has not supplied a required item. Confirm what is missing, who will provide it and any effect on the schedule.

The request depends on an unsupported service or unavailable approval. Ask for the available alternatives before assuming custom code can remove the restriction.

The delivered work does not meet the agreed requirement. Report the difference through the agreed project contact and review process. Check the project's agreement for any warranty period, available remedy and response arrangements.

For the initial request, continue with Get help from the Qcom team. For external costs, see Understand Qcom and third-party charges.