Payment Terms — the rules of an engagement, plainly.

1. Who I am

Philip Sloth, based in Esbjerg, Denmark (postcode 6700). Contact: [email protected]. CVR-registration as an enkeltmandsvirksomhed is in preparation but not yet completed; until then there is no business CVR-number on the invoice and this section will be updated the day registration completes. The future business will be operated as an enkeltmandsvirksomhed (sole proprietorship), but is not currently operated as one. Where in this document I say "I", I mean Philip Sloth as the person responsible for the engagement (operating today without a registered virksomhed; future enkeltmandsvirksomhed once CVR is issued).

2. Services

I provide custom web-development services on a project basis: scoping, design, implementation, deployment, and handoff of websites, web applications, and related digital deliverables. The exact deliverables for each engagement are defined in a Statement of Work (SoW) — typically an email exchange or signed PDF — that records scope, milestones, and price.

Items not in the SoW are out of scope unless agreed in writing as a separate engagement. This includes (without limitation): post-handoff edits, ongoing maintenance, additional features, content writing, asset creation, training, and SEO consulting.

3. Pricing & VAT

Prices are stated exclusive of VAT unless explicitly marked otherwise. The applicable VAT regime, once moms-registered, depends on your location and status:

For invoices in a foreign currency, the DKK equivalent of any VAT is calculated using the Danmarks Nationalbank rate at the time of invoice or — for Stripe payments — the actual conversion rate Stripe applied. The methodology is consistent within a financial year.

3.1 How I handle B2B vs B2C in practice

Before generating any payment link in my admin dashboard, I classify every engagement as either B2B (business customer) or B2C (private consumer). It's not optional or a default — the system requires me to pick explicitly before a URL can even be generated. The classification drives both VAT treatment once moms-registered(see the current-state callout above for the pre-registration treatment that applies today) and which consumer rights apply (independent of registration).

3.2 What “VAT” (moms) actually means in practice

VAT (Value Added Tax, Danish “moms”) is a consumption tax the government levies on almost all sales of goods and services. The standard Danish rate is 25%. As the seller, I collect VAT on behalf of the state and remit it to SKAT every quarter or half- year. From your perspective as a customer:

• B2B customers can typically deduct the VAT in their own VAT return — making it a net-zero transaction VAT-wise, as long as your business is VAT-registered. The 25% is a cash-flow item, not a cost.
• B2C customers cannot deduct VAT. The 25% is a real cost on top of the price.
• EU B2B with valid VAT number: 0% VAT — reverse charge. You calculate and account for the VAT in your own country. My system verifies your VAT number against the EU VIES database before checkout.
• Non-EU customers (B2B and B2C): 0% — Danish VAT law doesn't apply to trade outside the EU. You're responsible for any local tax or duty in your own jurisdiction.

3.3 When VAT applies — the registration threshold

In Denmark, VAT registration is voluntary below a turnover of DKK 50,000 per rolling 12-month period. If I'm below that threshold and haven't registered voluntarily, I add no VAT. The invoice / receipt then shows a single line with the total and a footnote noting that the issuer is operating below the DKK 50,000 moms-registration threshold (and, as long as CVR-registration is still in preparation, that fact too). You can't deduct VAT because there's none to deduct. When I cross the threshold — or choose to register voluntarily — all new invoices automatically switch to the full §58 layout with the VAT breakdown. Earlier invoices keep their original classification, since retroactive VAT isn't allowed.

4. How I bill — deposit, final, and single payment

Two billing models, picked per engagement and stated in the SoW:

• 50% deposit + 50% final. The default for projects above ~10,000 DKK. Deposit is due before work begins; final balance is due on delivery. Each phase is sent as its own payment link (labelled "DEPOSIT" and "FINAL" on the bridge and in the receipt email).
• Single payment. Used for smaller projects, fixed-fee tasks, or when the client requests it. One payment link, one charge, one receipt.

The deposit secures my production capacity for the engagement, covers initial scoping and research, and is non-refundable once I confirm the project start in writing — see § 7 for the full refund rules and the exceptions reserved for consumer customers.

Payment methods accepted: card (Stripe), MobilePay (DKK / EUR / SEK / NOK where eligible), Apple Pay / Google Pay, Klarna and Bancontact where Stripe enables them, and bank transfer for invoices over 25,000 DKK on request. Stripe processing fees are absorbed by me unless the SoW states otherwise.

