Copy the text below and paste it into the relevant section of the Bonsai contract editor. This clause appears as Section 9.1 in all three contract templates.
The Client is solely responsible for the accuracy, legality, and compliance of all content published on the website, including but not limited to: professional credentials and license numbers, service descriptions and health-related claims, legal pages (privacy policy, terms of use, medical disclaimer), staff information, pricing, hours of operation, contact details, testimonials, and any content supplied by the Client or approved by the Client for publication. The Developer will publish content as provided or approved by the Client and does not independently verify the accuracy of factual claims, the validity of professional credentials, or the legal compliance of content. The Developer reserves the right to decline to publish content that the Developer determines in good faith creates legal, compliance, or reputational risk, and will notify the Client in writing of any such determination. The Client agrees to provide all required content — including copy, images, credentials, legal pages, and access to third-party accounts — within fourteen calendar days of the project kickoff date. Delays in content delivery extend the project timeline by an equivalent number of days and do not entitle the Client to a fee reduction. The Developer is not responsible for copywriting, photography, or legal page drafting unless these services are explicitly included in the agreed Scope of Work.
This clause does two things. First, it protects you from liability when a client publishes something inaccurate or legally problematic — you published what they gave you, not what you invented. Second, it creates a content delivery deadline that prevents the most common project delay: a client who agrees to provide their own content and then takes eight weeks to do it. Fourteen days is the standard. If they miss it, the timeline extends day for day and you have a written record of why.
When a client pushes back on the content deadline, explain it this way:
"I have scheduled this project in my calendar based on the kickoff date. If content arrives late, it pushes into time I have already committed to another client's project. The fourteen-day window gives you two weeks to gather what you need and gives me enough runway to build without a gap. If something comes up, just let me know early and we can adjust."
This clause appears as Section 4.3 in all three contract templates.
Payment is due on the date specified in the payment schedule. If payment is not received by the due date, the Developer will send a written reminder within two business days. If payment is not received within ten calendar days of the due date, all project work pauses automatically until payment is received in full. If payment is not received within fourteen calendar days of the due date, a late fee of 1.5% per month (18% per annum) is applied to the outstanding balance and accrues monthly until paid. Work resumes within two business days of confirmed payment receipt, including any accrued late fees. Time lost to a payment pause is not deducted from the project timeline — the original launch date extends by the number of days the project was paused. The Developer is not liable for delays, missed deadlines, or consequential damages arising from a project pause caused by late payment. For clients on monthly maintenance retainers, if a retainer payment is not received by the fifth of the month a written reminder will be sent. If payment is not received by the fifteenth, retainer services for that month are suspended. If two consecutive monthly payments are missed, the Developer reserves the right to terminate the retainer agreement with thirty calendar days written notice, at which point all passwords, credentials, and site access will be transferred to the Client within five business days.
The payment pause is not a punishment — it is a natural consequence built into the contract so you never have to make it personal. When a payment is late you send one friendly reminder within two days:
"Just checking in — the invoice for [milestone] was due on [date] and I haven't seen it come through yet. Let me know if there's anything on your end I can help sort out."
Warm, professional, no pressure. If ten days pass with no payment, you send a second note stating that you are pausing work per the contract while the invoice is outstanding, and that the launch date will shift by the number of days paused. You are not angry. You are not punishing them. You are following the agreement both parties signed. At fourteen days you add the late fee and state the new total in writing.
Most clients pay before the ten-day mark once they realize work has actually stopped — the pause is the enforcement mechanism, not the fee. The late fee exists to compensate you for the cost of carrying the outstanding balance and to create a financial incentive to pay promptly, but in practice you will rarely collect it because the pause clause does the work.
The retainer version is the same logic applied monthly: reminder on the fifth, suspension on the fifteenth, termination after two consecutive misses. Never let a retainer run two months behind without taking action — by the time you do, you are owed real money and the conversation is much harder.
This clause appears as Section 7 in all three contract templates.
A revision is any request to change, adjust, or rework design or content that has already been presented to the Client for review. Corrections to Developer errors — elements that do not match the agreed specification — do not count as revisions. This agreement includes three revision rounds, each tied to a specific project milestone. Round 1 occurs after the initial design and homepage are presented on the staging site. Round 2 occurs after all pages are built and content is populated. Round 3 occurs after Round 2 changes are applied. Each round requires all feedback to be submitted at once in a single written document — not across multiple emails or calls. Feedback submitted piecemeal after a round closes will be addressed in the next round, or quoted as additional work if no round remains. Once the Client approves a round in writing, that round is closed and the approval cannot be reversed. Design direction changes — requesting a different color palette, layout approach, or structural organization after a prior round has been approved — are out-of-scope regardless of rounds remaining and will be quoted as a change order. After all three rounds are used, additional revisions are billed at the Developer's standard rate with a one-hour minimum, payable before work begins.
Three rounds, three milestones, one batch of feedback per round — that is the whole policy. Round 1 is when you show the homepage and design direction on staging for the first time. Round 2 is when the full site is built and populated. Round 3 is the final pass after Round 2 changes are in. The Client gets one shot per round to compile everything they want changed and send it as a single document or email. If they send three separate emails over four days, only the first one counts for that round — the rest go into the next round or become a change order.
The thing that trips up most freelancers is the distinction between a revision and a direction change. A revision is "move this button to the right" or "change this headline." A direction change is "actually we want a completely different color scheme" or "can we redo the homepage layout." Direction changes are out-of-scope no matter how many rounds are left, because approving a design and then discarding it is not a revision — it is starting over.
When you explain the policy to clients before the project starts, say it this way:
"You get three rounds of feedback. Each round I need everything in one batch so I can work efficiently. Once you approve a round we move forward, so take your time reviewing before you send feedback. That way we stay on schedule and you get exactly what you want."
This clause appears as Section 6.2 in all three contract templates.
When the Client requests work outside the agreed Scope of Work, the Developer will respond in writing within two business days with a change order specifying the additional work, the fee, and any impact on the project timeline. No additional work begins until the change order is approved in writing by the Client and the additional fee is paid in full. If the Client requests changes that would require reworking completed deliverables — including design direction changes after a revision round has been approved — these are treated as out-of-scope regardless of revision rounds remaining and will be quoted accordingly. If the Client submits feedback that mixes in-scope revisions with out-of-scope requests, the Developer will complete the in-scope items and issue a separate change order for the out-of-scope items before proceeding. The project will be paused if a change order is not approved within seven calendar days of issue, or if an additional fee is not received within seven calendar days of approval. Work resumes within three business days of confirmed payment.
The moment a client asks for something outside the agreed scope — an extra page, a redesign of something already approved, a new integration, copywriting when they agreed to provide their own — you stop, write it down, and send a change order before touching it. The change order goes in a reply to the same email thread so there is a written record. It states three things only: what the additional work is, what it costs, and whether it affects the timeline. You do not negotiate the fee in the change order email — you state it. If they push back, you have a conversation, but you never start the work and negotiate simultaneously. That is how scope creep becomes free work.
If the change order sits unapproved for seven days, you send one follow-up. If it sits for another seven days after that, the project goes on hold per the pause clause. The pause clause is not a threat — it is a natural consequence you explain warmly and matter-of-factly:
"I want to keep the timeline on track so I am holding this section until we align on the change order. Happy to jump on a quick call if it is easier to talk through."
Most clients approve quickly when they understand the alternative is a delayed launch.
This clause appears as Section 8 in all three contract templates.
8.1 Project Pause — Client Unresponsiveness. If the Client does not respond to a Developer communication requesting feedback, decisions, or content delivery for twenty-one consecutive calendar days, the project will be placed on hold. The Developer will send a written notice on day fourteen advising that the project will pause if no response is received within seven days. Upon pause, the project is removed from the Developer's active schedule. When the Client is ready to resume, the Developer will schedule a restart based on current availability, which may result in a delay of up to four weeks before active work resumes. No refund of the deposit is available for projects paused due to Client unresponsiveness. Any third-party costs incurred during the pause period — hosting, domain renewals, plugin licenses — remain the Client's responsibility. 8.2 Project Pause — Developer-Initiated. The Developer reserves the right to pause a project if an invoice remains unpaid beyond fourteen calendar days, if the Client submits content that the Developer determines creates legal, compliance, or reputational risk and the Client declines to address the concern in writing, or if the scope of work changes materially without an approved change order. The Developer will provide written notice before initiating any Developer-initiated pause and will specify the condition required to resume. 8.3 Cancellation — By the Client. If the Client cancels the project after the deposit has been received, the deposit is non-refundable in all circumstances, as it represents compensation for scheduling, discovery, and work completed to date. If the second milestone payment has been received at the time of cancellation, a pro-rated credit for unbilled hours may be applied at the Developer's sole discretion based on work completed. If the final payment has been received, no refund is available. All work product created to date — including design files, page layouts, and written content — remains the Developer's property until the final payment is received in full. Upon cancellation, the Developer will deliver to the Client within ten business days a summary of work completed, any transferable file assets, and instructions for obtaining their own licenses for any tools or plugins currently active on the site. Cancellation must be submitted in writing to charles@charleshardt.com. 8.4 Cancellation — By the Developer. The Developer reserves the right to cancel the project with fourteen calendar days written notice if the Client repeatedly fails to meet payment obligations, submits content the Developer determines to be unlawful, engages in abusive or harassing communication, or materially misrepresents the scope or nature of the project during the sales process. In the event of Developer-initiated cancellation for any reason other than Client breach, the Developer will refund any payment received for work not yet completed, calculated on an hourly basis at the Developer's standard rate. Work completed and delivered prior to cancellation is non-refundable.
The pause clause is your most important protection against the most common freelance problem: a client who goes quiet for six weeks mid-project, then reappears expecting you to drop everything and finish immediately. The twenty-one day trigger is generous — it gives a busy client two and a half weeks to respond before anything happens. The day-fourteen warning letter is the mechanism that makes the clause fair: you are not surprising them, you are reminding them that the clock is running and giving them one week to come back before the consequences kick in. Keep that letter warm:
"I want to make sure we stay on track for your launch date. I have not heard back on [the specific item you need] and want to flag that per our agreement the project will go on hold on [date] if I do not hear from you before then. Happy to jump on a quick call if that helps move things forward."
Most clients respond within 24 hours of that letter.
The cancellation policy exists primarily to set expectations before they are needed. When you walk a client through the contract at kickoff, say the cancellation section out loud: "If for any reason you need to cancel, the deposit is not refundable because by the time you cancel I have already done the discovery work, cleared my schedule, and likely turned down other work to take yours. Everything I have built for you up to that point is yours once the final invoice is paid." Said clearly at the start, this clause never surprises anyone.
The Developer-initiated cancellation clause is the one you hope never to use. The abusive communication provision specifically is important — having it in the contract means you can end a relationship that is genuinely harmful to you without it being personal or negotiated. You are simply enforcing the agreement.
This clause appears as Section 10 in all three contract templates. Copy the full block below into Bonsai when the client is signing up for a maintenance retainer alongside a build project.
10.1 Scope of Maintenance Services. The Developer offers three monthly maintenance plan tiers: • Basic Maintenance ($150/month): WordPress core, plugin, and theme updates tested on a staging environment and applied to the live site monthly; daily automated backups stored off-site (Google Drive or Amazon S3); uptime monitoring with email alert; monthly security scan; monthly status email summarizing updates applied and backup status. • Standard Maintenance ($250/month): All services in Basic, plus up to one hour of content changes per month (text edits, photo replacements, hours updates, staff additions or removals); quarterly PageSpeed report; quarterly broken link scan and repair. • Premium Maintenance ($400/month): All services in Standard, plus up to two hours of content changes and minor design updates per month; priority response within 24 business hours on all support requests; monthly Google Analytics summary report. Content hours in Standard and Premium plans do not roll over to the following month if unused. 10.2 Retainer Billing and Cancellation. Retainer fees are due on the first of each month. If payment is not received by the fifth of the month, a written reminder will be sent. If payment is not received by the fifteenth, services for that month are suspended. If two consecutive monthly payments are missed, the Developer reserves the right to terminate the retainer agreement with thirty calendar days written notice. Upon termination, the Developer will deliver to the Client all credentials, access information, and documentation required to manage the site independently within five business days. Either party may cancel the retainer agreement with thirty calendar days written notice. No refund is available for the current month's retainer fee at the time of cancellation notice. 10.3 Scope Limitations. The monthly content hour allowance covers routine updates: text edits, image replacements, adding blog posts, updating hours and contact information, and minor formatting adjustments. It does not cover: new page creation, new feature development, plugin customization, e-commerce changes, design overhauls, or any work requiring more than the included hours. Work outside this scope will be quoted as an additional change order at the Developer's standard hourly rate. The Developer is not liable for plugin conflicts, third-party service outages, hosting provider issues, or security breaches originating outside the WordPress installation. The Developer will make reasonable efforts to resolve any issues that arise but cannot guarantee specific uptime percentages or response times beyond those stated in the Premium plan.
Present the maintenance plan at every project handoff, not as a hard sell but as a straightforward explanation of what the site needs to stay healthy. The framing that works best:
"WordPress needs monthly updates the same way a car needs oil changes. If you want to handle that yourself, I'll show you how. If you'd rather not think about it, I offer a monthly plan that covers everything — updates, backups, security, and a bit of time for small changes each month."
The most common objection is "I can do updates myself." Your response:
"You can, and I'll show you how. The risk is that plugin updates occasionally conflict with each other or with the theme, and if something breaks and you can't fix it, the site goes down until it's resolved. My plan covers updates on a staging copy first so the live site never breaks. But if you're comfortable managing it, that's completely fine."
Most clients on a retainer stay because of the peace of mind, not the hours. Always offer the retainer in the proposal, not just at handoff — a client who signs with the retainer included is more likely to stay on it long-term than one who adds it as an afterthought post-launch.
The contract clause below limits your HIPAA liability in writing. The handoff email creates a paper trail that you raised the issue at delivery.
Contract clause — appears as Section 3.1 in the Medical & Wellness contract:
The Developer is not a HIPAA Business Associate and does not provide HIPAA compliance consulting, legal advice, or technical safeguards for protected health information (PHI). The Client is solely responsible for ensuring that their website, booking systems, contact forms, and any third-party integrations comply with the Health Insurance Portability and Accountability Act (HIPAA) and any applicable state health privacy laws. The Developer will not store, access, transmit, or process PHI on the Client's behalf. Contact forms and intake forms built as part of this project are designed to collect name and phone number only. The Client agrees not to add form fields that collect PHI — including but not limited to symptoms, diagnoses, medications, insurance information, or dates of service — without first consulting a healthcare attorney and executing a Business Associate Agreement (BAA) with any applicable third-party service providers. The Developer will flag any content or functionality that appears to create HIPAA compliance risk, but this does not constitute legal advice and the Client bears full responsibility for compliance.
Handoff email — send as plain text at project close. Adapt [tool name] to the actual booking tool in use:
Subject: Your new site — a note on HIPAA and your contact forms Hi [Name], As we close out this project I want to put a few things in writing for your records. Your contact forms are currently configured to collect name and phone number only. This is intentional. If you ever want to add fields that ask about health conditions, symptoms, insurance, medications, or anything else that could qualify as protected health information (PHI) under HIPAA, please consult your healthcare attorney before making that change. Standard WordPress form plugins are not HIPAA-compliant by default, and adding PHI fields without the right safeguards in place creates legal exposure. Your booking and scheduling tool ([tool name]) handles patient appointment data on its own platform. If you have not already executed a Business Associate Agreement (BAA) with [tool name], I would recommend doing so — that is between you and them, but it is worth confirming. This note is not legal advice. I am a web developer, not an attorney. I am flagging these items so you have a written record that they were discussed. If you have any questions about any of this, your healthcare attorney is the right person to consult. Charles Hardt Hardt Web Development charleshardt.com · charles@charleshardt.com
Send this advisory note to every medical and alternative health client at handoff, regardless of whether you believe there are compliance issues. The note protects you by creating a documented record that you raised the issue. If a client later adds PHI fields to their forms without telling you, and a compliance issue arises, your written advisory demonstrates that you flagged the risk at delivery.
File the sent email in the client's Notion project row under Notes with the date sent. The pre-launch checklist for medical clients includes a checkbox for this — confirm it is ticked before closing the project.
The contract clause goes in Section 3.1 of the Alternative Health contract. The handoff email is sent separately at project close and logged in Notion.
The Developer is not a healthcare attorney, FTC compliance consultant, or licensed health professional. The Client is solely responsible for ensuring that all content published on their website — including service descriptions, health benefit claims, testimonials, before-and-after content, supplement descriptions, and practitioner credential listings — complies with applicable Federal Trade Commission (FTC) advertising guidelines, Food and Drug Administration (FDA) regulations, Virginia state licensing requirements, and any professional ethics codes governing the Client's licensed (or unlicensed) health practice. The Developer will publish content as provided or approved by the Client. If the Developer identifies content that appears to make unsubstantiated health claims, overclaim practitioner credentials, or violate applicable regulations, the Developer will flag the concern to the Client in writing before publishing. This flag does not constitute legal advice and does not transfer compliance responsibility to the Developer. The Client indemnifies the Developer against any claims, penalties, or damages arising from content the Client approved for publication.
Handoff email — send as plain text at project close. Remove the bracketed Virginia ND paragraph if not applicable:
Subject: Your new site — a note on health claims and content
Hi [Name],
As we close out this project I want to put a few things in writing for your records.
FTC guidelines require that any health benefit claims on your site be substantiated by competent scientific evidence. Guaranteed outcome language, absolute cure claims ("we eliminate," "we reverse," "guaranteed results"), and testimonials that imply specific health outcomes without disclaimers are potential compliance issues. If you add new service descriptions or testimonials to the site after launch, please review them against FTC guidelines before publishing — or have your attorney do so.
If you sell or promote supplements or herbal products, FDA regulations require that structure/function claims include the following disclaimer: "This statement has not been evaluated by the Food and Drug Administration. This product is not intended to diagnose, treat, cure, or prevent any disease." This disclaimer must appear on any page where a supplement benefit claim is made.
[For naturopathic practitioners in Virginia specifically:]
As we discussed, Virginia does not currently license naturopathic doctors. Your site reflects your credential accurately. If your scope of practice or licensing status changes, please update the site copy accordingly and consult your attorney about any disclosure requirements.
This note is not legal advice. I am a web developer, not an attorney or compliance consultant. I am documenting these items so you have a written record that they were discussed at project close.
Charles Hardt
Hardt Web Development
charleshardt.com · charles@charleshardt.com
Send this advisory to every alternative health client at handoff. Adapt the bracketed Virginia ND paragraph for the client's specific credential and licensing situation — include it for NDs, health coaches, and nutritionists; omit it for licensed acupuncturists and chiropractors who have cleaner regulatory standing.
File the sent email in the client's Notion project row under Notes with the date sent. If the client adds health claims to the site after launch that you notice during a maintenance retainer, flag them again in writing and document the flag.