These terms explain how MichaelPC proposals, scopes, changes, approvals, project data, third-party services, payment, handover, and liability boundaries are expected to work before paid delivery starts.
The client contracts with MichaelPC on the basis of the written proposal, quote, statement of work, and any linked schedules or attachments issued for the project. The accepted proposal pack should identify the contracting party details, project reference, and any formal notice details that apply to that engagement.
Starting or submitting a quotation request does not create a contract. A project starts only when MichaelPC issues a written proposal, quote, or statement of work, the client accepts it in writing, and any required deposit or first payment is received.
Unless a project document says otherwise, the intended precedence order is: accepted order form or proposal-specific statement of work, then these Terms, then any data-processing or project schedules expressly attached to that proposal pack. Client purchase-order wording, procurement terms, portal terms, or similar client-side terms are not intended to override that structure unless MichaelPC expressly agrees to them in writing.
Only the items listed in the accepted proposal are included. Anything not listed is out of scope unless both sides agree a paid change, follow-on phase, or revised quote. Discovery calls, rough design discussion, or launch advice do not by themselves expand scope unless the written project documents are updated.
Scope changes, extra pages, extra integrations, revised approval rounds, or materially changed source material should be handled through a written change request or updated proposal note. A change request should identify the requested change, the impact on fees, the impact on timing, and whether third-party costs are affected. MichaelPC is not obliged to start changed work until the revised scope and pricing are approved in writing.
The client is responsible for providing accurate content, pricing, approvals, brand assets, access credentials, legal claims, and timely feedback. The client remains responsible for the accuracy and legality of text, images, reviews, logos, trademarks, and public-facing claims supplied to the project, and should only provide material they own or are properly licensed to use. The client should not provide infected files, unlawful content, or material that they do not have the right to publish or process. The client also warrants that project instructions, source materials, and requested public claims do not knowingly infringe third-party rights or break the law, and should indemnify MichaelPC against third-party claims caused by client-supplied materials, instructions, or unlawful public claims.
MichaelPC relies on the client to provide working access to domains, DNS, hosting, email, or existing platforms where relevant. Approvals are required before launch, redirects, DNS changes, public copy, or production updates. The proposal or statement of work should define the acceptance criteria and any review window for the specific scope. Unless the project documents say otherwise, the client should report material defects against the agreed scope within a short written review window after delivery or launch, with enough detail for the issue to be checked against the agreed acceptance criteria. Where the client uses the deliverable in production, instructs launch, or does not raise material scope-based defects within that agreed review window, the affected deliverable may be treated as accepted. If a reported defect is confirmed to be a material scope mismatch, MichaelPC should be given a reasonable chance to correct it before stronger remedies are discussed.
Domains should normally be registered in the client’s own name or account where possible. If MichaelPC purchases or temporarily manages a domain on the client’s behalf, the proposal should state who owns it, who pays renewal fees, who receives renewal notices, who controls DNS, and what happens on handover or non-payment.
Hosting, email, DNS, domain renewal, mailbox storage, spam filtering, deliverability, SaaS tools, plugins, stock assets, external platform uptime, and any third-party API or AI provider remain subject to the relevant provider’s terms, pricing, and technical limits. Third-party costs are the client’s responsibility unless the proposal says otherwise. Failures, outages, suspensions, or policy changes caused by a third-party platform are not treated as a guaranteed-responsibility area for MichaelPC unless a different written support boundary is agreed.
Any AI support must have an approved use case, source material boundary, tool choice, hosting model, and review process. AI-generated text, chatbot answers, suggestions, or workflow outputs remain support material. MichaelPC does not guarantee that AI output is complete, accurate, lawful, or suitable for regulated use unless that is separately agreed in writing. If a project involves client data processing through AI or automation tools, the proposal pack should define the approved data boundary and any relevant processor/controller responsibilities.
MichaelPC can improve structure, technical setup, clarity, and launch quality, but does not guarantee rankings, traffic, enquiries, sales, deliverability, uptime, or business outcomes that depend on search engines, ad platforms, providers, or the client’s underlying offer.
Quoted pricing, deposits, milestone payments, expenses, and final-payment timing are set in the proposal or invoice. Unless a proposal says otherwise, quotes should be treated as time-limited and can expire if the scope, timing, or source material changes. Unless a written invoice says otherwise, invoices are expected to be paid within 14 days. For business-to-business projects, overdue invoices can attract statutory late-payment interest, fixed compensation, and reasonable recovery costs where applicable law allows that remedy. Work can be paused where invoices or agreed deposits are unpaid, and launch, handover, licence transfer, or administrator handoff can be held back until the due amount has cleared where the project documents say that boundary applies.
If a project is paused, cancelled, or materially delayed after work has started, MichaelPC may invoice for the work completed so far and for committed third-party costs already incurred. Deposits and first payments reserve delivery time and are normally non-refundable once project work or committed third-party purchasing has started.
Unless a proposal says otherwise, the client receives the final agreed deliverables for the paid scope after full payment clears. Pre-existing MichaelPC methods, internal templates, reusable tooling, prompts, workflow logic, design systems, and know-how remain MichaelPC property as background IP. MichaelPC can keep using its background IP, general know-how, and non-client-specific improvements across later work. Third-party assets, plugins, fonts, stock items, providers, and AI tools remain subject to their own licences and terms. The proposal or closeout notes should confirm the handover position for domain, DNS, hosting, email, credentials, and any third-party licences that the client must continue directly.
Both sides should protect confidential information shared for the project and use it only for the agreed engagement. Confidential material should only be shared with the people or providers who genuinely need it for the agreed work, and both sides should use proportionate security around credentials, access, and private project information. Where MichaelPC handles client project data beyond the public enquiry stage, the proposal pack or a separate data-processing schedule should state whether MichaelPC is acting as controller, processor, or an independent provider for that specific activity and what return/deletion expectations apply at closeout. If confidentiality or IP misuse creates urgent harm, either side can seek urgent injunctive relief without waiting for a longer dispute path to finish.
MichaelPC works with reasonable care and skill, but cannot accept responsibility for losses caused by client-supplied inaccuracies, delayed approvals, client-controlled account mistakes, or third-party platform failures outside the agreed control boundary. Unless a different written cap is agreed for the project, MichaelPC's total liability for a claim relating to the paid services is limited, to the extent permitted by law, to the fees the client actually paid for the affected scope. To the extent the law allows it, MichaelPC is not responsible for indirect or consequential loss, loss of profit, loss of revenue, loss of opportunity, wasted management time, reputational loss, or outcome-based losses tied to rankings, traffic, sales, deliverability, provider uptime, or other third-party platform behaviour. Nothing in these terms is intended to remove or reduce rights a client has under applicable UK consumer law or other applicable law, and nothing here excludes liability that cannot legally be excluded, including fraud or death or personal injury caused by negligence.
If there is a problem, the client should raise it promptly so it can be reviewed and resolved. MichaelPC should first try to resolve complaints through the normal project contacts, then through a short written escalation or without-prejudice discussion if needed. Formal project complaints, data-protection complaints, or notice-related issues should be recorded and acknowledged through the documented complaints or project process. The accepted proposal or statement of work should also state the operative notice route for formal project notices. Unless a written agreement says otherwise, these terms are intended to be governed by the law of England and Wales, with disputes handled exclusively by the courts of England and Wales except where urgent injunctive relief is sought for confidentiality or IP protection. The parties may also choose a short mediation or settlement step before litigation if that is practical for the dispute.