For business customers paying on invoice (not on a payment link): payment is due 14 days from the invoice date unless otherwise agreed. Late payments accrue interest at the rate set out in the Danish Interest Rates Act (Renteloven), currently the National Bank's lending rate plus 8 percentage points for B2B, plus reasonable reminder fees.

4.4 Hosting subscription terms

When the engagement is structured as a recurring hosting subscription rather than a one-shot project, the rules below apply alongside the rest of these Payment Terms.

What's included. The subscription covers deployment, configuration, monitoring, and reactive fixes on the infrastructure I operate (typically Cloudflare Pages, Workers, R2, Supabase, and Resend on accounts under my control). New features, design changes, scope additions, and content updates beyond minor adjustments are out of scope and quoted as separate engagements.

Hosting account ownership during the subscription. The hosted service runs on my Cloudflare account and on any related vendor accounts (database, email, etc.) that I provision for the project. You do not need to create, fund, or maintain any hosting accounts during the subscription — that is the whole point of this offer.

Cancellation. You may cancel the subscription with thirty (30) days' notice for B2B customers; the consumer cancellation rights under Forbrugeraftaleloven § 28 apply for B2C customers. On the effective cancellation date:

• The hosted service stops at the end of the then-current billing period.
• I provide the project's source repository (typically GitHub) as a courtesy for your records and any self-managed continuation. The repository is provided as-is.
• I am not obligated to assist with, plan, or execute migration of the project to your own infrastructure or a third party's infrastructure. That work falls outside the subscription scope.
• Customer-owned data (form submissions, uploads, database rows, transactional records) is exportable on request during the subscription and for fourteen (14) days after cancellation. Beyond that window, data is retained only as required by Danish law — most notably Bogføringsloven § 12 (5-year accounting record retention) — and is not available for export.

Migration assistance — separately billed. If you wish to keep the project running on your own infrastructure (or a third party's) after cancellation, migration is available as a separately billed engagement. The fee is a flat amount, agreed in writing in advance and determined by the complexity of the stack, the number of services to be transferred, and the documentation level required. Migration assistance is not included in any subscription tier and is not committed to a fixed price schedule — every migration is quoted per case.

Note on platform constraints. Cloudflare does not currently support direct transfer of Pages projects, Workers, R2 buckets, KV namespaces, or D1 databases between accounts. Migration in practice means recreating these resources on your account and copying the data over. This is industry-standard for cloud platforms and is not specific to this engagement; the same constraints exist on AWS, Vercel, Netlify, and similar providers when changing the controlling account.

Infrastructure cost pass-through. The hosting subscription covers infrastructure up to the free-tier capacity of the underlying providers used to deliver the service (most commonly Cloudflare for hosting and edge compute, Supabase for database and authentication, Resend for transactional email, and similar). The specific usage thresholds applicable to your engagement are documented in your Statement of Work and reflect what comfortably fits within these free tiers.

Where actual usage exceeds the free-tier capacity of an underlying service — for example, a database growing past its included size limit, transactional email volume crossing the included monthly quota, or storage exceeding the included allowance — the upstream provider's paid-plan cost is billed through to you at cost, with at least seven (7) days' advance notice. No markup is applied to these pass-through charges; the original provider receipts are available on request. The subscription is not automatically suspended on overage. I notify you first, agree the path forward together (accept the pass-through, upgrade tier, or scope down usage), and adjust only after that conversation. The intent is predictable cost behaviour — you are never surprised by a charge.

Account-wide platform costs that are not directly attributable to any single customer — for example, Cloudflare's account-level Workers Paid plan when the total volume across all hosted projects crosses the free tier — are absorbed by me as the cost of running the hosting service and are not passed through to individual customers.

Stack flexibility. The default stack used by my hosting subscriptions — Cloudflare-first edge hosting, Supabase for backend services, Resend for email — is what most projects use because it works well for the Danish small-business market and keeps operational costs near zero at low traffic. It is not the only stack I work with.

If you would prefer a different stack — AWS, Google Cloud, Vercel, DigitalOcean, Hetzner, self-hosted on your own VPS, or anything else — message me via the contact form before signing the Statement of Work and we will scope the engagement around your stack instead. Pricing and operational details may differ from the default-stack subscription tiers, but the same principle of free-tier coverage with pass-through billing for overages applies regardless of stack. I am not locked into a single technology choice — the stack should serve your project, not the other way around.

4.5 Hourly and ad-hoc work

Work that falls outside any signed Statement of Work or active subscription is billed at an hourly rate. The current rate is DKK 700 per hour, exclusive of any applicable VAT, billed in 30-minute minimum increments. Half-day (4 hour) and full-day (8 hour) blocks may be quoted at a small discount for predictable engagements. Work performed outside ordinary business hours — defined as 08:00–18:00 Europe/Copenhagen, Monday through Friday excluding Danish public holidays — is charged at a 50% surcharge.

Examples of work typically billed under this section:

• Content updates beyond minor adjustments to a hosted site
• Bug investigations on a project after the warranty period (§ 8) has expired
• New features or scope additions on an existing project that were not in the original Statement of Work
• Technical advice, design review, or pair-programming sessions
• One-off tasks unrelated to a continuing engagement

The hourly rate is reviewed annually. The rate in effect on the date a piece of work is agreed in writing applies for that work, regardless of any subsequent rate change. Where you have an active subscription or active project, the rate stated in the Statement of Work or subscription terms takes precedence over the published hourly rate above.

4.6 Suspension and termination for non-payment

When a recurring subscription payment fails, Stripe automatically retries the card up to four (4) times over fourteen (14) days. During this retry window the service continues uninterrupted; the customer receives Stripe's dunning emails with a card-update link.

The following timeline applies, measured from the original payment due date:

• Day 7 — Personal reminder email from me, with a card-update link and a clear statement of the suspension and termination dates that follow if the payment is not cured.
• Day 14 — Final notice email. At this point Stripe has exhausted its automatic retries.
• Day 21 — Service suspension. The hosted application is replaced with a maintenance page or returns HTTP 503; data and configuration remain preserved. The customer may still log in to update the payment method and may restore service by completing payment at any point during the next thirty (30) days.
• Day 51 — Termination. If the account remains unpaid thirty (30) days after suspension, the agreement is terminated. I provide a final source-code export and data archive available for fourteen (14) days, after which the project resources are removed from my infrastructure.
• Day 65 — Final deletion. Project resources are deleted from my Cloudflare, Supabase, R2, and any other vendor accounts under my control. Records required by Bogføringsloven § 12 (invoices, receipts, transaction records) are retained for five (5) years from the end of the relevant fiscal year per Danish accounting law and the legal-obligation carve-out in GDPR Article 17(3)(b), and cannot be deleted on request during that period.

For one-shot project engagements where a final-payment invoice fails, the same Day 7 / Day 14 reminder and final-notice timeline applies. Final-stage deliverables and access credentials may be withheld until payment is received, but no separate suspension or termination process applies because there is no ongoing service to suspend. Outstanding amounts older than thirty (30) days may be referred to a Danish debt-collection agency at the customer's expense, with prior written notice.

Suspension or termination under this clause does not waive my right to recover unpaid amounts due under any prior period. Late-payment interest continues to accrue per § 4 (Renteloven) for the entire outstanding period.

Termination by me. I may terminate any engagement (project or hosting subscription) with thirty (30) days' written notice for any reason, with a pro-rata refund of any prepaid amount covering the post-termination period. I may terminate immediately, without refund, where: (a) you materially breach the Acceptable Use Policy at § 16 and do not cure within the period stated there; (b) you engage in abusive, threatening, or discriminatory conduct toward me or anyone working with me; (c) continuing the engagement would put me in violation of law, sanctions, or any underlying-provider Terms of Service that I cannot reasonably negotiate; or (d) your use of the hosted service damages other hosted clients or the stability of my infrastructure. In any termination by me under this clause, I will provide a final source-code export and customer-data archive available for fourteen (14) days, on the same terms as a customer-initiated cancellation under § 4.4.

5. Delivery

A deliverable is considered delivered when I send the deliverables and access credentials by email or hand them over via a shared repository / dashboard. You then have 7 days to raise written objections; after that period without objection, delivery is deemed accepted and the warranty period (§ 8) begins.

Acceptance unlocks two things in your favour: your right to use the deliverables fully, and (where applicable) the start of the warranty period. It also closes the engagement for refund purposes — see § 7.

5.1 Intellectual property and ownership

Source code, design files, copy, and other deliverables created specifically for your project under a Statement of Work transfer to you upon final payment of the engagement in full (deposit + final, or single payment as applicable). Until that point all rights remain with me, but I grant you a non-exclusive, non-transferable licence to use the in-progress deliverables solely for the purpose of reviewing them within the engagement.

The following are excluded from the transfer:

• Pre-existing tools, libraries, components, and code I bring into the engagement (e.g. my own reusable components, templates, deployment scaffolding, working repositories). I retain the rights to those, but grant you a perpetual, royalty-free, non-exclusive licence to use them as part of the delivered project.
• Third-party open-source dependencies — these remain governed by their own licences (MIT, Apache-2.0, GPL, etc.) and are not part of this transfer. Their licence terms travel with the code.
• Skills, know-how, methodology, and general patterns I learn or refine during the engagement — I remain free to apply them to other projects, subject to the confidentiality obligations in § 12.

If final payment is not made — for example, the engagement is cancelled mid-project and the deposit is forfeited under § 7 — no IP transfer occurs and you may not use the partial work product commercially. Where you have paid for and received an interim deliverable that stands on its own (e.g. a completed design phase or milestone invoice), the IP for that specific deliverable transfers on payment of its corresponding invoice. The remaining unpaid work-in-progress remains my property.

Default rule under Danish copyright law (Ophavsretsloven § 53) is that copyright remains with the developer unless explicitly transferred in writing. This § 5.1 is that explicit written transfer; payment of the final invoice is the trigger.

6. Consumer rights — 14-day right of withdrawal

If you are a consumer (forbruger) within the meaning of Danish law — i.e., you are buying for purposes outside your trade, business, craft, or profession — you have a 14-day right of withdrawal under Forbrugeraftaleloven from the date the contract is concluded (typically: the date you pay the deposit or single payment), without giving any reason.

However, for digital services begun with your consent, this right can lapse earlier under Forbrugeraftaleloven § 18, stk. 2, nr. 13. When you are paying via a B2C-flagged payment link, the Stripe checkout iframe shows a separate mandatory dropdown labelled "Fortrydelsesret (Forbrugeraftaleloven §18)" with two options, in the exact statutory wording:

• Waiver: "Jeg ønsker at arbejdet påbegyndes straks, og jeg accepterer at jeg dermed mister min fortrydelsesret efter Forbrugeraftaleloven §18, stk. 2, nr. 13"
• Preserve: "Jeg ønsker at beholde min 14-dages fortrydelsesret (arbejdet starter først efter perioden er udløbet)"

You must pick one before the Pay button activates. Your choice + the timestamp is captured by Stripe, persisted on the transaction row, and confirmed in writing in the receipt email — that email serves as the "durable medium" required by §18 stk. 4. If you select waiver, your right of withdrawal lapses for the work that has begun and you will not be entitled to a refund for work already completed. If you select preserve, work will not begin until the 14-day period has expired.

If you have not given that consent, your full 14-day right stands. To exercise it, send a clear statement (an email is enough; a copy of the standard withdrawal form linked at forbrug.dk may also be used) to [email protected] before the 14 days expire. I will refund all sums paid within 14 days of receiving your withdrawal notice.

For business customers (B2B), the 14-day right of withdrawal under Forbrugeraftaleloven does not apply. Capturing your CVR number / EU VAT ID at checkout is the cleanest evidence of B2B status; provide it during the bridge checkout or in your initial enquiry.

7. Refunds, deposits, and chargebacks

Deposits. The 50% deposit is non-refundable once I confirm the project start in writing. The deposit secures my production capacity, covers initial scoping and research, and is forfeited if you cancel the engagement after that point. This is consideration for real reserved time and work — not a penalty.

Final / single payments. Once the deliverable has been delivered (§ 5), the corresponding payment is non-refundable for the work actually delivered. If you reasonably believe the deliverable does not conform to the agreed specification, raise written objections within the 7-day acceptance window and I will repair or, at my election, refund the affected portion under the warranty (§ 8).

Consumer rights preserved. Where you are a consumer, your statutory 14-day right of withdrawal (§ 6) and your 2-year mangelsansvar (legal warranty) under Købeloven and the Digital Content Directive apply regardless of the rules above; these statutory rights cannot be waived to your detriment.

Chargebacks. Before initiating a chargeback with your card issuer, please contact me at [email protected] so we can resolve the issue directly. Most disputes that escalate to a chargeback turn out to be miscommunications I would happily resolve. I retain delivery audit logs (timestamps, IP address, user-agent at checkout, deliverable handoff records, milestone sign-offs, the version of these Payment Terms you accepted) and will provide them as evidence to the card network if a chargeback for delivered work proceeds. A successful chargeback for work I have delivered and that you have accepted may result in additional recovery of the disputed amount plus reasonable legal fees.

8. Warranty

Business customers (B2B). For 30 days from delivery, I warrant that the deliverable will substantially conform to the agreed specification. Your exclusive remedy for non-conformity is, at my election, repair, replacement, or a refund of the fees paid for the affected deliverable. Wear and tear caused by ongoing third-party service changes (e.g. a Cloudflare Workers API breaking change three months after handoff) is not a warranty defect.

Consumer customers (B2C). You have the statutory rights of a consumer under Købeloven and the Danish implementation of the Digital Content Directive, including the right to have material defects remedied within a reasonable time. These rights cannot be waived. Material defects that surface during the 24-month statutory period should be reported as soon as practicable.

9. Limitation of liability

To the maximum extent permitted by law and in accordance with Danish commercial contract practice, my total cumulative liability under or in connection with an engagement, regardless of the cause of action, is limited to the total fees paid by you to me under that engagement in the twelve (12) months preceding the event giving rise to the claim.

I am not liable for any indirect, incidental, consequential, or special damages, including (without limitation): loss of profits, loss of revenue, loss of data (where data preservation is not a primary contractual obligation), business interruption, loss of opportunity, or reputational damage.

Nothing in this clause limits or excludes liability that cannot be limited or excluded under mandatory Danish law: personal injury, gross negligence, intentional misconduct, fraud, or any mandatory consumer-rights protection. For consumer customers, your statutory rights apply notwithstanding anything in this section.

10. Third-party services and post-delivery costs (read this carefully)

Most modern web projects depend on third-party services that have their own billing relationships, including (without limitation): hosting and edge compute (Cloudflare Pages, Workers, R2, KV, D1, DDoS protection), database (Supabase, PostgreSQL providers), email (Resend, Postmark), payment processing (Stripe), domain registration (Cloudflare Registrar, Gandi, etc.), authentication (Supabase Auth, Auth0, Clerk), AI / ML APIs (OpenAI, Anthropic), file storage (S3, Cloudflare R2), and analytics. These services are run by independent companies under their own terms.

Unless explicitly agreed in writing as a managed-service arrangement, the following applies:

• You sign up for the third-party services in your own name and on your own payment method. Where I provision the service, the account is created with your details and transferred to your control before delivery — never run on my credit card "to be settled later".
• From the delivery date forward, all ongoing third-party service costs are your sole responsibility. By accepting delivery of the project (whether explicit acceptance or by elapse of the 7-day acceptance window — § 5), you acknowledge that you, not Philip Sloth, are responsible for any subsequent invoices, overages, plan upgrades, auto-renewals, or other charges from those providers.
• I am not responsible for changes in third-party pricing, service availability, plan tiers, or terms of service after handoff. If, for example, Cloudflare changes its Workers pricing, Supabase deprecates a feature, or your traffic exceeds a free tier and the provider auto-bills you, this is between you and the provider.
• Spending caps and budget alerts. On every project handoff I document, where the provider supports them, the spending caps and budget alerts I have configured. Where a provider does not offer a hard spending cap (notably Cloudflare, which offers only informational alerts), this is documented in the handoff. After handoff you are responsible for monitoring usage, configuring or adjusting alerts, and rotating credentials. Adding budget alerts after handoff is part of your operational ownership of the service.
• Philip Sloth has no continuing financial obligation in respect of any third-party service after the delivery date. Any claim that a post-handoff bill should be paid by Philip Sloth will be declined unless (a) the bill arises from work done before handoff and not yet invoiced, or (b) it arises from an explicit managed-service contract.

A signed handoff acknowledgement at delivery — listing each third-party service used in the project, the account holder of record, the spending cap and budget alerts configured (where available), the auto-renewal status of any annual plan, and the exact date and time at which liability transfers — is the standard artefact for projects above ~25,000 DKK and is available on request for any engagement. The handoff document follows a fourteen-section template covering project identity, source-code transfer, domain and DNS, infrastructure inventory, a fifteen-item credential rotation checklist, deployment runbook, monitoring and incident response, compliance obligations (GDPR, bookkeeping retention, consumer-protection law), known issues and technical debt, backups and disaster-recovery posture, and a countersigned acceptance block. The structure is deliberately designed so that the next operator (whether you take the project in-house or hand it to another developer) can take full ownership independently — without ongoing dependence on me — within the transition support window stated in the handoff itself. The template is publicly viewable on request so you know exactly what level of documentation you are receiving.

11. Force majeure & third-party outages

I am not liable for delays, failures, or non-performance caused by events outside my reasonable control, including (without limitation): outages, performance issues, or contractual changes affecting Cloudflare, Supabase, Stripe, Resend, domain registrars, internet service providers, energy supply, government action, natural disaster, or pandemic. If such an event materially delays the engagement, I will notify you and we will agree a revised timeline in good faith.

12. Confidentiality

Definition. "Confidential Information" means any non-public information disclosed by either party to the other in connection with an engagement, in any form (oral, written, digital, or visual), and whether or not marked as confidential. This includes business plans, customer lists, internal data, strategies, source code, configuration, security details, financial information, and any other information a reasonable recipient would understand to be confidential given the nature of the information and the circumstances of disclosure.

Mutual obligation. Each party agrees to use the other's Confidential Information only for the purpose of the engagement, to protect it with the same degree of care it uses for its own confidential information of similar importance (and in no event less than reasonable care), and not to disclose it to any third party except to my contractors or sub-processors who have a need to know and are bound by equivalent confidentiality obligations.

Carve-outs. The confidentiality obligation does not apply to information that: (a) is or becomes publicly known through no breach of this clause; (b) was lawfully in the recipient's possession before disclosure; (c) is independently developed by the recipient without reference to the other party's Confidential Information; (d) is lawfully received from a third party without confidentiality obligation; or (e) is required to be disclosed by law, regulation, court order, or a regulator with binding authority — in which case the disclosing recipient will, where lawfully permitted, give prior written notice to allow the other party to seek a protective order or equivalent relief.

Duration. Confidentiality obligations under this clause survive termination of the engagement and continue for five (5) years from the date of disclosure; for information that constitutes a trade secret under Lov om forretningshemmeligheder, the obligations continue for as long as the information remains a trade secret.

Return or destroy. On termination of the engagement, each party will, on the other's written request, return or securely destroy all Confidential Information in its possession, except: (i) one archival copy retained for record-keeping and legal-defence purposes; and (ii) records I am required by law to retain (notably bookkeeping records under Bogføringsloven § 12 — see § 4.4 + § 4.6 for retention specifics).

Marketing reference. I may reference the engagement publicly (in my portfolio at philipsloth.com, on social media, in conversations with prospective clients) at a high level — name, sector, and high-level scope only — beginning thirty (30) days after the engagement starts. Before the engagement, you may opt out of all marketing reference by saying so in writing in the Statement of Work; in that case I will treat the engagement as confidential. For engagements where you require explicit pre-approval before any reference, flag this at Statement of Work time and I will treat marketing reference as opt-in (i.e., I will not publish anything without your written approval of the specific entry).

Formal NDA. If your organisation requires a formal mutual non-disclosure agreement on its own paper, say so before the engagement starts and I will sign one on reasonable terms (matching or stricter than this § 12). The clause above stands as the default where no separate NDA is signed.

13. Governing law & disputes

These Payment Terms are governed by Danish law. The Danish courts have exclusive jurisdiction over any dispute, save that a consumer's right to bring proceedings in their country of residence under EU consumer-protection law is preserved.

For consumer disputes, you have access to the Danish public consumer-complaints system: Center for Klageløsning and onwards to Forbrugerklagenævnet, subject to their jurisdictional limits and fees ( forbrug.dk ). The European Online Dispute Resolution platform is available at ec.europa.eu/consumers/odr. Before initiating any formal procedure, please email me; most disputes resolve quickly outside any forum.

14. Acceptance & record

You accept these Payment Terms by paying any invoice or completing any Stripe Checkout session. Acceptance is recorded together with the timestamp, the IP address used at checkout, the user-agent string, the version of these Terms in force at that moment, and the corresponding Stripe receipt number / charge ID. A copy of the Terms in force at any historical payment is available on request.

When these Terms change, the "last updated" date below is updated. Material changes affecting active engagements are notified by email. Your continued engagement after the notification constitutes acceptance of the changes; for historical payments, the version in force at the time of payment governs.

15. Severability & entire agreement

If any provision of these Terms is held by a court to be unenforceable, the remaining provisions remain in full effect. These Terms, together with the Statement of Work for the engagement and the Privacy Policy, constitute the entire agreement between us in respect of the subject matter and supersede any prior understandings.

16. Acceptable use of hosted services

Hosted services run on accounts under my control (Cloudflare, Supabase, Resend, and similar). What gets hosted on those accounts therefore directly affects me, my other hosted clients, and the underlying providers' continued willingness to serve me. This Acceptable Use Policy defines what is and is not allowed under any hosting subscription.

When end-user personal data is processed on accounts under my control, I act as data processor on your behalf within the meaning of GDPR Art. 28. The substantive Art. 28(3) clauses (documented instructions, sub-processor authorisation, security measures, breach notification, audit rights, return or deletion at end of services) are set out in the Data Processing Agreement. The actually-binding DPA is co-signed at the start of any engagement that involves processing your end-users' personal data on my infrastructure.

You may not, and may not allow your end-users to:

• Upload, host, transmit, link to, or otherwise serve: (i) content unlawful under Danish or EU law; (ii) content infringing a third party's intellectual property rights; (iii) child sexual abuse material; (iv) malware, phishing kits, credential-harvesting pages, or stalkerware; (v) content promoting violence, terrorism, or imminent illegal activity; (vi) content violating Markedsføringsloven (Danish Marketing Practices Act) or comparable EU consumer-protection law.
• Use the hosted service to send unsolicited bulk email (spam), credential-stuffing or brute-force attacks, denial-of-service attacks against any third party, or otherwise act in violation of the Cloudflare, Supabase, Resend, or Stripe Terms of Service in force at the time.
• Operate a service in a regulated industry — financial services, gambling, cryptocurrency exchange or token sale, adult content monetisation, prescription pharmaceuticals, firearms sales, money services businesses — without prior written agreement, since these may trigger account-level review or termination by the underlying provider regardless of my preferences.
• Attempt to circumvent or disable any security control, rate limit, or authentication mechanism I have configured on your project, except where I have agreed in writing for you to do so.
• Reverse-engineer, decompile, or attempt to extract source code from any tooling I provide that is not part of the deliverables transferred under § 5.1.

If I have a good-faith belief that hosted content or activity violates this AUP, or threatens the legal standing or operational stability of my infrastructure or other hosted clients, I may suspend the affected service immediately, with written notice to you and a fourteen (14) day cure period — unless the violation is severe enough to require immediate takedown under applicable law (for example, child sexual abuse material, a court order, or a valid notice-and-takedown request under the EU Digital Services Act). In severe cases I may take down the affected content or service without prior notice and notify you afterwards. Repeated or uncured violations are grounds for termination per § 4.6 (Termination by me), without refund.

You indemnify me, on a fee-paid basis, against any third-party claim, regulatory action, or account-level penalty imposed on me by an underlying provider as a direct result of your hosted content or your or your end-users' use of the hosted service. This includes reasonable legal fees, the cost of recovering or migrating affected services to a new account if I am suspended by an upstream provider because of you, and any loss of revenue from other hosted clients caused by such a suspension. The liability cap in § 9 applies in your favour as the operator (limiting my liability to you), but does not limit your indemnification obligation under this clause.

Contact

Questions about these Payment Terms — or anything in them you want explained before you pay — email me at [email protected]. I'd rather have the conversation now than after a payment has cleared.