and <meta description> using the content. for each page containing relevant keywords (often "Business Name – Page Title" format).
Skip to main content

Fincher Labs Products & Services Operations Manual

Internal Use Only — Fincher Labs Confidential

Document Control

  • Document Title: Fincher Labs Products & Services Operations Manual
  • Document ID: FL-OPS-001
  • Version: 1.2
  • Last Updated: 2025-08-10
  • Author: Fincher Labs Team
  • Status: Draft
  • Distribution: Internal (Fincher Labs Staff and Contractors Only)
  • Approver: Fincher Labs Operations Manager

Alignment Standard: This manual is governed by the five core principles in fincher-manifesto-FINAL.md — Build, Reuse, Repeat; Iterate & Accelerate; Underdog Advantage; AI‑Augmented Engineering; Transparent, Simple & Fair.

Change Log

VersionDateAuthorChanges
1.22025-08-10Fincher LabsAligned content with Company Manifesto: added principle-aligned policies, AI guardrails, reuse/automation mandates, updated KPIs, and clarified pricing/hosting transparency.
1.12025-08-10Fincher LabsConverted to Markdown per styleguide; cleaned bullets, headings, ToC, and artifacts.
1.02025-08-09Fincher LabsInitial consolidated release of manual.

Table of Contents

1 Introduction

This operations manual serves as the single source of truth for all Fincher Labs products, services, and internal processes. It outlines what we offer to clients, how we deliver our projects, and the standards and policies we uphold. The purpose of this document is to ensure every team member – from sales to development – works with consistent information and a clear playbook. By consolidating product details, pricing, workflows, and policies, we can provide a seamless and professional experience to our clients.

Scope: This manual covers the core website development package and related add-on services Fincher Labs provides. It details each offering's public-facing description (what we advertise to clients) alongside the internal scope, process, and deliverables required to fulfill it. It also includes operational guidance such as sales scripts, technical standards, quality checklists, support procedures, and company policies (e.g. payment terms, turnaround times, and customer communication guidelines).

Audience: The document is intended for internal use by Fincher Labs staff. This includes sales representatives, project managers, designers/developers, and support personnel. New team members should use it as a training guide, and existing team members should reference it for up-to-date information on how we run our product offerings and client engagements.

How this manual aligns with our Company Manifesto

  • Build, Reuse, Repeat: Every project must produce at least one reusable asset (template, component, prompt, or workflow). We assemble from a shared component bank first, then create net-new only when necessary.
  • Iterate & Accelerate: We capture lessons within 48 hours of launch, apply the 3x Trigger (if we do it 3 times, we automate it), and commit to weekly process refinement.
  • Underdog Advantage: We optimize for essentials that matter to small businesses — speed, affordability, clarity — and keep scope realistic to deliver results fast.
  • AI‑Augmented Engineering: We use AI for first drafts and scaffolding; humans own decisions, quality, and brand alignment. AI increases speed without lowering our quality bar.
  • Transparent, Simple & Fair: Clear inclusions/exclusions, turnaround expectations, pricing, hosting policies, and a practical revision/support approach.

Guiding Principles (Operationalized):

  • Speed & Consistency: 3–5 business days standard; 24‑hour rush when feasible with a defined readiness checklist.
  • Clarity & Scope Control: Written scope, one major revision round included, minor polish allowed, change orders for larger scope.
  • Automation-First: Use Zoho, n8n, and templates to reduce manual work and errors.

All team members are expected to be familiar with the contents of this manual. If there is any discrepancy between what's written here and older materials, this manual takes precedence as the most updated reference. In case of doubt or a unique situation not covered here, escalate to the Operations Manager for guidance and ensure any new decisions are added to the next revision of this document.

2 Service Offerings Overview

Fincher Labs currently offers a set of website design/development services and related support services tailored for small businesses and entrepreneurs. Our services are modular – the Core Website Package forms the foundation, and clients can add on extras like rush delivery or professional email setup as needed. We also provide post-launch support options and a referral incentive program for client referrals.

How we deliver this value: intelligent assembly and reuse. We build once and deploy many times through a growing library of templates, components, prompts, and automations. This compound advantage sustains our speed and affordability for small businesses without compromising quality.

The table below summarizes our main products, services, and programs along with their pricing (in USD):

Service OfferingPriceDescription (Summary)
Core Website Package$350 one-timeComplete business website (~5 pages), custom-branded, mobile-responsive, basic SEO, contact form, launch.
Rush Delivery Add-On (expedite)+$150 (add-on)Accelerated 24-hour turnaround vs. standard 3–5 days. Requires Core Website Package.
Professional Email Setup — Zoho Mail$50 one-timeSetup of a professional @yourdomain email using Zoho Mail (budget-friendly for small businesses).
Professional Email Setup — Google/Microsoft$125 one-timeSetup of Google Workspace (Gmail) or Microsoft 365 (Exchange). Client pays provider subscription fees.
Pay-As-You-Go Website Updates — Minor$50 per updateOn-demand small tweaks (e.g., text changes, single image swap).
Pay-As-You-Go Website Updates — Major$100 per updateLarger updates (e.g., new page/section or feature) without a maintenance contract.
Remote Support (Basic)$25 per incidentAd-hoc assistance during business hours (e.g., email configuration, troubleshooting).
Remote Support (Extended)$40 per incidentUrgent or after-hours support; for immediate attention or complex incidents.
Client Referral Bonus — Standard$50 credit/referralReward for referrals that lead to a new Core Website Package sale.
Client Referral Bonus — Promotional$100 credit/referralOccasional promo period doubling of the standard bonus.

Notes: All website projects include domain setup assistance and a standard 60-day support window after launch at no extra charge. We aim for a 3–5 day turnaround on the Core Website Package (from the time we receive all required content and deposit), which is dramatically expedited to ~24 hours if the Rush Delivery Add-On is purchased. There are no ongoing monthly fees for hosting the basic website – the site is deployed on our cloud infrastructure with no recurring hosting charge to the client (the client only needs to pay their domain's annual renewal and any email service subscription if applicable). If resource usage or feature set materially changes (e.g., traffic spikes or dynamic features), we will discuss options transparently — no surprises.

The sections below provide detailed descriptions of each offering, including what we advertise publicly to clients versus what is done internally to deliver the service. This ensures our team understands both the marketing angle and the execution details.

3 Detailed Service Descriptions

3.1 Core Website Package ($350)

3.1.1 Overview

The Core Website Package is our flagship offering: an affordable, professionally assembled website for small businesses, priced at a flat $350 (within our standard $250–$400 range depending on workload and scope). It is positioned as a turnkey solution for clients who need a web presence

quickly and without hassle. This package covers a standard informational website (typically up to ~5 pages of content).

3.1.2 Inclusions

  • Intelligent Assembly: Site is assembled from our proven template and component library, custom-branded to the client. This reuse enables speed and affordability without sacrificing quality.
  • Basic SEO Setup: Proper page titles, meta descriptions, clean URLs, and submission to Google for indexing.
  • Domain & Launch Support: We connect the site to the client's domain and get it live; we guide domain purchase/configuration if needed.
  • Quick Turnaround: Standard delivery time is 3–5 business days once we have content and deposit.
  • Post-Launch Support: 60 days included for fixes and minor tweaks.
  • Data Privacy: No PII stored on our servers by default; forms email directly to the client.
  • AI‑Assisted Copy (Optional): We can transform client-provided bullets into site-ready copy using AI with human editing.

3.1.3 Deliverables

  • Website Pages: Up to ~5 pages (e.g., Home, About, Services, Gallery/Portfolio, Contact).
  • Responsive Implementation: Layouts tested across common devices and browsers.
  • Contact Form: Configured with Cloudflare Turnstile; submissions email directly to the client.
  • Basic SEO Metadata: Page titles and meta descriptions set for all pages.
  • Domain Connection and SSL: Connected to the client’s domain with HTTPS enabled.
  • Handoff Materials: Concise guide with links and credentials; XML sitemap if applicable.

Revision Cycle: One major revision round included after initial draft; minor polish allowed thereafter. Larger scope changes require a change order or are handled as paid updates.

Deliverables to Client: Live website at client domain; optional code/asset handover on request; a concise handoff guide with links, credentials (if any), and support instructions.

AI Usage Guardrails: Any AI-generated text or imagery must be human-reviewed for factual accuracy, tone, and brand alignment before delivery.

Payment & Closure: 50% deposit to start; 50% at launch. Final deliverables contingent on final payment received within agreed terms.

Reuse Requirement (Internal): Each project must nominate at least one asset to productize (template section, component, prompt, or workflow) and record it for the library.

In summary, the Core Website Package is designed to be a quick, value-packed website offering. Internally, it's important we stay within the defined scope so that these projects remain profitable and quick-turn. Any additional requests should either be funneled into the initial build as minor tweaks or directed to our post-launch update services (so we don't endlessly iterate beyond the $350 scope). Clear communication with the client from the outset (what's included, timeline, content needs, etc.) ensures the project stays on track.

3.2 Rush Delivery Add-On (+$150)

3.2.1 Overview

The Rush Delivery Add-On is an optional service clients can purchase in addition to the Core Website Package to guarantee a 24-hour turnaround for their website, once rush readiness is met. This caters to urgent launches (events, campaigns, openings). The add-on costs an additional $150 on top of the base package price.

Rush Readiness Checklist (starts the 24h clock): content delivered; brand assets/logos provided; domain access confirmed; approvals channel established; deposit received.

3.2.2 Inclusions

scenarios like: preparing for a trade show or ad campaign and needing a landing page quickly, or an upcoming business launch with a tight deadline. The add-on ensures they won't miss their critical timeline.

Internal Scope & Implementation: - Feasibility & Scheduling: Confirm capacity and scope (<~5 pages; low complexity). Decline rush if we cannot meet it. - Client Preparedness: Rush timer starts only when readiness checklist is met; reflect this in quote terms. - Team Coordination: Assign focused resources; allow extended hours if needed. - Development Approach: Use boilerplate/templates; reuse components; prefer stock assets if gaps exist; test continuously. - Communication & Updates: Keep a rapid response channel open. - Limited Revision Window: Minor tweaks only during 24h; schedule non-essential revisions post-launch (support or paid update). - Contingency Planning: If delay is our fault, refund rush fee; if client-caused, rush guarantee is void (documented in terms). - After 24h Launch: Aim to go live within the window and transition into the standard support period.

walk them through the result quickly since they might not have expected such speed. After launch, the project goes into the normal 60-day support period like any other. If the client has additional adjustments (that couldn't be done in the 24h window), we can do those as part of the support if they're small, or as paid updates if larger – use judgment, considering they paid a premium already; we want them satisfied.

In essence, the Rush Add-On is about managing priorities and expectations. Internally, everyone must be clear that once we commit to rush, that project is top priority until completion. The extra $150 helps cover any overtime or disruption costs, but it's also about delivering excellent service in a pinch, which can turn a one-time client into a long-term advocate. Always ensure the quality doesn't drop – rushing should never mean a sloppy website. Follow our checklists even under time pressure (perhaps with an extra set of eyes if possible to catch mistakes). A successfully executed rush project can be showcased as a win for Fincher Labs and often results in referrals (e.g., "I got a website in one day!" is something clients will excitedly tell others).

3.3 Professional Email Setup

In addition to websites, we offer professional email setup services so that clients can have email addresses at their custom domain (e.g., name@yourbusiness.com ). This adds credibility to their business communications (as opposed to using generic Gmail/Yahoo addresses). We have two tiers for email setup, depending on the platform the client prefers: Zoho Mail or Google Workspace/Microsoft 365. The service involves configuring the domain's DNS and the email hosting service, creating the initial mailbox(es), and ensuring the client can send/receive emails with their new address.

3.3.1 Zoho Mail Setup ($50)

Zoho Mail is an affordable (often free for a basic plan) email hosting solution suitable for small businesses. We charge a one-time $50 fee to set up the client's domain email on Zoho's platform.

3.3.2 Inclusions

Internal Scope & Process (Zoho Setup): - Domain Verification: After the Core Website is underway or launched, if the client opts for the Zoho email setup, the first step is to verify the domain in Zoho's system. We create a Zoho Mail admin account for the client's domain (typically using an address like admin@clientdomain.com or prompting us to create the first user which could be their main address). Zoho will provide a TXT record (or CNAME) that needs to be added to the domain's DNS to prove domain

ownership. We will log into the domain's DNS management (often through Cloudflare, since we tend to manage DNS there, or the client's registrar if not) and add the required verification record. - DNS Records Configuration: Once the domain is verified, configure the necessary DNS MX records to direct email to Zoho's mail servers. Zoho usually provides specific MX records (e.g., mx.zoho.com ). Remove any old or placeholder MX records to avoid conflicts. Additionally, set up SPF and DKIM: - SPF (Sender Policy Framework): Add a TXT record that identifies Zoho's mail servers as authorized senders for the domain. Zoho's documentation will give a string to add (to reduce chances of emails being marked spam). - DKIM (DomainKeys Identified Mail): Enable DKIM signing in the Zoho mail admin panel and publish the provided DKIM public key as a DNS record. This cryptographically signs outgoing mail to prove it's from the domain. - Account Creation: Create the user's mailbox account in Zoho. Often, the client will want something like info@ , contact@ , or their first name (or multiple accounts if needed – note: Zoho's free plan allows up to 5 users at time of writing, which covers most small clients). We create the account(s) and set an initial password. - Testing: Log into the new email via Zoho's webmail interface to ensure the account works. Send a test email to and from an external email (like our company email or a personal email) to confirm sending and receiving are functioning. Check spam folder behavior as well. - Client Handoff & Training: Provide the client with instructions and credentials: - Write down the new email address(es) and temporary passwords (and encourage them to change passwords after first login). - Give the URL for Zoho Mail login (mail.zoho.com) and/or instructions to set up the email on their phone or mail client (Zoho IMAP/ POP and SMTP settings, which we can get from Zoho's help docs). - If the client is not tech-savvy, offer a quick remote support session (could be counted as part of the setup fee or as a courtesy) to help them add the email to their phone or Outlook. This typically doesn't take long and ensures they actually start using the new email. - No Ongoing Obligation: After setup, the client will maintain this email service directly with Zoho. Zoho's free tier might have limitations (like limited storage or features). Internally, we should note if the client might eventually outgrow the free tier (for example, needing more users or space) – in such cases, we might advise them to upgrade with Zoho or consider Google/Microsoft. But for many small clients, Zoho free is sufficient. We do not have to manage or support their email long-term beyond initial setup and any immediate questions; however, if issues arise later (like password resets or additional user setup), those would fall under either courtesy help if simple or a billable support incident if significant. - Time & Effort: Typically, setting up Zoho Mail takes a couple of hours at most (most of it waiting for DNS propagation for verification). The $50 fee covers this effort. The actual Zoho service might cost us nothing (free tier) or the client might be on a low-cost plan – but that's between the client and Zoho. Fincher Labs just charges for labor/expertise to configure.

By offering the Zoho Mail setup, we provide a budget-friendly email solution that aligns with the low cost of the website, ensuring the client's online presence is comprehensive (website + professional email). Internally, it's a straightforward process but must be done carefully to ensure reliable email deliverability (misconfigured DNS can lead to emails going to spam or not arriving). Always use Zoho's latest guidelines for DNS settings, and test thoroughly.

3.3.3 Google/Microsoft Email Setup ($125)

As an alternative to Zoho, clients might prefer using the industry-leading email platforms – Google Workspace (Gmail for Business) or Microsoft 365 (Exchange/Outlook) – for their professional email. These services are more robust and familiar to many, but they come with monthly subscription costs. Fincher Labs charges $125 one-time to handle the initial setup and configuration for either Google Workspace or Microsoft 365 using the client's domain.

3.3.4 Inclusions

Internal Scope & Process (Google Workspace/Microsoft 365 Setup): - Account Provisioning: The client will need a subscription for the email service: - For Google Workspace: We may have the client sign up for a Google Workspace account (or we do it on their behalf, with their permission). This usually starts as a trial (up to 14 days for free for a few users). We choose an admin username (often admin@domain.com or the client's name) and set up the Workspace tied to their domain. - For Microsoft 365: Similarly, we'd sign up the client's domain for a Microsoft 365 Business Basic/Standard plan (or use an existing one if they have it). We may have to coordinate with the client if they already have an Office 365 tenant. - Licensing: Ensure at least one user license is active (the client will have to provide payment details to Google/Microsoft for ongoing service after any trial). If the client is not comfortable doing that, we may need to walk them through it or handle it with their billing info. - Domain Verification & DNS: Both Google and Microsoft will require verifying the domain ownership. Like with Zoho, this involves adding a TXT record (or uploading an HTML file, but DNS TXT is easiest since we manage DNS). - Once verified, set up MX records for the chosen service: - Google: MX records pointing to Google's mail servers ( ASPMX.L.GOOGLE.COM etc., typically 5 records with varying priorities). - Microsoft: MX record pointing to .mail.protection.outlook.com . - Add SPF record appropriate for the service (Google's SPF include string or Microsoft's). - Enable DKIM signing: for Google, this is done in the admin console by generating a DKIM key and adding a DNS record; for Microsoft, DKIM can be configured in Exchange admin center similarly by publishing CNAMEs. - Also consider autodiscover/DMARC: - Microsoft often uses an autodiscover CNAME for easier Outlook configuration. Add those if recommended. - For DMARC (optional but good practice), set a policy record (e.g., start with a monitoring policy like v=DMARC1; p=none; rua=... just to have it). - User Mailbox Setup: Create the user's mailbox(es) in the admin portal. Likely just one or two users for a small business. E.g., create info@domain.com and assign it a license. If using Google, that user will have a Gmail inbox. If using Microsoft, that user will have an Exchange mailbox. - Initial Passwords and Security: Set a temporary password for each account and note it. For Google, you might have to reset password if created without one. For Microsoft, likewise. Encourage the client to change passwords on first login. Also consider enabling 2-step verification if the client is open to it (for security), though not mandatory. - Testing: Send test emails in and out of the new accounts. For Google accounts, simply log into Gmail with the new user and send an email to a personal account and reply back. For Microsoft, use Outlook Web Access to do the same. Check that emails arrive without issues and aren't flagged as spam (sometimes new domains might have low reputation initially). - Handoff & Education: Provide the client with the login URL and credentials: - Google: mail.google.com (with their full email as login) or admin.google.com for admin account. - Microsoft: outlook.office.com for webmail,

portal.office.com for account management. - Write up a short guide if needed, e.g., how to log in, how to configure in an email app (though many know, some may not). For Google, most smartphones just need email/password as Gmail is straightforward; for Microsoft, if the client uses Outlook desktop, we might need to help them add the account via autodiscover. - If the client had any existing email hosting, ensure they know to switch to using the new one (and that old emails won't automatically transfer – migrating old emails would be a separate task if needed). - Coordination of MX Switch: If the client previously had email hosted somewhere (for example, their domain registrar's default email or another provider), switching MX records will cut over mail delivery to the new service. Make sure to do this at a low-traffic time if possible and let the client know when it's done. There might be a propagation window; usually within a few hours mail flows to the new boxes. - Support Considerations: The $125 setup fee covers the initial configuration. We should plan for possibly one follow-up support session to resolve any minor issues (like assisting with setting up an email client, which could be done as part of the handoff or counted as a small courtesy). If the client later decides to add more users or has issues, that can either be handled as a paid update/support incident or the client can work with Google/Microsoft support directly. These platforms have their own support, but often clients come back to us since we set it up. We can decide case by case if small changes warrant a fee. - Time & Effort: This setup is more involved than Zoho, hence the higher fee. Typically, expect about 2-3 hours of work spanning across a day or two (due to waiting on DNS, client giving billing info, etc.). Ensure to schedule this work such that it doesn't delay the website launch – it can be done in parallel or after the site if needed. Make sure the client knows the site and email are separate; one can launch without the other being fully done if necessary.

By providing the Google/Microsoft email setup option, we cater to clients who might already be comfortable with Gmail/Outlook or who plan to scale up their email usage. Internally, we must keep track of which service the client chose and maintain any admin login info (in our password manager, for example) at least until handoff. After handoff, ideally transfer ownership of the admin account to the client (i.e., ensure they change the recovery info to their own, etc., so they are in control). The core principle is to set up the client for long-term success with their chosen email platform, then step back and let those reliable services handle the day-to-day.

3.4 Pay-As-You-Go Website Updates ($50 / $100 per update)

3.4.1 Overview

Not all clients will want an ongoing maintenance contract or subscription for website updates – many prefer to handle changes on an as-needed basis. Our Pay-As-You-Go Updates service provides a flexible, ondemand way for clients to request changes to their website after the initial launch and support period. We offer two fixed-price tiers for updates, based on the scale of the update:

 - Minor Update: $50 per request
- Major Update: $100 per request

Public-Facing Details (Client View): - On-Demand Site Changes: Clients can request changes whenever they need them, without any monthly commitment. They only pay for the work when they need it done. - Affordable Flat Fees: Small changes cost $50, while larger enhancements cost $100 – we will quote which category an update falls into before doing the work. This transparent pricing ensures clients know upfront what they'll pay. - Quick Turnaround: Update requests are typically completed quickly (we aim for 1-2 business days for minor tweaks, and perhaps 2-3 days for major changes, unless otherwise scheduled). Clients won't have to wait long to see their changes live. - Examples: We clarify what might be a minor vs. major update: - Minor ($50): e.g., updating a phone number or business hours on the site, changing some text or swapping out one image, adding a testimonial to a page. - Major ($100): e.g., adding a new page

(with content provided by client), integrating a new feature like a mailing list signup form, or doing a more involved restyle of a section. - No Surprise Charges: If a requested change would exceed the scope of a major update (for instance, a full redesign or adding very complex functionality), we'll inform the client and provide a separate quote. Otherwise, $100 is the max they'd pay for a single batch of changes under this scheme. - Long-Term Support: This offering is presented as a way we continue to support the client's website over the long run, even after the initial free support window. It's like having a "website handyman" on call.

Internal Process & Scope: - Categorizing Requests: When a client reaches out with a change request, the project manager or developer must assess its scope and decide whether it's "minor" or "major" under our definitions: - Use rough time effort as a guideline: Minor ~ up to 1 hour of work; Major ~ up to 3 hours of work. If it's beyond ~3 hours, it may need to be broken into multiple updates or a custom quote. - Also consider complexity: Changing a hex color site-wide might be quick (find-and-replace in CSS), whereas adding a new page with multiple sections might be more involved but could still be within a major update if content is provided. - If uncertain, err on the side of transparency: better to tell the client "This looks like a larger change; it might require a custom quote" than to promise it under $100 and then struggle. - Maintain a simple internal list of what common tasks fall under each tier (based on our experience) to help with consistency. - Quotation and Approval: Always communicate to the client the cost before proceeding: - "Sure, we can add those three team bios to your About page – that would be a minor update at $50. Would you like us to go ahead and do that?" (Email confirmation suffices as approval.) - Or, "Creating an entirely new 'Services' page with content you provided is a bigger change, but still within our major update flat rate of $100. We can proceed with that if you approve." - If something is beyond a major update (e.g., "Can we add an online store?" which is a whole new project), respond that this is outside the scope of a quick update and suggest a separate discovery/quote for that project. - Scheduling & Turnaround: Once approved, schedule the update work: - Minor updates should be slotted as soon as possible, ideally completed within 1-2 days. Many minor changes might even be done on the same day if resources permit (this quick service impresses clients). - Major updates might take slightly longer but we still aim for prompt execution, typically within 3 days or so. If a major update is to add a new page and the client provided content, a developer can usually handle it fairly quickly. - Keep the client informed: let them know the expected timeline ("We'll have this done by tomorrow EOD" or "expect the new page to be live by Wednesday"). - Testing & Deployment: Even for small updates, follow our QA practices on the changed parts. Ensure the change didn't break anything else. If adding new content, check formatting on mobile, etc. Deploy the changes (since these are existing sites, deployment might be to production or a staging environment first if we use one – for minor stuff it's usually fine to go live directly, but for major changes, possibly share a preview if appropriate). - For example, if adding a new page, we might send the client a preview link to confirm everything looks good before linking it in the navigation live. - Bundling Changes: If a client sends multiple small requests around the same time, consider bundling them into one update if it makes sense, rather than nickel-and-diming. E.g., they say "Can you update my homepage tagline and also post this new photo in the gallery?" – together those are still minor and can be one $50 charge rather than two separate charges. The idea is to maintain goodwill. However, if requests are separate in time, we treat them as separate incidents. - Billing: Use our billing system (Zoho Invoice or CRM) to invoice the client for the update immediately upon completion (or in batches if they do many in a month – though most will be one-offs). Since these are small amounts, often clients prefer to pay by credit card online; ensure the invoice makes that easy if possible. Keep records of these in case we want to analyze how many updates each client is using (could be a metric).

  • Maintaining Site Integrity: When performing updates, always work off the latest version of the site's code. Pull from the repository if needed. This underscores the importance of having version control. Make sure new changes don't overwrite or regress previous fixes. Each update commit should be documented

clearly. - Communication: After deploying an update, notify the client promptly: "Your website has been updated with the changes you requested. Please take a look and let us know if everything appears as expected." This closes the loop and shows responsiveness. - Common Types of Updates (Internal Examples): - Minor: Text edits, replacing one image or banner, updating an address, adding a single testimonial or news item, tweaking a style (like making a header bigger, changing a color). - Major: Adding a new top-level page to the menu (client provides content), embedding a third-party widget (like a scheduling calendar or Twitter feed), reorganizing page sections (like swapping the order of sections, which might require CSS/HTML adjustments), or adding several photos to a gallery. - If a request involves integration with a new service or a feature we've never done, assess carefully if it fits into a major or if it should be a separate mini-project. - Version Control & Backup: Before making changes, it's good practice to back up the current site or ensure the repo is up to date. In case a change doesn't go well, we can roll back quickly. For major changes, perhaps do them on a separate branch or test environment, especially if the site is hightraffic (most of our small clients won't have heavy traffic, but still). - Out-of-Scope Items: Some things we should likely not do as a quick update because they could be can-of-worms: - Adding e-commerce functionality or a complex form – that's a new service offering potentially. - SEO overhaul or content writing – those are separate services possibly. - Platform migration or redesign – definitely a new project. - If any such request comes, treat it as an opportunity to discuss a larger project rather than trying to fit it into an update slot.

By offering Pay-As-You-Go updates, we ensure clients have a safety net after their support period ends: they know we're available to keep their site fresh. Internally, it generates additional revenue and keeps us connected with past clients (which is great for repeat business and referrals). It's important to manage it so that it remains profitable – the flat fees mean we have to be efficient in doing these changes. Over time, we'll refine what falls under minor vs major as we see how long tasks actually take. Document frequently requested updates in an internal knowledge base – maybe even develop snippets or tools to do them faster (for instance, if multiple clients ask to add a "COVID update" banner, have a ready-made code chunk for that). This service, combined with our friendly approach, encourages clients to reach out rather than attempt risky DIY changes or hiring someone else.

3.5 Remote Support (Per Incident: $25 / $40)

Our Remote Support service provides clients with quick technical assistance or training on an as-needed basis, outside of the context of website content updates. This is more about supporting the client in using their website or related tools, and fixing minor issues, rather than altering the website's design or content (which would fall under updates). The service is charged per "incident" – a single support issue or session – and we have two price points: $25 for standard support and $40 for extended/urgent support.

Public-Facing Details (Client View): - Tech Help When You Need It: Clients can get one-on-one assistance via phone or screen-sharing for any website-related questions or minor issues. For example, if they forgot how to log into their email, need guidance updating their blog (in cases where they have a blog/CMS), or something on the site isn't displaying correctly on their computer, we'll help. - Affordable Per-Incident Pricing: Only $25 for a standard support session (during our business hours), which typically covers one issue or question. If something comes up outside of business hours or is extremely urgent (needing immediate attention at night or on a weekend), we offer an extended support option at $40 for that incident. - Examples of Support Incidents: "How do I reset my email password?" – We'll walk you through it. "My website contact form email is not showing up in my inbox" – We'll troubleshoot with you. "I'd like to know how to add a blog post" – We'll show you (if their site has a blog feature or CMS). Essentially any

guidance or minor troubleshooting that doesn't require a full update. - Convenient & Remote: The support is remote, meaning via a phone call, email, or a screen-sharing session (e.g., Zoom or similar). The client doesn't need to bring their computer anywhere – we'll talk them through it or remotely connect if needed. - Customer-Friendly: We explain things in simple terms and aim to resolve issues quickly. It's like having a "helpdesk" for your website without a monthly contract. - No charges during support window: (We might mention if still within the initial 60-day post-launch support period, such issues are handled free. After that window, this per-incident fee applies. This sets the expectation that routine support becomes paid later, but that initial period is free.)

Internal Process & Scope: - Definition of Incident: Internally, we define an "incident" as a single support issue or request from a client that can typically be resolved in a short session. It might involve one or two phone calls/emails. It generally should not exceed, say, 30 minutes of active work. If something is more complex, it might be counted as multiple incidents or escalated to a small project. For consistency: - One incident = one problem. If during a call the client brings up a second unrelated issue ("While I have you, can you also look at..."), that might be considered a second incident (and thus another charge), but use discretion based on effort. We don't want to nitpick small things, but also shouldn't let a single $25 session turn into hours of free consulting. - Standard vs Extended: - Standard ($25) applies if the support is provided during our normal operating hours (e.g., weekdays 9am-5pm) and we can schedule it at our convenience (usually same-day or next-day service is fine). - Extended ($40) is for either off-hours support (nights, weekends, holidays) or immediate-attention issues (client says "my site is down right now!" at 8pm – we'd treat that as urgent and after hours). It's essentially a small emergency fee. - Internally, decide what qualifies as after-hours: likely any request outside 9-5 Mon-Fri. If we voluntarily handle something at 7pm but it could have waited, we might still charge standard. The extended is mainly if client insists on immediate help off hours, or if we advertise a quicker SLA for that tier. - Logging and Ticketing: When a client contacts us for support (via our support email or phone line), create a support ticket or at least make a note of: - Client name, date/time, issue description. - How it was resolved and how long it took. - This helps for both billing and identifying if some clients have frequent issues (maybe indicating training needs or chronic problems we should fix permanently). - We don't have a formal ticket system, but even a spreadsheet or Zoho Desk (if available) could be used. At minimum, email threads serve as records. - Resolution Process: Upon receiving a support request: - Acknowledge to the client and categorize its urgency. If urgent and off-hours, decide if we can handle it immediately or schedule. - If it's something like a site down or email not working, treat with higher priority as it affects their business. - Use remote tools as needed: sometimes a phone call is enough to talk them through (e.g., steps to reset a password). Other times screenshare is best (like if they need guidance clicking through a UI). - Maintain a calm, patient demeanor – remember client-friendly language; even if the issue seems trivial or user-error, we empower the client. E.g., "I'm happy to help you with that. Let's take a look together." - Solve the issue or provide a workaround. Test to confirm it's resolved. - Make sure the client is satisfied that their question was answered or issue fixed. - Examples (Internal handling): - Email login issue: Client can't log into their newly setup Zoho email. Likely causes: forgot password or mis-typed. We could remote in via Zoho admin to reset their password and then help them log in. Or talk them through checking caps lock, etc. Resolution: Reset password, give new one, watch them succeed logging in. - Contact form deliverability: Client says form submissions aren't arriving. Possible reasons: their email's spam filter caught it, or the form config needs an update (maybe their email changed). We'd test the form, check our form handling code, maybe change the "from" address to avoid spoofing issues, and advise the client to check spam folder or adjust their email settings. Once fixed (e.g., we have forms send from a consistent no-reply@clientdomain and have proper DNS records), do a test with them. - Site appears down for client: Check if it's truly down (could be their network). If it's up for us, advise them to clear cache or check again, maybe a DNS

propagation issue. If it's actually down, identify cause (maybe domain expired or hosting issue). Solve accordingly (renew domain, restart hosting, etc.) – note domain expiration ideally we prevent via renewal assistance, but if it happened, get it sorted out quickly and help them renew. - CMS guidance: If we delivered a site with any editable portion or integrated CMS (not common in base package unless maybe they have a blog via a headless CMS or such), the client might need a walkthrough on how to add a post or edit content. We'd hop on screenshare, show them the admin interface steps. This is more training than fixing – it's fine as an incident as long as it's one topic. - Boundary of Support vs Update: Sometimes a client might request what they think is "support" but it's actually an update. For instance, "Can you help me change the picture on my homepage? I tried but I can't." If the site is static, the client has no way to change it themselves – so effectively they're asking for an update service. We should then route this to a paid update rather than treat it as a $25 support call. The support call could cover explaining that to them and then initiating the update process. Use judgment: if it's literally a two-second change and it's the first time, maybe do it as courtesy or a $25 thing; but in general, content changes are updates (see Section 3.4). - We may explain: "We'd be happy to update that image for you. That actually falls under our $50 minor website update service since it's a change to the site's content. Would you like us to proceed with that update?" This way they know it's different from just guidance support. - Billing and Collection: After resolving the incident, prepare to bill the client for the support if applicable: - If it's a quick question we answered via email in 5 minutes, and it's the first time or a very loyal client, sometimes we might waive the fee as goodwill (especially if within not-too-far post-launch). But if we establish this service, we should generally charge to keep it sustainable. - For phone/screen sessions, we likely schedule them knowing it's billable, so the client expects a charge. We can invoice immediately after the session. - Keep the invoice description simple: "Remote support session – Date – Issue description" at $25 or $40. - If a client bought multiple incidents in some package (we currently don't have a bundle, but maybe in future we could sell, for example, a 5-incident pack at a slight discount), then track usage. Currently, not offered, but maybe an idea.

  • Support Infrastructure: Ensure we have the tools to perform remote support: - Phone line or VoIP (maybe use a company number or if using personal, block ID as needed). - Screen sharing software: Zoom, Google Meet, or even Zoho Assist (since we use Zoho suite) can be used to remote control their screen if necessary. - If remote controlling, always ask permission and have them initiate any download of remote assist app (for security trust). - A stable internet connection on our side and any relevant admin credentials ready (e.g., if working on their email, have the Zoho admin login on hand). - Documentation: After an incident, jot down notes on what was done, especially if it's a recurring type of question. We can add frequent Q&As to an internal or external FAQ to possibly reduce such calls (maybe in future, a client portal with help articles). - Extended Support Special Cases: If we advertise emergency off-hours support, we need an internal on-call arrangement. Since we're a small outfit, likely the expectation is limited. We might not explicitly promise 24/7 availability, but if a client reaches out at an odd time, we respond if we can and charge extended. We should make clear (perhaps in the handoff or contract) what the client should do if something urgent happens off-hours (e.g., email our support and we'll do our best). We're not a 24/7 operation, but we try to be responsive.

Remote Support incidents allow us to monetize small help requests and ensure clients aren't left stranded after project completion. It's also a good touchpoint to keep relationships warm. Often, a quick helpful session can leave a great impression and lead to referrals or additional work. The key internally is to politely distinguish between what is a quick support (which can be solved by guiding the client) and what is actually new development work (which should be an update or new project). With clear communication and consistent application of the pricing, clients will come to understand and respect the boundaries.

(Note: During the initial 60-day post-launch support window, we do not charge for support incidents that fall under normal assistance – those are free as part of our warranty. The per-incident fees kick in after that window, or for issues outside the scope of the warranty. See Section 6.1 for support window coverage.)

Additional Note on Domain & Hosting Support: (Relevant to Sections 3.1, 3.3, 3.5) We include domain configuration assistance as part of our web projects, and we host the site on a reliable platform for free. However, domain renewal is an ongoing need (usually annual) – while not exactly a "service for sale," it's part of our support commitment to remind or assist the client in keeping their domain active. This is detailed in Section 6.3 (Domain Renewal Assistance), but it's worth mentioning here that any critical domain/hosting issues that arise (like an expired domain or site downtime) are addressed with high priority, often as part of our goodwill support (especially if it's due to something we manage, like a hosting config). We want our clients' sites to stay online and their emails to keep flowing, so even if it's beyond formal support period, such critical issues might be handled first and billing considered second. This client-first approach is part of our ethos, trusting that solving problems quickly builds loyalty and then the business side can be sorted out.

Now that we've covered the specific services and products we offer, the next sections of this manual will delve into how we sell and execute these services, including our sales approach, project workflow from quoting to launch, and the standards we uphold during development and beyond.

4 Sales & Onboarding

This section serves as our Sales Playbook and onboarding procedure guide. It covers how we communicate the value of our services to prospective clients, handle inquiries and objections, convert leads into signed projects (utilizing our Zoho automation), and encourage referrals to generate new business. The goal is to ensure every salesperson or team member interacting with clients can confidently articulate our offerings and follow a consistent process to bring a client on board.

4.1 Sales Playbook & Key Talking Points

When discussing Fincher Labs' services with potential clients, it's important to highlight our unique value proposition and benefits in a clear, compelling way. Below are the key talking points and messaging guidelines:

  - "Complete Online Presence in Days" – Emphasize that we deliver fast and affordable websites via intelligent assembly of proven templates and components.
Many small businesses expect websites to take weeks or months and cost thousands; we break that
mold by offering a full website for $350 in about 3–5 days. This speed and price is a major selling
point. For example: "You can have a professional website live by this time next week for under $400."
- Affordable Investment, High Value: Frame the $350 cost (within a typical $250–$400 range depending on scope/capacity) as a smart investment rather than an
expense. For a small business, $350 is often less than the cost of a single traditional advertisement,
yet a website is a 24/7 marketing tool. Reinforce that perspective: "For roughly the price of a one-time
newspaper ad, you get a website that will bring in customers 24/7 for years to come." It's important they
see ROI potential (more on ROI in the next section).
- Professional Quality: Assure clients that despite the low price and quick turnaround, the quality is
professional. We use modern design practices and technology (like Next.js, though we don't always

name-drop tech to non-tech clients). Instead, say: "We build modern, mobile-friendly sites. The same technologies powering Fortune 500 sites, we use to power yours – just scaled to what you need." Emphasize "AI‑assisted, human‑perfected": AI accelerates first drafts; humans ensure quality. Mention that their site will look custom and not "cookie-cutter" (we tailor to their brand). We have examples/portfolio ready if they want to see past work (showing visually appealing sites we've done).

  • End-to-End Service: Highlight that we don't just toss them a website and disappear. We handle domain setup, we can set up their business email, and we support them post-launch for two months at no extra charge. Essentially, "we hold your hand through the whole process and beyond launch." This is reassuring, especially for those not tech-savvy. It differentiates us from DIY website builders or freelancers who might not be as attentive.

  • No Hidden Fees: Be upfront that $350 is the one-time development fee (within the $250–$400 range), and the only other costs are things like the domain registration (maybe ~$10/year, paid to a registrar) and if they choose a premium email service (Google/Microsoft's monthly fee). Hosting is included free. This transparency builds trust. You might say, "There's no catch – $350 covers the site build and launch. We're able to host it on our cloud servers at no extra cost to you. The only ongoing cost is your domain name renewal each year, which is usually around $10-15."

  • Custom and Personal: Stress that each site is customized to the client's business – we're not just plugging their name into a generic template. Also, Fincher Labs is a small studio, which means personal attention. "You'll be working directly with us – we take the time to understand your business and what you need on your website. You won't be just a number like with some larger agencies." Many small clients appreciate knowing the people behind the work.

  • Peace of Mind & Support: For clients who worry about not knowing anything about websites, remind them "We take care of the technical stuff so you can focus on your business." We will demystify any jargon and make the process easy. Also, mention our support window and ongoing help options (so they won't feel abandoned). "And after the site is live, we're still here for you – if you need changes or have questions, we're just an email or call away."

  • Use of Successful Client Stories: If we have any quick case studies (even informal), use them in conversation. E.g., "We helped a local bakery get a site up in 4 days, and within a week of launch, they got 10 inquiries through the contact form. They were so excited to see immediate results." Real stories or references make our promises tangible.

  • ROI & Business Growth Focus: Instead of just talking features, frame benefits in terms of business outcomes: more credibility, more customer inquiries, saving time (if we add something like online appointment forms, etc.), and having an online brochure that works for them 24/7.

  • Upsell Add-Ons Appropriately: Depending on client needs, mention our add-on services:

  • If they seem in a hurry: "We do offer a rush delivery service for an extra fee if you need it live by, say, tomorrow."

  • If their email is something like @gmail, mention the professional email setup: "Along with the website, we can set you up with a professional email address, like name@yourdomain.com, which looks much better to clients."

  • Always frame these as convenience and brand-improving options, not as nickel-and-diming. We're offering them to enhance the value we provide.

  • Overcoming DIY Temptation: If a lead mentions they're considering a DIY website builder (Wix, Squarespace, etc.), highlight how our service saves them time and yields a more polished result. E.g., "Many of our clients initially thought of doing it themselves, but found it overwhelming to get a site that truly looks professional and does everything they need. With us, you don't have to struggle with design or technical settings – we do it all for you, and often the total cost ends up similar once you factor in those platform fees and your valuable time."

    • Local/Relatable Angle: If the client is local or values personal connection, emphasize that aspect. E.g., "We're a small local business just like you, we understand budgets and needs of our community." Building rapport can set us apart from impersonal online services.
    • Confidence and Simplicity: Speak confidently about our process. "Our process is straightforward: we gather your requirements, content, and preferences, then we get to work. We'll keep you updated throughout. In just a few days, you'll see your site ready to go." Clients appreciate knowing what to expect in simple terms.

Overall, the sales pitch should come across as we are offering a high-value, low-hassle solution to get them online quickly and effectively. We solve a problem (not having a website or having an outdated one) and we do it in a friendly, efficient manner. Always steer the conversation towards how it benefits the client's business and reduces their headaches, rather than just listing technical features. And importantly, listen to the client's specific needs or concerns; tailor the talking points to what matters to them (e.g., if they emphasize wanting a site easy to update, mention our update service or how we can handle changes for them; if they care about design aesthetics, mention our customization and past designs).

4.2 Value Proposition & ROI Framing

One of the most powerful ways to convince a potential client is to frame our services in terms of return on investment (ROI) and value to their business. Many small business owners are cost-sensitive, so we need to help them see that a website isn't just an expense – it's an investment that can yield tangible benefits. Here's how to articulate that:

 - 24/7 Salesperson Analogy: A common framing is: "Your website is like a salesperson who works 24/7,
never sleeps, never takes a break, and can reach customers anywhere." For just $350, that's an incredibly
cost-effective "employee." This helps them see the site as a tool that will actively bring in revenue or
enhance their business.
- Credibility and Trust = More Business: Explain that today's customers often judge a business by its
online presence. "If someone hears about your business, the first thing they often do is search online. If
they find a professional website, they're far more likely to trust you and convert into a paying customer.
Without a site, or with a poorly made one, you might be losing those leads." So the ROI might not just be
direct sales through the site, but the business won by instilling trust.
- Reach and Visibility: "A website expands your reach beyond word-of-mouth. People searching on Google
for services in your area can find you. It opens up new customer avenues." If appropriate, mention how
even one or two new clients brought in by the website could cover the cost. For example, "If the site
brings you just one new project or a couple of customers, it's literally paid for itself. Everything beyond that
is profit." If they sell products or have a high customer lifetime value, crunch a quick number: "With
your average service being $200, you only need 2 new bookings from the website to break even on the
cost."
- Saving Time (ROI in efficiency): Some ROI is in time saved or improved efficiency. Example: "With
information on your site, you might cut down on a lot of basic inquiry calls. Customers can find your
hours, services, etc., on their own. That frees you up to focus on tasks that make you money." If we include
features like a contact form, mention how it can generate leads automatically without them having
to answer the phone each time someone has a query.
- Comparative ROI: If they've done other marketing, compare: "How much did that direct mail
campaign cost you, and for how many leads? Now compare that to $350 for a website that will serve you
for years." We can also highlight that many agencies charge $2k-$5k for similar sites – so our service

is high ROI from a cost-savings standpoint too. (Careful with this; we want to show we're a great deal
without planting doubt about quality.)
- Longevity: "This isn't a one-time ad that runs and is done. The website will continue to be online, year
after year (with maybe minor updates), constantly providing information and attracting customers. So the
ROI accumulates over time. The upfront cost is small when spread over the life of the site." You can break
it down: "$350 over say 3 years before a redesign is like $10 a month – that's nothing for a full business
website."
- Client Examples in ROI Terms: If any existing client saw measurable results, mention that. E.g.,
"After we built a site for a landscaper, he reported that he started getting about 5 new inquiries a month
through the site. If even 2 of those turn into jobs, that's hundreds or thousands of dollars of revenue
monthly thanks to a website." Real or even hypothetical scenarios help make ROI concrete.
- Professional Email ROI: For email, mention how having yourname@yourbusiness.com can
impress clients. It might be subtle, but "Using a branded email can be the difference in looking like a
serious, established business vs. a hobbyist. It helps with trust, which can indirectly lead to higher
responses and sales." Also, internal efficiency if they use Google Workspace or MS 365: "You also get
tools (Google Drive, etc.) that can improve your operations."
- Opportunity Cost of Not Having a Website: Sometimes it's effective to highlight what they lose by
delaying. "Every day your business isn't online, you could be missing out on customers searching for your
services." Ask if they've ever had someone ask "Do you have a website?" and they had to say no –
"Think of how many didn't even ask and just moved on to a competitor who has one." That absence is
costing them in unseen ways.
- Turnaround ROI (time to value): Because we launch quickly, the client starts reaping benefits
almost immediately. "You could start getting new leads by next week." This short payback period is
attractive – not many investments start yielding returns so fast.
- Referrals and Word-of-Mouth Boost: With a website, even word-of-mouth referrals are stronger.
For instance, if someone recommends their business, that referred person can quickly check the
website, see the services, be impressed and follow through. Without it, that chain might break. "Your
website also supports your word-of-mouth – it gives those referrals something to look at and convince
themselves."
- ROI for Non-profits or Other Goals: If the client isn't selling something (maybe a non-profit or
community org), frame ROI in terms of reach and engagement: "Your message/mission will reach more
people, potentially increasing donations or participation." Adapt to their goal (members, attendees,
etc.).

In summary, always loop back the conversation to "How will this website (or email, or service) make or save you money, or otherwise improve your business outcomes?" We want them to mentally justify the purchase as a net positive. We're not just selling web pages; we're selling credibility, visibility, and opportunity.

4.3 Common Objections & Rebuttals

During the sales process, potential clients may raise concerns or objections. It's crucial for us to address these confidently and helpfully. Below are some common objections we encounter and suggested rebuttals/talking points for each. The key is to remain empathetic – acknowledge the client's concern, and then provide information or perspective that alleviates it.

 - "I'm not sure I can afford a website right now."
Rebuttal: "I understand budget is a concern for many small business owners. That's actually why we
created this $350 package – to be budget-friendly. Think of it this way: for $350, you're getting a business

asset that can continuously bring you customers. Many of our clients see that even one new customer from the website can cover the cost. Also, we only require a deposit to start, not the full amount upfront. We can split the payment if that helps – 50% to kick off, 50% at launch. There are no hidden or ongoing fees from us. It's a one-time investment that can yield long-term returns." (If needed, circle back to ROI points, or compare to other expenses they might have that don't directly bring revenue, whereas a website has potential to.)

  • "My friend/relative said they could make me a website for free (or I might do it myself)." Rebuttal: "It's great that you have someone willing to help. We've worked with a lot of clients who started that way – maybe a friend set something up on Wix or a cousin in college offered to design it. Often, what happens is that initial enthusiasm fades or the result doesn't turn out as professional as expected. We specialize in this – you'll get a polished site and we'll handle it quickly and reliably. Plus, we'll be here to support you after. With a friend or relative, it can strain the relationship if things get delayed or if you need ongoing help. We've actually had clients come to us after waiting months on a friend's help that never quite finished. By working with us, you get a guaranteed result by a set date. Your time is valuable too; doing it yourself can be a big learning curve and time sink. For a lot of business owners, it ends up costing more in lost time and frustration. We take that burden off your shoulders." (If they're worried about offending the friend, you can add: "Maybe your friend can still be involved for content or ideas, but we'll do the heavy lifting professionally.")

  • "$350 seems too low – will the quality be good? Is there a catch?" Rebuttal: "There's no catch, I promise. We've streamlined our process and use efficient technology, which lets us keep costs low. We also believe in pricing fairly for small businesses. Rest assured, you get a high- quality site. In fact, I can show you examples of sites we delivered at this price point." (Have portfolio or references ready.) "We're able to charge less because we focus on the core features a small business needs, without unnecessary frills. And since we get referrals and repeat business due to happy clients, we don't spend a lot on advertising – which also helps keep our prices low. Our business model is built on volume and efficiency, not cutting corners on quality. We truly believe in delivering great value."

  • "Can I see samples of your work or templates you use?" Rebuttal: "Absolutely, I can share some of our past projects." (Then present portfolio pieces or a demo template if appropriate.) "Each site is customized to the client's branding, but these will give you an idea of our style and capabilities. Also, if you have a particular look in mind or even a template you like from somewhere, we can use that as inspiration. We're flexible – the end goal is a site that you're proud of." (If we have a sandbox site to demonstrate, it can help quell quality concerns. Just ensure any sample shown aligns with what we can deliver for $350.)

  • "How do I know the website will actually help my business? I've managed without one so far." Rebuttal: "It's true, some businesses get by on referrals and existing clientele. But consider this: a website can help you tap into a broader market and serve as a validation for new customers. These days, people expect a business to have an online presence – some might be hesitant if they can't find you online. You may not even realize how many potential customers didn't call you because they couldn't see more info about you first. A website also helps existing customers refer you; they can send their friends to your site to learn more. It's like a storefront that's open 24/7. In an increasingly digital world, having no website can inadvertently send a message that the business is small or not up-to-date. We want to help you avoid losing business to a competitor who is online."

(Optionally, add: "Many businesses saw during recent times (like the pandemic) that an online presence was crucial. It's a form of business insurance to have that channel available.")

  • "I don't have any content or good photos for a website." Rebuttal: "Don't worry, you're not alone – a lot of clients start with very little content. We will guide you on what content is needed. For text, if you can give us even bullet points about your business, we can help flesh it out or at least place it nicely. For photos, if you have a logo that's a great start. If you don't have images, we can source high-quality stock photos that fit your industry (at no additional cost, as part of our service). For example, if you're a landscaping company and don't have pictures, we can use professional stock imagery of gardens and lawns. Over time, you can replace those with your own photos as you get them, or we can update them for you. The main thing is: lack of content shouldn't hold you back from getting started. We can launch a great looking site with what's available and always improve it later." (Also mention: "We have experience writing basic content too – we know what a typical Home or About page might say. We'll put something together and you can tweak it.")

  • "I'm not very tech-savvy; I'm worried I won't understand how to manage the site or email." Rebuttal: "That's completely fine – in fact, that's exactly the kind of client we often help. We handle all the tech stuff for you. You won't have to deal with code or complex settings. Once the site is live, if you need any changes, you can just call or email us and we'll take care of it through our update service. For things like email, we'll not only set it up but also show you how to use it. We can do a screenshare and walk you through sending and receiving emails, or adding it to your phone. We make our solutions as user-friendly as possible – for example, if your site does have any editable parts (some clients want a blog or ability to post updates), we'll give you a simple editor or training. And remember, you have that 60-day support period where you can ask any questions at all. We pride ourselves on patience and clear explanations. Our goal is that you feel comfortable and supported."

  • "What if I need changes or something breaks on the site later?" Rebuttal: "We've got you covered. First, our 60-day post-launch support means if anything isn't working quite right or you realize you want a small tweak, we fix that free of charge. Beyond that, we offer very affordable update options – only $50 for minor changes, $100 for bigger updates – and we're always an email away. The site is built on stable technology, so it's unlikely to 'break' on its own. We don't store sensitive data so you won't have to worry about hacks or anything complicated. In short, if you need something, we will be there to help. We won't disappear after the website is done. In fact, we hope to be your long-term partner as your business grows."

  • "Do I really need the professional email? Can't I just use my Gmail?" Rebuttal: "You absolutely can keep using personal Gmail, and it won't stop the site from working or anything. The reason we offer the professional email setup is it adds a layer of professionalism and trust when communicating with clients. For instance, john@yourbusiness.com on your business card or in email correspondence looks more official than johnny74@gmail.com . It subtly tells people you're a serious business. That said, it's optional. We priced it pretty low ($50 or $125 depending on provider) to make it accessible if you want it. If you're on the fence, we can always set up the website first and add the email later if you decide it's needed. Some clients do start with their free Gmail and then upgrade once they see more email volume. It's entirely up to you and we can support you either way."

  • "How do I know you'll stick to the timeline? I really need it by X date." Rebuttal: "Timelines are one of our strengths. We pride ourselves on delivering when we say we will. The

     standard timeline is 3-5 days, and if you have a specific date like an event or launch, we will schedule the
    project backward from that to make sure it's ready. Internally we use a streamlined process (we even have
    automation for our quoting and project setup) that saves time. Plus, since we focus on relatively small
    projects, we don't have the kind of delays big agencies do juggling many moving parts. We'll stay in close
    communication throughout those few days. And remember, we even offer a rush 24-hour option if needed.
    The fact that we have that option shows we're confident in our speed. Of course, we will also depend on
    you to provide content and feedback promptly, but assuming that, we haven't missed a deadline yet."
    (If they do choose the rush add-on, double down on assurances and maybe share how we've managed
    previous rush projects successfully.)

By preparing for these and other objections, we can respond smoothly and turn hesitations into agreements. Always listen fully to the client's concern, acknowledge it ("I understand…") and then answer. Use positive language and sometimes questions to confirm you addressed it: "Does that help explain it?" or "Do you feel better about that aspect now?" This invites them to voice further issues or ideally say "Yes, that makes sense."

4.4 Quote-to-Sign Automation (Zoho Workflow)

Fincher Labs uses an automated quoting and contracting workflow to streamline onboarding and ensure nothing falls through the cracks. We leverage Zoho (specifically Zoho CRM and Zoho Sign/Zoho Books) to generate professional proposals and capture electronic signatures, making the process fast and paperless for the client and us. Here's how the quote-to-sign process works internally:

1. Gather Requirements & Pricing: After the initial consultation with a prospect, the salesperson or
project manager will determine exactly which services the client needs (Core Website Package for
sure, plus any add-ons like Rush, Email setup, etc.). We also clarify any special notes (like if they need
extra pages beyond the standard, or any agreed variations in scope). We ensure we have the client's
correct legal name, business name, and email address for the quote.

2. Prepare Quote in Zoho: Using Zoho's CRM/Books system, create a new Quote for the client. We
have predefined line items for each of our services in the system:

3. e.g., "Core Website Package – $350",
4. "Rush Delivery Add-On – $150" (if applicable),
5. "Professional Email Setup (Zoho) – $50" (if applicable),
6. etc. We select the appropriate items for this client's package. The system will automatically total the
amount. We ensure the description of each line item is clear (the CRM might have a short
description, but we can add any specifics in the notes field if needed, like "includes up to 5 pages,
delivered in 3-5 days" for clarity, or a line stating "60-day support included at no charge").

Additionally, include any one-off charges or discounts: e.g., if we promised a slight discount or had a referral credit applied (maybe the client was referred and gets $50 off, though usually we give the referrer a credit, not the new client, but if any promo, we reflect it).

1. Payment Terms & Deposit: In the quote template, state the payment terms. Our standard is 50%
deposit, 50% on completion (Net 0 at launch). We explicitly put that in writing:

2. e.g., "50% ($X) due upon acceptance to initiate project. Remaining 50% ($Y) due upon website launch
(no later than 7 days after site completion)." If using Zoho Books, we might set it up to automatically
request 50% as a retainer or have an invoice follow, but at minimum, it's written on the quote for
clarity. Also include acceptable payment methods (e.g., "Payment by online invoice (credit card/ACH)
or check." If integrated, we can accept card payments via Zoho's payment gateway).

Also mention any refund policy here if relevant (e.g., "Deposits are non-refundable once work begins" – that might be more for the contract text, but including it in fine print is good).

1. Timeline & Deliverables in Quote: We include a brief mention of timeline and deliverables either in
a cover letter section or line item description:
2. For example, add a note: "Project to commence on [estimated start date] with expected completion
by [estimated date range]. Includes design & development of a custom 5-page website, mobile
responsive, contact form, domain setup, and 60-day post-launch support."
3. If Rush is included: "Rush delivery guarantees site launch within 24 hours of project start."
4. This manages expectations and serves as a written commitment.

Zoho allows adding a cover note or terms & conditions section – we should use that to paste in our standard terms (which might include these details and policies about scope, support, etc., akin to a short contract).

1. Electronic Signature Request: Once the quote looks good, we send it to the client via Zoho's e-
signature integration. Typically, Zoho will send an email to the client with a link to view the quote.
The client can review the quote online; we usually include a friendly note in the email as well:
2. e.g., "Dear [Client], Thank you for choosing Fincher Labs. Please find your project quote attached.
You can review the details and electronically sign to approve. We're excited to get started! Let us
know if you have any questions." The client is prompted to sign (Zoho Sign ensures the signature is
legally binding). They might have to click an "Accept" or "Sign" button, and possibly draw a signature
or just type their name depending on the setup.

Zoho can automatically convert an accepted quote to an invoice or project in the system, which is useful for our tracking.

1. Deposit Invoice Automation: Ideally, our Zoho setup will automatically generate an invoice for the
deposit once the quote is signed. If not automatic, manually create an invoice for 50% and send it
immediately upon quote acceptance. The invoice should have a payment link (Zoho Books allows
that if configured with a payment gateway). Many clients will pay the deposit right away via credit
card. If they prefer check, they'll send it, but we won't start until received (make this clear politely).
2. We keep an eye on this – maybe configure Zoho to notify us when the quote is signed, and when an
invoice is paid.

3. If the deposit isn't paid within a day or two of signing, a gentle reminder might be needed because
our timeline commitments hinge on that.

4. Project Kickoff in System: Once signed (and deposit ideally received), mark the deal as "Closed
Won" in Zoho CRM. This could trigger other automations:

5. For example, create a task list or project in Zoho Projects (if we use it) or at least an entry in our
project tracker, with the client's info and target dates.
6. Update our calendar with the promised launch date or timeline.
7. Possibly generate an internal email/slack to the team: "New project signed – [Client Name] – due by
X".

The automation can also store all relevant info like what add-ons were included, etc., so the team knows the scope immediately from the system.

1. Contract Terms & Archival: The signed quote combined with our terms effectively serves as the
contract. We ensure a copy of it is saved (Zoho usually keeps it, but we might also PDF it for our
records). It contains the client's signature, timestamp, and the agreed line items.
2. If we have additional contract terms (like liability limitations, etc.), those should be embedded in the
quote or attached. It's wise to include a boilerplate in the quote terms & conditions field. For
instance: "Fincher Labs will provide services as described. Client will provide necessary content. Any
changes beyond the defined scope may require a separate quote. Fincher Labs' liability is limited to
the amount paid for services.…" etc. Keep it concise and comprehensible, since the client will read
this.
3. Ensure it mentions the support period, and any warranty on work (like we guarantee to fix bugs
found in that period).

4. Also include the referral program mention: e.g., "Referral Bonus: Don't forget, if you refer another
business to us, you receive a $50 credit upon their project completion!" This plants a seed early.

5. Client Onboarding Confirmation: After signing, send a personal email (or call) to thank them and
outline next steps:

6. Confirm receipt of the signed quote and deposit (or if deposit pending, mention we'll start on
receipt).
7. Restate the timeline: e.g., "We're scheduled to have your initial site ready by [Date]."
8. List anything you need from them that isn't already provided: logos, text, images, credentials, etc.,
with an ideal deadline.

9. Assure them they can ask any questions and that they'll be kept updated. This sets a professional
tone and reduces any anxiety after signing.

10. Zoho CRM Notes: Throughout the sales process, keep notes in the CRM about the client's preferences, any verbal commitments (e.g., "client mentioned possibly needing booking functionality in future", or "client is very particular about color blue matching their logo"). These notes help the project team deliver better and give context.

           - Also, log any referral info (like who referred them, so we know to pay out the bonus later).
- Tag the deal with source (Ad, Referral, etc.) for internal metrics.

The benefit of using Zoho and this automated approach is multi-fold: - It creates a professional impression for the client. The quote and contract are branded and clear. - It reduces friction to sign – clients don't need to print or scan; one click and done. - It ensures we have a legally binding agreement in place easily. - Internally, it triggers the next steps smoothly, helping us avoid forgetting to invoice or start work without

deposit. - It also centralizes information (CRM holds the product details of the sale, etc.) which is useful for later analysis and for maintaining a history with the client (when we do updates or future projects, we know what was originally delivered).

Zoho Template Maintenance: We maintain templates for quotes in Zoho to speed this up. If we ever change pricing or terms, update the template so new quotes reflect that. Currently, our products and prices are set; if any promotion (like we sometimes have a $100 referral credit promo), we might need a line item or discount line reflecting that, rather than editing base prices.

In conclusion, the Quote-to-Sign process is designed to be quick, clear, and convenient. By following it, we can move from a verbal agreement to a signed contract in the same day, and then swiftly into production. This efficiency impresses clients and reduces our sales cycle time.

4.5 Referral Program

Fincher Labs has a Referral Program to encourage satisfied clients (and other partners or contacts) to refer new business to us. Word-of-mouth is powerful, and we want to actively reward those who help us grow our client base. The program details are as follows:

Overview: For each new client referred to Fincher Labs who purchases a Core Website Package (or an equivalent primary service), the referrer receives a $50 referral reward. This reward is typically given after the new client's project is completed and paid. During special promotional periods, we may increase the referral bonus to $100 to further incentivize referrals.

Who Can Refer: Any existing client, past client, or even friends/associates of Fincher Labs can participate. There's no formal sign-up needed – we just need to know that a new lead came from them. We do this by asking new leads how they heard about us, or they might mention someone's name.

Reward Format: By default, the reward is given as a $50 credit toward any Fincher Labs service. Existing clients can use that credit for updates, a future project, or professional email setup, etc. If the referrer doesn't have an obvious use for a credit (say a past client whose site is static and won't need anything further), we can offer a $50 gift card or cash equivalent as a thank-you. The $100 promotional referral, when active, follows the same format. We note in internal records whether the reward was issued as credit or delivered via gift card, etc.

Promotional Bonus: When we run the $100 referral promo (for example, perhaps during a slow season or end-of-year push), we communicate this to clients in our newsletter or personal emails: "For the next 3 months, get $100 for every website referral you send us!" Internally ensure to set an expiry date and honor the $100 for referrals that come in that window. After promo, it reverts to $50.

Conditions: - The referred client must mention the referrer either at initial contact or during the sales process. We often ask "Were you referred by anyone?" on our contact form or when we talk. If it's not mentioned, the referrer should ideally inform us, "Hey, I sent someone your way." - The referral reward is paid out only after the referred client signs and pays for the service (and at least their deposit, usually we wait until full payment or project completion to be safe). - If two people refer the same client, the reward generally goes to whomever the client identifies or who told the client first (this scenario is rare, but we'd handle case by case). - There's no limit to how many referral bonuses one can earn. If a client sends us 5

new clients, that could be $250 in credits – we'd happily give that because that's 5 new projects for us. - Selfreferrals or internal: obviously a client can't refer themselves under another name to get a discount – we'd vet that the new client is a bona fide separate entity.

Internal Tracking: - We maintain a simple referral log (maybe a section in the CRM or a spreadsheet) where we record: Referrer name, Referred client name, date referred, and status (signed? completed? reward given?). - When a referred project is completed, the operations manager ensures the reward is delivered. For credits, note it in the referrer's account (Zoho Books lets us have credit notes or just track manually and apply to their next invoice). For gift cards, purchase and send with a thank-you note/email. - We also thank referrers personally via email even if it's credit: e.g., "Thank you for referring [New Client]! We've applied a $50 credit to your account for future services. We appreciate you spreading the word about Fincher Labs."

Client Communication (Encouraging Referrals): - At project completion/handoff, we mention the referral program. For instance, in the handoff email (Appendix B.2 sample includes this), we say: "If you're happy with our service, we'd love if you tell others. We offer a $50 referral bonus for any new client you send our way!" - Periodically, we might send out a friendly reminder to our client list about the program, especially if we have the $100 promo. - Ensure our website (if we have a page or FAQ) mentions the referral incentive to encourage it even for those browsing.

Special Cases: - Sometimes, a partner (like a freelance graphic designer or IT consultant) might refer multiple clients to us. If it becomes a channel, we might formalize a slightly different arrangement (like a percentage commission or a larger flat fee). But until then, the $50 per site is our standard. - If a referred project is smaller than Core Website (rare, since most are that or more), we typically still give $50. If it was a notably tiny engagement (like a $100 update project referred), we might adjust or at least give something like $25. Use judgment, but usually referrals are for the main service. - Conversely, if someone refers a very large project (not typical in our current service list, but say we custom quote something bigger), we might consider thanking them extra (maybe more than $50) given the larger revenue. But the baseline is still $50 unless we specify a special case.

The referral program not only drives sales but also acts as a barometer of client satisfaction – people only refer if they're happy. So it incentivizes us internally to keep quality and service high.

Make sure all team members are aware of the program so they can mention it to clients conversationally: e.g., a developer talking to a friendly client can say, "By the way, if you know anyone else who might need a site, we have a referral bonus program; just let them or us know." Consistent mention (without being pushy) can plant the idea.

Metrics & Goals: We track how many new projects per quarter come from referrals. If it's low, maybe our program needs more promotion or clients need reminders. If it's high, that's great – it usually means we're doing well. This feedback loop is important.

In summary, the Referral Program is a win-win: clients get a little reward for helping out their network (and essentially discount on our services), and we get the best kind of new business – warm leads that already trust us due to the recommendation. Always fulfill referral rewards promptly and with gratitude to reinforce the positive feelings.

With the sales and onboarding practices clarified, we ensure potential clients are smoothly guided from initial interest to a signed contract, and we leverage existing happy clients to bring in new ones. Next, we transition into the operational side of actually executing the projects in a structured way.

5 Project Execution & Delivery

This section outlines the end-to-end process of executing a client project – from the moment a quote is signed (and deposit received) through designing, building, launching the website, and handing it off to the client. Adhering to a consistent process helps us hit our quality and timeline targets and ensures nothing is overlooked. We break the process into defined stages:

5.1 Project Kickoff & Requirements

Once the project is officially green-lit (contract signed, deposit in), we enter the kickoff phase.

  - Internal Kickoff Meeting: If the team is more than just one person, quickly huddle (in person or
virtually) to brief everyone involved. Cover the scope (e.g., "Core site with rush? any add-ons?"),
client's business overview, any initial ideas or concerns. Assign roles if needed (who's primary
developer, who will handle content or graphics, etc.). For very small projects, this might be as
informal as an email with project details to the developer.
- Client Kickoff Call/Email: Reach out to the client to officially start the project. This can be a
scheduled call or an email, depending on complexity and client preference:
- In this communication, re-confirm the requirements and vision. For example: "To confirm, we'll be
creating a 5-page site for YourBiz, including pages A, B, C... We'll make sure the design matches your
branding (using your logo and blue/green colors). You mentioned you like the layout of XYZ website – we'll
take inspiration from that. And we'll include a contact form and a gallery as discussed."
- If not done earlier, now is the time to get any additional input on style and content. Possibly ask the
client if they have any websites they admire (to gauge taste), or specific features they really want.
- Confirm the timeline: "We're aiming to have the first version ready by [Date/Day], and then we'll
incorporate your feedback and launch by [Date]." If rush, remind: "We'll be working swiftly to launch
within 24 hours, so please be available for quick feedback."
- Outline what you need from the client: typically content and access (offer the Content Accelerator: client can provide bullets; we transform into site-ready copy with AI + human edit):
- Text content for each page (if not already provided, maybe attach a simple content outline
document they can fill, or ask them to email in chunks).
- Images (logo, product photos, team photos, etc.). If they don't have any, see if they want
specific imagery or if we should pick stock.
- Credentials: Domain registrar login (if we'll handle domain pointing) or Cloudflare account
email if they have one. Email account info if we're setting up emails (or info to create those).
- Any social media links, contact info details, etc., to put on site.
- Clarify deadline for content: ideally "Please try to get these materials to us by [Date] so we
can stay on schedule."
- Explain how feedback will work: "We'll design and build the site structure with placeholder content if
needed, then show you a draft. You can then give us a list of any changes or tweaks, and we'll adjust
accordingly."

- Encourage questions, ensure the client feels engaged.
  • Content Collection: Often, clients may not promptly supply content. To keep momentum:

  • If some content is missing but we can start (like they gave home and about text but not services page text), we might begin building structure and plug placeholders in the missing spots.

  • If critical content is missing (like all images or any text), gently nudge them. Offer help: "If it's easier, you can bullet-point some info and we'll wordsmith it into the site." We can also draw from their existing materials (brochures, Facebook page info, etc.) if available.

  • Use a collaborative doc or email thread for content. Some agencies use forms or questionnaires – if we have one, great. If not, an email listing needed items works.

  • Initial Design Planning: Even as content is being gathered, we plan the design approach (Design by Assembly first):

  • Decide on a general site structure (navigation menu items, page hierarchy).

  • Choose whether a pre-designed template fits or if we're doing a quick custom layout. Since we use Next.js, perhaps we have an internal collection of components/sections (hero banners, content blocks, contact form section, etc.) that we can assemble. Identify which sections/pages the site needs.

  • If the client provided branding guidelines or a logo, sample the color scheme from that. If not, pick a color palette that suits their industry and existing materials.

  • If the client had a favorite reference site, note key elements from it (e.g., "client likes the big header image style of example.com").

  • Sketch out (mentally or on paper) the homepage layout at least, as that sets tone for other pages.

  • Decide on any stock images to use if client has none: e.g., search our stock library for relevant pictures.

  • Setting Up Work Environment:

  • Create a project folder/repo for the site. If using version control (Git), initiate a repo (maybe on GitHub or GitLab under our organization) named appropriately.

  • Set up the development environment: ensure we have the latest Fincher Labs starter template for Next.js (if we maintain one) and confirm the component bank to reuse before creating net-new.

  • If applicable, set up a live preview environment (like a staging link either on Vercel, Netlify, or Cloudflare Pages preview) – this can be useful to share with clients for review without full launch.

  • If we're using any project management tasks (like a checklist in Notion or Zoho Projects), list out the tasks: "Set up base project, Implement homepage, Create about page, Implement contact form, QA test, etc." Assignees, due dates can be noted.

  • Kickoff Complete: After these steps, we should have:

  • Clarity on requirements and aesthetic direction.

  • The necessary content/assets or a plan to obtain them.

  • Tools and project structure ready to begin building.

  • The client feeling informed about what's happening next and when they'll hear from us.

A well-conducted kickoff ensures the rest of the project flows smoothly. It is far better to resolve any ambiguities now than to discover misaligned expectations later. For example, if the client expected a booking system but never mentioned it until after first draft – kickoff is the time to have caught that by explicitly asking what features they need. Thus, having a checklist for kickoff can help: - Confirm pages and features. - Confirm design preferences. - Confirm content responsibilities. - Confirm timeline and milestones. - Confirm technical accesses (domain etc.).

From here, we proceed to the actual design and development knowing what we need to accomplish. File 3x Trigger candidates (repetitive manual actions) as automation tasks.

5.2 Design & Development

In this stage, we actually build the website according to the agreed scope. We typically fuse design and development in one phase for efficiency (especially given the short timelines and our use of modern web frameworks). Here's how we manage this stage:

 - Content-first (where possible): We try to structure the site around the content the client provides. If
we have the text and images early, great – it can drive design decisions. If not, we use placeholders
but design with the expectation of real content length (e.g., if we expect a paragraph but have lorem
ipsum, ensure design can accommodate more or less text gracefully).
- Homepage Design: Start with the homepage as it's the most critical. Implement the header (logo,
navigation menu) and footer (business info, maybe simple contact info or social links) as global
components. Then craft the homepage sections:
- Often a hero section (banner image or color background with the business name and tagline,
possibly a call-to-action like "Contact Us" button).
- A brief intro or about snippet.
- Perhaps highlights of services (if multiple, maybe icons or images).
- Any testimonials or logos of clients (if available).

- A contact prompt (maybe location/map if relevant or contact summary leading to contact page). Use
the client's color scheme and logo to guide style. Ensure mobile-first design – we might design in a
browser with responsive view toggling frequently.

- Other Pages Implementation: Build out the remaining pages, following a cohesive style:

- About Page: company history or bio info (format nicely with headings and images if provided, e.g.
team photo).
- Services/Product Page(s): each service described, could be text heavy or list of offerings. Use
appropriate imagery/icons to avoid walls of text.
- Gallery/Portfolio: if applicable, set up a grid of images or case studies.
- Contact Page: very important – include a contact form (fields: Name, Email, Phone (optional),
Message). Embed our Turnstile CAPTCHA in the form. Also list other contact info (address, phone,
email) and maybe a Google Map embed if location is important.

- Any other specific page (like FAQ or Pricing, etc.) as per client content.

- Development Workflow:
  • Using Next.js, create pages for each route. Utilize our component library or write components for reusable sections (e.g., a section for testimonials, a card for service listing).

  • Apply styling, likely via CSS modules, styled-components, Tailwind, or whichever approach our stack uses. Keep it consistent with our usual practices for maintainability.

  • Ensure images are optimized (use Next's Image component or optimization pipelines).

  • If any interactive element is needed (like a lightbox for gallery, or a form submission AJAX), incorporate the necessary packages or code.

  • Use placeholders for any late content but mark them clearly (so we know to replace "Lorem ipsum" text or stock filler text). For copy blocks, prefer our prompt library to generate first drafts, then perform human editing for tone, facts, and brand alignment.

  • Integration of Add-ons: If the project includes optional services:

  • Professional Email: This doesn't affect site design, but we might link the email on contact page. Meanwhile, someone else or at a later time we handle the DNS for email (ensuring to not conflict with site DNS changes).

  • Analytics or SEO considerations: If we plan to add Google Analytics or similar, insert the script or use a plugin. Basic SEO: ensure each page has a good

  • If the client requested anything like "I want to be able to blog," at this price we likely didn't include a CMS, but if we did, maybe integrate NetlifyCMS or simple markdown posts. However, base package likely no blog unless explicitly added.

  • Domain and SSL: not directly design, but in development we might test on a staging domain. We'll handle domain pointing in launch phase.

  • Regular Check-ins (if timeline is several days): If the timeline spans multiple days (standard 3-5 day projects):

  • It can be good to send the client a quick update mid-way. For instance, after day 2, maybe send a sneak peek screenshot or mention, "Homepage is coming together nicely, we're on track." This keeps them confident and engaged.

  • If any content is still missing, remind them gently now (so it doesn't hold up launch).

  • Internal Reviews: Before showing anything to client, do an internal review of the site:

  • Check that it meets the initial requirements (all pages present, features working).

  • Compare to any design references provided to ensure we captured the spirit.

  • Make sure text reads well (if we helped write any of it).

  • Ensure no placeholder text or obviously missing pieces remain.

  • Check form functionality (maybe temporarily pointing it to our email to test, or a test endpoint).

  • Test in at least Chrome and one other browser, and on mobile viewport.

  • Performance and SEO basics: Run a quick Lighthouse (or similar) audit if possible:

  • Aim for good performance (though small sites usually fine).

    - Ensure images are not huge files, etc.
    - SEO: ensure each page has one H1 heading, proper structure, alt tags on images. Create a simple
    XML sitemap if possible (Next can generate or manual since small).

    - Accessibility: check color contrast (particularly text vs background, to be readable).

    - Prepare a Demo for Client: When we're ready to present the site to the client for review, decide
    how:

    - Ideally, deploy it to a staging URL (like clientname.fincherlabs.com or a random preview link).
    This way, they can click around and test it themselves in a browser on their devices.
    - Alternatively, host it temporarily at the final domain but behind a "coming soon" or basic auth. But
    staging subdomain is simpler and more professional.
    - If neither possible, at least screenshots or a video walkthrough could be used, but interactive review
    is best.
    - Ensure the staging environment has Turnstile keys in test mode or working, so the form works
    (maybe direct form submissions to our email in staging, to not accidentally spam client's email
    before final).

At the end of this stage, we have a working website that meets the initial brief, pending client feedback. The development pace is quick but thorough thanks to our use of templates and checklists. Everything should be ready or nearly ready for launch except for any changes the client will request in the next phase.

We then move to presenting this work and getting the client's input.

5.3 Client Review & Revisions

With the site now built in a draft form, it's time to loop the client in for review. This stage is critical for client satisfaction – it's where they see their website for the first time and we make any necessary adjustments. Proper handling here ensures the client feels heard and ends up happy with the final product.

  - Presenting the Draft: Send the client an email (or call to arrange a screenshare, depending on
client's preference) to share the preview of the website. For most, an email with a link to the
staging site works. The email should be friendly and encouraging:
- "Hi [Client], Your website is ready for your review! We've put together the initial version based on your
content and our discussions. Please click the link below to browse through it. We think it's looking great,
and we're excited to hear your thoughts."
- Provide the link and any instructions (e.g., "Feel free to test the contact form – it's currently set to
send messages to our test inbox, so you can try it without worry.").
- If needed, mention known placeholders: "We used a placeholder image for [section] since we're awaiting
your photo – we'll swap that when you have it."

- Offer to hop on a call to go through it together if they prefer (some non-techy clients might want you
to guide them in real time).

- Guidance on Feedback: Clients may not always know how to articulate feedback on a website.
Encourage them to list any changes or questions:
  • "Let us know if anything isn't as you expected, or if you'd like any tweaks. Common things might be wording changes, swapping pictures, or adjusting colors. We want it to be just right for you."

  • If the client doesn't respond in a day or two, follow up asking if they had a chance to review and if they need any help.

  • Provide a simple template or list for feedback if necessary (some agencies give a form, but for our scale an email bullet list is fine).

  • Collecting Revision Requests: Once the client responds, gather all their feedback. It might come as an email with points like "Can we change X? I don't like Y. Add this info here…" etc. Sometimes they might call and describe; in that case, write down all items in an email back to confirm, e.g., "As discussed, the changes you'd like are: 1) Make the phone number larger on contact page, 2) Replace the hero image with the attached image of your store, 3) Change the tagline text to 'ABC…' and 4) Add your new testimonial on the home page. Let me know if I missed anything."

  • This confirmation avoids miscommunication and sets a concrete to-do list.

  • Scope Check: Quickly assess if any requested changes exceed the original scope significantly:

  • If a client suddenly asks for a new feature like e-commerce or an extra 5 pages not discussed, that's beyond scope. This needs to be addressed carefully: acknowledge the request, and propose it as a separate phase or that it would incur additional cost/time.

  • Most revisions are minor (text, colors, swapping images), which we include. Our internal rule is one revision round included, so we expect to do these without additional charge.

  • If the client's changes are so large that it's basically a rework (rare if kickoff was thorough), then the project manager might need to negotiate. But ideally, because we kept them informed and got content, this shouldn't happen.

  • Implementing Revisions: Make the requested changes promptly:

  • Change content as per feedback. Double-check grammar/spelling if client gives new text.

  • If they provided new images, optimize and insert them.

  • Adjust styling as requested (e.g., "make the blue darker," or "center that text," etc.).

  • Test those changes (especially if any functional adjustment like a different email for form).

  • If any change is not advisable (e.g., client wants something that hurts UX or SEO), diplomatically advise them. For example, "We can certainly do that, but just to mention – having all text in caps in that paragraph might be a bit hard to read for users. Perhaps we can try a slightly larger font instead?" Ultimately, if they insist, do it; but often they appreciate guidance.

  • Quality Check Revised Site: After revisions, do another round of quick checks:

  • Ensure new content didn't break layout on mobile.

  • All links still work (sometimes adding content can push things).

  • The site still looks consistent (the revision might be iterative, but view the whole site to ensure nothing was missed).

    • Showcasing Changes: Inform the client that the changes have been made:

    • "Hi [Client], we've completed the updates you requested. The site at the same link now reflects those changes. Please take another look and let us know if everything looks good!"

    • If the client had a lot of changes, they may have another small round of tweaks. Generally, we aim to wrap up after one pass, but be prepared for a "second round" of a few minor fixes. (We should accommodate a reasonable second pass if needed, even though we say one round, because client satisfaction is key. If it extends beyond, then perhaps they're indecisive – handle case by case, possibly gently reminding of scope if it gets excessive.)

    • Final Approval: Once the client responds positively – "Looks great, I love it!" or "Everything's good now, thank you!" – that's our green light to proceed to launch.

    • It's wise to get an explicit approval note: "Glad you're happy! Just to confirm, are we okay to go live with this version?" This not only excites them for launch but also serves as a record that they accepted the site.

    • If any launch scheduling needs (like they want it live by Monday morning specifically or want to coordinate announcement), confirm that.

    • Handling Delays: If a client is slow to provide feedback or content (perhaps dragging beyond the typical timeline):

    • Continue to follow up politely. If too much time passes, mention we can still launch with placeholders if needed and update later. But try to keep momentum; clients sometimes get busy, but we don't want projects lingering.

    • Internally, if a project stalls waiting on client, note that in project status. We might even consider formally closing a project if idle too long and asking for final payment (depending on contract terms). But usually for such small projects, it's resolved without that.

    • Client Communication & Relation: Throughout review, maintain a positive tone. Even if they critique something you did, don't take it personally – respond professionally: "No problem, we can change that." If they spot a bug or mistake, apologize and fix quickly: "Thanks for catching that! I'll correct it right away." The idea is to make them feel comfortable providing feedback and trusting we'll address it.

After this stage, we should have a site that the client has signed off on, meaning it's ready to be launched publicly. The revision process, if managed well, should strengthen their confidence in us (they see we respond and adapt quickly). We've ensured the site meets their expectations, so the launch will be a happy event, not a surprise.

Now we move to the final stage: deploying the site to the live domain and doing the formal handoff.

5.4 Launch & Handoff

This is the exciting culmination of the project: making the site live on the client's own domain and ensuring everything is in place for the client to take over operations (with our support safety net).

Launch Preparation: - Domain DNS Setup: If not done already, we must point the client's domain to our hosting: - If we manage DNS via Cloudflare: add the necessary DNS records (e.g., an A record pointing to our host's IP or a CNAME to our site if using cloud hosting, plus any AAAA if needed for IPv6). Ensure the proxy/CDN is enabled if using Cloudflare to get SSL and performance benefits. - If the client's domain is in their own registrar without Cloudflare: either they've given us access or we gave them instructions. Common setup might be an A record to an IP or a nameserver change to our environment. We likely prefer Cloudflare as it simplifies SSL. - Once set, allow time to propagate. Using Cloudflare usually it's quick globally. - Verify DNS propagation via a DNS checker for the major locations to ensure the update. - Hosting Deployment: Deploy the final site to production: - If using a static host (like Cloudflare Pages, Netlify, Vercel), update the project's settings to use the client's custom domain. Provision SSL certificate (most do this automatically – e.g., Cloudflare will handle it if we use their proxy, or Netlify/Vercel will with Let's Encrypt once domain verified). - If using our own server, upload files / set up the site container accordingly and configure the web server for that domain, and ensure SSL (use Let's Encrypt or our certificate to secure it). - Essentially, ensure that when someone goes to www.clientdomain.com or clientdomain.com , it serves the new site over HTTPS. - Set up redirects (like non-www to www or vice versa, http to https) for a polished result. - If email was set up, double-check DNS MX records remain correct post any nameserver changes (we likely accounted for it, but verify).

  - Final Test Live: Once the DNS is resolving to our site and the site is up on the official URL:
- Do a thorough run-through on the live domain. This includes testing the contact form (which now
should send to the client's email or designated address). We often do one test submission ourselves
to ensure deliverability, and inform the client we did so (or use a testing flag if we included one).
- Check all pages load correctly via the domain (no staging links left in code, etc.). E.g., ensure images
are loading from the correct domain paths, etc.
- Check the SSL certificate status (browser should show secure).
- If relevant, set up Google Analytics tracking ID now that domain is live (or ensure it's sending data).
- Performance: perhaps run one more Lighthouse on production just to confirm nothing changed.

- If domain has email tied (like using Zoho), ensure website launch didn't interfere (shouldn't if DNS
done right).

- Backup & Documentation: Archive the final code and content:

- Ensure our repository is up to date with final code.
- Create a backup of the site (e.g., zip the build or database if any – likely not, since static – but any
important configuration).
- This is so if any immediate post-launch issue arises (like client requests something weird or we need
to roll back a change) we have a snapshot.

- Document any credentials or specifics for internal records (like Cloudflare account used, etc.).

- Notify Client of Launch: Now, let the client know their site is officially live:
  • Ideally send an email (see Appendix B.2 for a template structure): Subject: Your Website is Live! Body: Excited and congratulatory tone. "Congratulations, [Client Name]! Your new website [domain] is now live for the world to see." - Provide the link. - Encourage them to check it out on different devices. - Mention any next steps (like clearing cache if they saw an old coming soon page might be needed). - If they have professional email set up, confirm that's operational (maybe have them test sending an email). - Remind them of the support window: "As you start using the site, remember we're here to support you. You have 60 days of complimentary support from today. So if you encounter any issues or have minor tweaks, just let us know." - Mention referral program as a friendly note (and any promotion if in effect). - Express gratitude: thank them for choosing us, say it was a pleasure working with them, etc. - Possibly attach or link a one-page "Site Guide" if we have one (some clients appreciate a PDF with their credentials and how to do basic things).

  • Optionally, a phone call could accompany this: especially if the client is the type to celebrate, give them a call telling them it's live and congratulate them, then follow with email.

  • Handoff Deliverables: Provide the client with any deliverables and credentials:

  • Domain: If we set up a Cloudflare account for them, give them login credentials or invite them to be co-admin. Ideally, transfer ownership to them (with guidance that we manage it but they have ultimate control).

  • Email: If email was configured, ensure they have admin credentials and user logins, and they know how to pay the subscription (for Google/MS).

  • CMS (if any) login: Not typical for our base, but if a blog or form backend panel exists, give them the login info.

  • Access to analytics: If we set up Google Analytics under our account, maybe share access or offer to transfer it. If under their account, ensure they can see it.

  • A copy of the site content: Not usually needed, since they can copy from the live site. But if they request the code, provide it. Standard deliverable is the running site itself; code is our IP but we usually share if asked.

  • Possibly a brief "Website Maintenance Tips" doc: e.g., suggestions like "if you upload images to your blog, make sure they're compressed" (only if relevant).

  • Emphasize they own the domain and content. If we host the site on our infra, clarify that arrangement (like it's free hosting, but if they ever want to move the site to another host we'd give them the files).

  • Support Period Commencement: Note internally the start of support window (60 days from launch date).

  • Put a reminder perhaps 2 weeks before it ends to send a check-in email to client (and maybe mention support is ending but we can continue help via pay-as-you-go).

  • During support, be responsive to any minor issues.

    - Final Invoice: If any balance is remaining (the second 50%), send the invoice the day of launch.

    - The launch email can separate the celebration from the invoice. Maybe send invoice a couple hours
    later or mention in email: "We will send the final invoice for the project separately. Thank you."
    - Usually, clients expect it since it was in contract. Keep it straightforward.
    - Follow up on payment if not received in whatever net terms given (often due on receipt).

    - Mark project as completed in our system only after final payment (but don't withhold any site stuff
    unless absolutely needed; trust but verify).

    - Post-Launch Monitoring: It's good practice to monitor the site for a couple days:

    - Check that the site stays up (especially after DNS propagation fully).
    - Ensure no contact form submissions bounce (maybe do another test after 24h with everything fully
    live).
    - If using Cloudflare, see if any settings need adjusting (like enabling Always Online, etc., as value-
    add).

    - This is mostly to catch any early issues.

    - Internal Project Retrospective: After launch, optionally have a short internal review:

    - What went well? Did we hit the 3-5 day target (or 24h if rush)? If not, why (content delays, etc.)?
    - Note any client feedback for testimonials or case study.
    - If any improvements to our process were identified (maybe we needed a better content collection
    method), note it for continuous improvement.

    - Update any metrics (project delivered on time, how many revision rounds used, etc.).

    - Client Follow-up: Consider a follow-up touchpoint maybe a week or two later:

    - Ask if everything is going well, any questions popped up.
    - They might have gotten feedback from their customers to share, which can be nice to hear.
    - It shows we care beyond just getting paid.
    - Also a good time to gently ask if they'd consider leaving us a review on Google/Facebook (if we have
    profiles) or a testimonial quote. Happy clients often will.

Now the project is officially handed off. The client has their website live and we have wrapped up our obligations, moving into the support phase.

By following this structured launch and handoff, we ensure a smooth transition. The client feels supported and in control of their new website, and we preserve the relationship for future opportunities (updates, referrals, maybe a redesign years later). A strong finish is just as important as a strong start, as it leaves the client with a positive final impression of the project experience.

6 Post-Launch Support & Maintenance

Our work doesn't end the minute the site goes live. Fincher Labs provides a safety net for clients in the immediate post-launch period and ongoing options for maintenance. This section details how we handle support after launch, what the client can expect during the included support window, and how maintenance requests are handled thereafter.

6.1 Standard Support Window (60 Days)

We include a complementary support period of 60 days (approximately two months) with every website project. This is essentially a warranty phase where we fix any issues and assist the client with minor adjustments as they get used to their new site.

Scope of Included Support: - Bug Fixes: If any problems are discovered on the site (a broken link, a button not working, a form misrouting, layout glitch on some browser, etc.), we address those promptly and free of charge. We want the site to perform perfectly, and sometimes issues only surface after launch with realworld use. - Small Content Adjustments: Clients might realize after a week that something needs a tweak – e.g., an address changed, a spelling error in text, or they want to swap an image. Within reason, we handle these minor edits at no cost during this window. We consider "minor" as things that take us a short time and don't change structure or design significantly. - Guidance and Training: The client can ask us how to do something related to the site. For example, "How do I view my form submissions?" (if we set them up to store somewhere) or "Can I get an email when someone fills the contact form?" (maybe we had it already, but any clarifications). We'll explain or adjust settings as needed. If there's an admin interface, we might walk them through again if they forgot. - Performance Monitoring: We keep an eye (lightly) on the site's performance and uptime in those first couple months. If, say, the site goes down (maybe due to server issue or domain DNS hiccup), we proactively fix it. Usually with our setup, downtime is unlikely, but we keep the client protected. - Feedback Implementation: Sometimes, the client's users give feedback ("Your site is great but on my phone this text is a bit small"). If it's a valid concern, we'll address it as a courtesy. We treat these as minor enhancements to ensure the client and their audience are happy. - Limitations: We clarify that the support window is not an extension of the revision phase for significant new work. For instance, if two weeks post-launch the client wants to add a whole new section or new feature that wasn't originally discussed, that falls outside warranty support. We'd happily do it, but that would be under the pay-as-yougo updates or a new quote if large. We phrase it as, "The complimentary support covers tweaks and fixes to what we delivered, rather than new features." However, we often err on generosity for small adds if it keeps goodwill (like adding one extra testimonial is small, we might just do it).

Communication During Support: - We remind the client at launch and in our handoff email about the 60day support. "Don't hesitate to reach out if you need anything or have questions in the next couple months – we've got you covered." - If a client does reach out with an issue, respond quickly (same day ideally) acknowledging and giving ETA. Support window issues get priority because we want them completely satisfied. - Track these issues internally (maybe via our support incident log) to ensure we resolve them and to learn if any common issues appear.

Transition out of Support: - As the 60 days near expiration, we usually send a friendly check-in (as mentioned earlier). For example, "It's been almost two months since we launched! Hope everything's going well. Just a reminder, your complimentary support period ends on [Date]. That doesn't mean we won't still help you – we absolutely will – but after that date any new changes or support would be subject to our standard maintenance

rates ($50/$100 updates or $25 support incidents). Let us know if there's anything you'd like us to address before then." - This serves two purposes: it prompts them to request any lingering tweaks now (so they don't come a week after and expect free), and it gently introduces the idea of paid maintenance going forward so they aren't surprised. - If an issue arises just after the support window (say a week over) that arguably was latent, we often will honor it as if in window – we're not strict to the day for genuine issues, especially if they rarely contacted us. The policy is more to manage expectations than to nickel-and-dime.

90-Day Extension (if applicable): - We mentioned sometimes 90 days – if for any reason we promised 90 (maybe as a sales incentive or to a special client), we will honor that. Internally we should note if a client has 90 instead of 60. - Also, occasionally if a client had delayed launch content or the site soft-launched, we might implicitly give them a bit more time. Again, we're flexible if needed but standard is 60. - If we decide to uniformly move to 90 in future for marketing reasons, we'd update docs; currently, it's 60.

Boundary Cases: - If in the support window the client requests something major (like "We decided we want to add e-commerce"), we treat that as a separate project, not free support. We explain kindly that that's beyond the original site scope and can provide a quote. - Support does not include content creation (e.g., writing new blog posts for them) or marketing services – if they ask about SEO improvements beyond the basics, we can advise a bit (like "we've done basic SEO; further content marketing is separate") or potentially upsell if we offer such.

The standard support window is an important value-add we advertise, and it also protects us in a way: clients know there's a limit, which reduces open-ended obligations, but also they feel safe to adopt the site. It fosters goodwill and often those first weeks are when any subtle bugs might surface, so it's our chance to catch and fix them with no friction.

6.2 Extended Support & Maintenance Options

After the complimentary support period ends, clients have a few options to get continued help with their website. We have structured, flexible solutions rather than a mandatory maintenance contract, given our small-business clientele often prefer pay-as-you-go. Here's how we handle extended support:

  - Pay-As-You-Go Updates: As detailed in Section 3.4, clients can request updates for a flat fee ($50
minor, $100 major). This is the primary mode for changes to content or adding small features post-
support window. We position this as a convenient way to keep their site fresh without an ongoing
commitment.
- In communication, when support ends or when a client later asks for something, we remind them:
"Yes, we can do that update for you. As per our maintenance options, that change would be considered a
[minor/major] update, so it'd be just $X. Let me know and I'll proceed."
- By framing it upfront, clients understand it's a paid service now, and they usually accept since the
pricing is transparent and fair.
- We treat these requests as new mini-projects in our system, schedule them promptly (most updates
done within a couple days), and invoice on completion.

- If a client has multiple updates at once, sometimes we combine as one "major" if appropriate or list
multiple line items if distinct tasks, whatever is clearer.
  • Remote Support (Post-window): If a client needs help or has an issue that isn't strictly an "update" (like they forgot how to do something, or their email client got misconfigured), that falls under our per-incident support ($25/40). We use the same approach as in Section 3.5.

  • We might say, "Sure, I can help troubleshoot that. We can schedule a quick remote support session. It's $25 for the session. When's a good time?"

  • Many times, if it's a really quick fix via email (like sending them instructions to reset a password), we might do it gratis especially if it's minor. We use judgment to not nickel-and-dime loyal clients for trivial things. The incident fee is more for when real time is spent or it's a recurring need.

  • The presence of this service assures clients that even without free support, they're not alone.

  • Maintenance Contracts (Case-by-Case): We currently do not have a subscription maintenance plan, but it's worth noting:

  • If a client actually wants ongoing service (like monthly content updates or monitoring), we could propose a retainer. For example, "$X per month for up to Y updates or dedicated support." We haven't formalized this because many of our clients have relatively static sites.

  • However, remain open to it if a client asks: e.g., "Can we have you on a retainer?" In that case, scope what they need (maybe they plan weekly blog posts, etc.) and come up with a custom plan. For now, it's handled ad hoc.

  • Emergency Support: After the window, if a site emergency happens (site down, hack attempt, etc.), we treat it as urgent support. We'd fix it, then likely invoice time or incident after. The client relationship often matters more, so we might fix first, then discuss costs if any. If it was due to our server or something, obviously no charge. If it was out of scope (like they let a domain expire), we'd help them fix it (renew domain) and might charge a small fee for time or might waive since renewing domain they pay for anyway. Hard to predefine, but our approach is to be helpful first, sort out billing second fairly.

  • Content Management by Client: If a site has a CMS (not typical for base package, but say they had a blog and we gave them a way to post), the client might handle some things themselves. We should still be available if they need help or if they accidentally break formatting. We'd charge for fix if it's clearly their doing after support period, but often just help.

  • Technology Updates: Over time, frameworks or dependencies might need updates (e.g., if there's a security update to something). We don't have a formal process for that on static sites (most content static so not much to update). For more dynamic projects, a maintenance plan might include periodic updates. But with static Next.js builds and no custom server code, there's low maintenance in that sense.

  • Encouraging Maintenance: Every so often (maybe annually), we could reach out to clients offering a "site checkup" or asking if they'd like any updates. This can prod some business (someone might say "Actually yes, I've been meaning to update the gallery"). It's also just good client relationship management.

    - End of Life: After a few years, a site may need a redesign or more major overhaul (new branding,
    etc.). Our extended support covers small incremental changes, but at a point, we might recommend
    a new project. Example: A client from 3 years ago might come asking for a redesign; we'd quote a
    fresh package price rather than doing endless updates.

    - Records and Reminders: We keep records of all updates done for a client. If a client frequently
    requests updates (like every month they have something), it might be worth suggesting a retainer to
    save them money or at least bundling tasks quarterly to be efficient.

    - We can also recognize our good repeat clients and occasionally give a discount or freebie as thanks
    (like "you've done many updates with us, we threw in that small change at no charge").

Policies for Updates Outside Support: - Payment for maintenance tasks is typically due upon completion or within a short term since amounts are small. We often batch multiple small updates into one invoice to not inundate them with micro-bills. - If an update request is large enough (like several $100 tasks at once), we might ask for approval with an estimate first, just like a mini quote, to ensure they agree to the cost. - If a client disputes a charge (rare if communicated well), try to resolve amicably – maybe they thought it was minor enough to be free; we might waive once but clarify for future.

Attitude and Branding: - We want clients to feel that even though the free support ended, we did not abandon them. They should feel we are still essentially their "web department" on call. Just that now, beyond the warranty, it's pay-per-service, but the relationship and care remain. - By being responsive and fair in the maintenance phase, we often earn referrals and repeat business. Many businesses expand or create new ventures and come back to us for new sites precisely because we took good care of them.

6.3 Domain Renewal Assistance

Domains are usually registered for a year at a time (or more), and it's critical that clients renew them to keep their site online. Many small business owners can be forgetful about this, or not tech-savvy, so Fincher Labs offers support to ensure domain renewal doesn't become a problem.

Our Domain Policy (Ownership): We ensure the client is the owner of record for their domain. That means their name/business is listed in WHOIS and they have ultimate control (usually via their own account at a registrar or Cloudflare). In cases where we purchased the domain on their behalf (using our account for convenience), we consider that a temporary arrangement and will transfer it to them or help them set up their own account to move it there. We avoid holding domains long-term to prevent any appearance of hostage situation, and to simplify things if they ever move away (which we hope they don't, but it's ethical to allow easy exit).

Renewal Reminders: - We keep a note of each client's domain expiration date if possible (for those we registered or if they shared details). Maybe an entry in a spreadsheet or calendar for each domain expiring.

  • At least 30 days before expiration, we email the client a reminder: "Your domain [yourbusiness.com] is coming up for renewal on DATE. Make sure to renew it so your website stays online. If you registered it yourself with [Registrar], you should have received a reminder from them as well. If you need any assistance with the renewal process, we're here to help." - Often registrars auto-renew if a credit card is on file. We encourage clients to set that up if they haven't: "We recommend enabling auto-renewal or double-checking that your billing info is up to date at the registrar, so you don't accidentally lose the domain." - If we manage the domain in our

account, we handle the renewal but will coordinate payment with the client (unless we offered first year free or something). Usually, we charge them whatever the domain costs us (no markup, or a tiny admin fee if any, but typically domain is cheap so we might waive small differences). - Document these communications in case a client forgets; we can show that we did remind them.

Assisting with Renewal: - If a client is uncomfortable or too busy to renew themselves, we can step in: - If it's their account: we might hop on a call and walk them through logging in and clicking renew. - If they provide their credentials (some do, or share screen), we can do it for them. - If it's our account: we just renew and invoice them the fee (or add it to next service invoice). - After renewing, confirm with client that domain is extended to new expiration date. - If the domain expired unintentionally (client missed all notices): - Act quickly. Many registrars have a grace period (usually 30 days) where it can be renewed normally. We'll guide them to renew ASAP. - If beyond grace, domain might enter a redemption period (with higher fees). We'd inform the client and help them navigate (some might balk at the high fee, but losing domain is worse). - If the domain was lost (someone else bought it after expiry), this is worst-case. We try to help: maybe contact the new owner if it's squatting (can be expensive) or help client choose a new domain and update the site. This scenario is what we try to prevent vigorously with reminders.

Domain Records Maintenance: - Over time, if a client changes something (like moves email host, or adds a subdomain), they might come to us for DNS help. We consider that part of domain support: - E.g., client wants to set up Office 365 email a year later – we'll add the needed DNS records for them (likely as a paid support or update, unless trivial). - If they want another service (like verifying domain for a marketing tool), we can assist with the DNS entry. - These are usually quick, so sometimes done as courtesy if client is in good standing or as a minor update cost if it takes more effort.

Registrar Credentials: - We encourage clients to keep their registrar login safe and note it somewhere. If they lose it, we can try to help recover (contact registrar, etc.). That's another reason we set up with their email so recovery goes to them. - For domains under our account, we ideally transfer out: either transfer to their own account at same registrar or push domain to them. If not, at least make sure we have a method to get it to them if ever needed (some trust us to keep it, but we'll never hold it if they request transfer).

Renewal Fees: - We clarify that domain renewal fees (and any third-party service fees) are separate from our web design fee. We often mention approximate cost at the start to avoid confusion. - If a domain's price changes (some TLDs have varying prices), inform the client at renewal time (most .com remain similar). - If we decide to cover a renewal (maybe as a goodwill or part of a promotion), tell the client "we took care of it for this year." But that's optional and case-by-case (like maybe as a gift for a referral, etc.).

Domain Privacy: - Many registrars offer WHOIS privacy. We often enable it if it's free to protect client from spam (assuming we have client's permission; usually fine). - If it costs extra, we ask the client if they want it. Some will pay $5-10/year extra, some won't mind either way.

Expired Domain Response: - If a site suddenly goes down and we find the domain expired (maybe client missed everything), our immediate step: contact client, explain the situation calmly, assist to recover if possible. It's urgent because they might be losing emails too. This scenario tests our support commitment; we do what we can even if out of support window, because it's critical.

Domain Changes: - If a client wants to change domain entirely (rebrand), that's a new mini-project: - We'd help them get new domain, map site to it, and set up redirects from old to new to preserve SEO. - That likely

involves some paid work (update domain config, possibly content changes for the new name). - But handle similarly with care.

Hosting Renewal/Changes: - Since we handle hosting and it's free at our current scale, there's not a direct renewal, but we do monitor our platform usage. - If in future we had to charge for hosting (maybe if a site is very high traffic or using paid features), we'd discuss with the client separately. - Also, if we ever need to migrate the site to a new platform (say we move from one provider to another for our own reasons), we'd do that transparently and inform the client if any DNS update needed. That's on us as part of maintenance.

In summary, domain and renewal support is part of our end-to-end service philosophy: we don't just throw a site online; we help ensure the lights stay on. By managing or guiding domain renewals, we prevent avoidable disasters and reinforce trust. Clients often really appreciate a reminder about something they would have forgotten. It's a small thing for us but can save them from downtime or losing their web identity.

Now that we've covered support and maintenance, the next sections will focus on standards and internal practices (technical, quality, risk, etc.), which ensure that throughout all these processes, we are delivering at a consistent, high-quality level.

7 Technical Standards & Security

Fincher Labs has established a standardized technology stack and best practices to ensure our websites are reliable, secure, and high-performing. By default, we use modern frameworks and services that give our small business clients an edge (fast load times, good SEO, strong security) without the overhead of managing complex infrastructure. Below are our technical standards and notes on security and privacy practices:

7.1 Platform & Framework (Next.js)

Framework Choice: We build our websites using Next.js, a popular React-based web framework. Next.js allows for hybrid static and server-side rendered pages, but for our typical projects we often leverage its ability to generate a static website (Static Site Generation) or lightly use serverless functions where needed (like handling form submissions if we don't use a third-party service).

Benefits: - Performance & SEO: Next.js supports pre-rendering content, meaning our sites can be delivered as static HTML that loads very quickly and is easily indexed by search engines 1 . Fast load times and proper SEO tags (which we include) help our clients rank better on Google and provide a good user experience. - Modern Development: Using React/Next.js means we can create component-based UIs, which makes development efficient and consistent across pages. We also benefit from a large ecosystem of libraries if we need to extend functionality. - Flexibility: If in the future a site needs to scale up or add interactive features (like a user login or e-commerce), Next.js gives us a path to do so (via its API routes or transitioning to dynamic rendering) without rebuilding from scratch. - Familiarity: Our team is proficient in Next.js, which reduces development time and minimizes bugs since we're working with known tools.

Do-Not-Reinvent Rule: Prefer our existing section/component catalog first. Creating net-new components requires documenting intended reuse and adding them to the library.

Coding Standards: - We maintain clean, well-organized code. Use meaningful component names, and include comments for any non-obvious code sections. - Mobile-first design approach in CSS to ensure

responsiveness. - All projects adhere to ESLint rules and Prettier formatting (we have a standard config we apply). - We keep third-party libraries minimal to avoid bloat. For example, for a simple image carousel we might use a lightweight library or write a small script instead of pulling in a huge package. - Version control: All projects are tracked in Git, and we commit frequently with clear messages. This is crucial for teamwork and rollbacks if needed. - We avoid storing any sensitive keys or secrets in the code repository. Instead, use environment variables for things like API keys (which are then configured on the deployment platform securely).

Hosting & Deployment Integration: Next.js projects are easily deployed on platforms like Vercel (by the creators of Next.js) or other static hosts. We typically: - Use Cloudflare Pages or Vercel for hosting static exports, as they seamlessly integrate with our Git workflow (push to main branch triggers deployment) and provide CDN distribution for global speed. - If a project needs serverless functions (like emailing a form), those platforms support it (e.g., Vercel Functions) so we can keep everything within the Next.js project.

Scalability: While our current projects are small, our tech choices mean a site could handle large traffic because: - Static content is CDN-cached (almost infinitely scalable for read traffic). - Cloudflare's network can handle spikes. If we had dynamic parts, we'd leverage serverless which auto-scales within limits. - This means our clients likely never have to worry about "outgrowing" their brochure site's tech. If they outgrow in content or design, we redesign, but the backbone is solid.

In summary, Next.js is our standard framework for delivering fast, SEO-friendly, and maintainable websites 1 2 . Sticking to this standard improves our efficiency (we reuse knowledge and possibly code across projects) and ensures each project benefits from up-to-date web best practices.

7.2 Hosting & DNS (Cloudflare)

Hosting Infrastructure: We host websites on a cloud platform with a global content delivery network (CDN) to ensure fast load times everywhere and high reliability. Our go-to is Cloudflare for DNS and CDN: - We often deploy static sites on Cloudflare Pages (which automatically uses Cloudflare's CDN). If not Pages, we might use Netlify or Vercel which also provide CDNs, but we still use Cloudflare for DNS management in most cases. - Cloudflare's network caches content globally, meaning someone visiting the site from Europe or Asia will load it from a nearby server, often resulting in sub-second load times. - Cloudflare also offers excellent uptime and DDoS protection, which means our clients' sites are resilient against traffic spikes or malicious attacks at the network level. - Using Cloudflare DNS is also very convenient: their DNS propagation is extremely fast and the dashboard is developer-friendly. We typically point the domain to Cloudflare's nameservers and manage DNS records there.

SSL/TLS: Every site we launch uses HTTPS encryption by default. Cloudflare provides free SSL certificates (either by proxying traffic or via origin certificates): - This ensures that all data between the user and site is encrypted (important even for basic sites to avoid browser "Not secure" warnings). - It boosts SEO (search engines favor secure sites) 3 . - We set all sites to redirect http -> https so there's no insecure access. - We can use Cloudflare's SSL in "Full (strict)" mode with either a Let's Encrypt cert on origin or Cloudflare Origin cert to ensure end-to-end encryption.

DNS Records & Management: - Typical setup: an A record for the root domain (or an CNAME depending on host requirements) and perhaps a CNAME for www to the root. We also add any needed MX, TXT records (especially if we did email setup). - We keep DNS records minimal and tidy; remove any that are not

needed (some registrars add default ones that are irrelevant). - We enable Cloudflare features like: - Always Online: a feature that can show a cached version of the site if our host goes down. - Auto minify: Cloudflare can minify JS/CSS/HTML on the fly (though often our build already does). - Browser cache TTL and Edge cache TTL: to optimal values, though the static host usually sets long cache with hashes in filenames. - Security: Web Application Firewall (WAF) and basic security level to at least "medium". This helps block common threats.

Turnstile (Cloudflare) integration: Covered in next section but relevant here as it's a Cloudflare service that pairs with our hosting.

Cloudflare Benefits Recap: - Reduces latency worldwide. - Shields from certain cyber threats (SQL injection, etc., via WAF rules). - Provides analytics on traffic which we can review if needed for performance or security insights. - Easy DNS editing and immediate propagation help us manage changes swiftly, which is great during launches or updates.

Alternative Hosting: If not on Cloudflare, our backup is Vercel or Netlify: - Those are also globally distributed and come with automated deployments on Git push. They also provide free SSL via Let's Encrypt.

  • In such cases, we often still use Cloudflare for DNS just because of familiarity, unless using Netlify DNS or etc. But Cloudflare's features usually make it worth continuing to route traffic through them (though double CDN can be redundant, we sometimes bypass Cloudflare caching if using another CDN host, using it just for DNS and maybe security).

Serverless Functions or Backend (if any): If a site uses an API route (Next.js serverless function, e.g., to handle a form submission or send an email): - Vercel or Netlify will run those on their servers near the region of request, which is fine. Cloudflare also has Workers which we could use for small scripts if needed (Cloudflare Pages supports Functions as Cloudflare Workers). - We lean towards serverless (stateless) logic rather than maintaining a traditional server; it's easier and scales with little config. That also means no server maintenance for us (no OS updates, etc.).

By standardizing on Cloudflare for DNS/CDN/SSL, we ensure every site is fast, secure, and globally accessible without additional cost to us or the client at our current scale. If resource usage or feature set materially changes, we will discuss options transparently.

We periodically review Cloudflare's offerings (they continuously improve things like image optimization, edge functions, etc.) to utilize any features that could benefit our projects.

7.3 Forms & Spam Protection (Turnstile)

Nearly all our client websites include a contact form or similar input from users. To protect these forms from spam bots without burdening real users, we implement Cloudflare Turnstile on our forms.

Cloudflare Turnstile is an invisible CAPTCHA solution 5 6 : - It does not show any challenges (no "click all images with traffic lights") to most users. Instead, it quietly runs in the background when the form loads and uses non-intrusive browser checks to verify the user is likely legitimate. - If Turnstile detects something suspicious, it may prompt a simple checkbox or challenge, but this is rare and far less annoying than Google reCAPTCHA's often multi-step puzzles. - Privacy advantage: Turnstile does this without harvesting personal

data or tracking users across sites, unlike some other CAPTCHA providers. This aligns with our no PII storage and user-friendly principles.

Implementation: - We sign up for a Turnstile site key in our Cloudflare dashboard for the client's domain (Cloudflare offers Turnstile even if you're not using Cloudflare for full site, but in our case we often are). - Add the Turnstile widget script to the contact form page. - Our form (whether it's handled via a serverless function or third-party service) verifies the Turnstile token server-side on submission. We use Cloudflare's API endpoint to validate the token and ensure it was solved by a human. - Only if the validation passes do we proceed to actually send the form contents via email or store them. - If validation fails (likely a bot), we reject silently or show a generic error to the user. In practice, Turnstile catches bots effectively, so this keeps spam out.

Why not reCAPTCHA?: - We prefer Turnstile because it improves user experience (no or minimal interaction required, whereas Google reCAPTCHA v2 can be frustrating for users, and v3 is invisible but has privacy concerns) 5 . - Also, Turnstile avoids adding Google-related cookies or trackers, aligning with GDPR friendliness (we might avoid needing cookie notices if we have no trackers). - This difference can be a selling point: our clients won't get junk emails from their forms (or very few), and their users won't hate the contact form.

Testing Turnstile: - We always test the form with Turnstile in development (Cloudflare allows a test mode). Ensure that our form backend properly requires the Turnstile token. - In staging and production, monitor initially if any spam gets through. So far, with Turnstile's low friction, we rarely see spam submissions.

Alternate/Additional Measures: - On some forms, we also include basic validation (like requiring proper email format, etc.) – this is not spam prevention but good practice to reduce junk input. - We do not store form submissions in a database by default (see section 7.4 on data); we typically send them directly to the client's email. That means if a few spams slip through, the client might see them in email, but not accumulating on a server. - If a particular site gets targeted by spam despite Turnstile (rare, but spammers evolve), we could add further questions (like a simple question field) or tighten Turnstile (Cloudflare may increase the challenge level automatically).

Other Forms: If the site has any other input (like a newsletter signup or comment box, though usually not for brochure sites): - We would also protect those either via Turnstile or by using an external service that has anti-spam (for example, if a client insisted on a blog with comments, we might use something like Disqus or a form with Akismet). - The principle is to not allow open inputs to be abused as a vector (e.g., an email form that could be used to send spam – our backend would throttle or limit recipients if we had an email friend feature, etc. We mostly avoid those features).

Cloudflare Turnstile being free and managed by Cloudflare means one less headache – we don't have to maintain an anti-spam algorithm, and there are no additional costs for the volume of usage our small sites get. We standardize on it so all our clients benefit from spam-free, hassle-free forms.

7.4 Data Privacy (No PII Storage)

Fincher Labs has a policy of not storing personally identifiable information (PII) on our servers for standard projects. This is both to protect user privacy and to reduce liability and compliance burdens on us and our clients.

What this means: - We design our systems such that any personal data (like names, emails, phone numbers entered in contact forms) is not permanently stored in a custom database that we maintain. Instead, for contact forms, the information is typically emailed directly to the client's email address. The data might transiently pass through a server or function to trigger that email, but we don't keep it longterm. - We do not build features that collect user accounts or profiles on these small sites. No login systems, no storing of user lists, unless explicitly required by a project (which would then fall outside the "standard package" and need additional planning for security). - If a client requests something like a newsletter signup form, we integrate it with a third-party service (e.g., MailChimp embed) so that the emails go straight to that external system which has its own compliance measures (GDPR, CAN-SPAM, etc.), rather than us capturing them. - For analytics, we either use privacy-friendly analytics (like privacy-focused Google Analytics settings or a simple Cloudflare Web Analytics) that don't track personal data, or none at all. We avoid embedding any third-party that excessively tracks users unless the client insists and we then note it in privacy policy.

Advantages: - Security: If we don't store user data, we eliminate the risk of a data breach of that data. Hackers can't steal what we don't have. Our sites are mostly static, so attack surface is minimal. - Compliance: Regulations like GDPR, CCPA, etc., impose strict rules on handling PII. By not storing any, we and our clients generally fall outside the scope of most onerous requirements (no need to handle data subject requests, etc., for most brochure sites). If the site does something like a contact form, just emailing it is usually seen as "communication requested by user" which is fine. - Simplicity: It simplifies development and maintenance – no databases to manage, no backups needed for user data, no privacy policy complexities beyond basic site stuff. - Trust: We can tell users (and include in the site's privacy note) that "We do not store your personal information on our servers. Information you submit is used solely to respond to your inquiry." This can build trust with visitors.

Privacy‑Friendly Patterns: Prefer privacy modes for embeds (e.g., YouTube nocookie, map privacy toggles) and cookieless analytics where possible (e.g., Cloudflare Web Analytics). If clients request marketing pixels or trackers, they must provide consent tooling and the privacy page must reflect it plainly.

Exceptions & Mitigations: - If a client does need to collect and store data (say they want a client portal or event registrations stored), that moves into a custom project territory. We'd then ensure to use secure databases and likely recommend a known solution (or plugin) rather than writing our own from scratch. We'd also incorporate encryption, user authentication, etc. But such features are beyond our core package because of these complexities. - Some PII may inadvertently be collected by third-party tools (ex: if we embed a Google Map, Google might collect user IP which is considered PII). We inform clients of such things and ensure the site's privacy policy covers it. We also try to use privacy-mode embeds when available (like YouTube's nocookie domain for embedded videos). - Emails from forms: While we don't store them, the client now has them in their inbox. We advise clients to handle those responsibly (e.g., if they plan to put them into a mailing list, they should get consent, etc.). That's more of a business practice note than our technical doing.

Email Setup & PII: In setting up professional email for clients, we ensure: - We're not storing their email passwords anywhere in our systems after handoff. If we needed to, we'll reset and give to them, but we don't keep them. - Emails themselves might contain PII (their correspondence with customers). By using reputable providers (Zoho, Google), that data is secured and managed by those companies under their compliance frameworks, not by us.

Backups: Since no user data, our backups are just site content (which is public or from client). So even if a backup were exposed, it's not revealing customer data. That said, we still secure any repository or backup location.

Cookies and Tracking: We avoid adding cookies unless necessary: - Our sites typically only might use a cookie for Turnstile or Cloudflare's security (which are anonymized) or for analytics if added (we prefer cookieless methods). - If a client wants a Facebook Pixel or similar, that's PII in a sense (tracking users). We would advise on the implications and require them to have a proper cookie consent if needed. But in our base approach, we lean away from those unless client specifically uses them for advertising.

Privacy Policy Page: We recommend clients have at least a basic privacy policy statement (especially if they have a contact form). We can provide a generic template that says what we do (no data stored, info only used to contact back, etc.). If needed, we'll help them put that on site (maybe in footer link).

Sticking to a no-PII storage rule keeps our operations lightweight and our clients safe from a lot of potential headaches. It's a conscious design choice that aligns with modern privacy expectations and makes our lives easier in terms of security management.

By following these technical and security standards (Next.js, Cloudflare, Turnstile, and not storing PII), we achieve a robust, secure, and ethical foundation for all projects: - Users get a fast and safe browsing experience. - Clients get a site that's difficult to hack and easy to maintain, without surprise regulatory issues. - Internally, we can manage multiple projects without having to worry about server upkeep or data breaches, letting us focus on delivering value.

Next, we'll discuss how we ensure quality through systematic checks and manage risks, further solidifying the reliability of our services.

8 Quality Assurance

Delivering a high-quality website is paramount to maintain our reputation and client satisfaction. Fincher Labs employs a thorough Quality Assurance (QA) process before any site is launched. This includes testing functionality, compatibility, performance, and content accuracy. We also have a checklist of items to review for each project to catch any oversights.

8.1 Pre-Launch Quality Checklist

Before a website goes live (or is presented to a client for final approval), we go through the following QA checklist:

 - Cross-Browser Display: Test the site on all modern browsers:
- Google Chrome (latest version, desktop and mobile views)
- Firefox (desktop)
- Safari (especially on iPhone/iPad for mobile)

- Microsoft Edge (desktop; since it's Chromium-based, it should mirror Chrome, but we still open it
once). We look for any layout issues, font rendering problems, or features (like flexbox, etc.) not
working as expected on a specific browser. Our tech stack is pretty standard, so issues are rare, but
we verify.
  • Responsive Design (Mobile/Tablet/Desktop): Use dev tools or actual devices to check the site at various screen sizes:

  • Small phone (e.g. iPhone SE or an older Android size)

  • Common smartphone (e.g. ~375px width, iPhone X/12 size)

  • Tablet (iPad width ~768px, both portrait and maybe landscape)

  • Desktop standard (~1440px width)

  • Large screen (if we expect someone might open on 4K monitor, check nothing goes too wide or breaks). Ensure that navigation is usable on mobile (hamburger menu works, etc.), text is readable (not too small), images resize correctly, and there's no horizontal scroll or cutoff content. We also verify touch elements have appropriate spacing for fingers (not too small or close).

  • Performance Optimization:

  • Run a Google Lighthouse or WebPageTest on the staging site to get performance scores. We aim for green scores (90+). If something is slowing it (maybe a large image), we address it: compress image further or use Next.js image optimization.

  • Check page weight and number of requests. For a simple site, it should be small (a few hundred KB maybe not counting images). Ensure no huge libraries unintentionally included.

  • Ensure lazy loading is in place for below-the-fold images (Next's handles this by default).

  • Check that caching headers are set properly (our static host usually does, but confirm by looking at network response headers).

  • On mobile network simulation, confirm site still loads reasonably fast (3G test in Lighthouse).

  • SEO & Meta: Confirm all pages have appropriate meta tags:

  • Unique

  • Meta description for each page (about 150 characters of summary including a keyword and call to action if possible). We often write these if the client hasn't.

  • Proper use of header tags (H1 once per page for main heading, H2/H3 for subsections logically). No missing H1.

  • Alt attributes on all images, describing the image or using relevant keywords (helps both accessibility and SEO).

  • If the site is being indexed, ensure no stray noindex tags (unless intentionally e.g. on a thank-you page, etc.). Conversely, if during staging we had it noindex, remember to remove that before launch.

  • Create a simple XML sitemap listing all pages and submit to search console if part of our launch routine (or at least provide it so search engines find it).

  • Link to external references open in new tabs (using target="_blank" , so visitors don't fully leave the site).

  • Check that internal links are not broken. Click through the nav and any in-text links.

  • If any page has very little content or dummy text that wasn't replaced (sometimes an about page might be sparse if client gave nothing), flag it and either remove the page or ask client for at least a paragraph, as empty pages hurt SEO.

  • Accessibility:

  • Ensure images have alt text (reiterating from SEO, but that's key for screen readers).

  • Ensure link text is descriptive (no instances of just "click here" without context).

  • Color contrast: use a tool (or eyeball) to ensure text vs background has sufficient contrast, especially for small text. Our standard is to meet WCAG AA contrast ratios at least for body text.

  • Check that the site can be navigated via keyboard (tab through links and form fields, see if any focus outlines are missing or hidden).

  • If any video or audio content (rare in our small sites), ensure controls are present and maybe captions available.

  • We're not doing a full WCAG audit on these small projects due to scope, but we attempt basic compliance so no major barriers exist.

  • Functionality Testing:

  • Forms: Test each form thoroughly: - Enter valid data and submit: verify it behaves correctly (shows success message or redirects appropriately). Confirm the email is received by the intended recipient (for staging we may send to ourselves; for production, send a test to the client or cc ourselves to ensure deliverability). 4 - Enter invalid/missing data: ensure our validation works (e.g., try submitting without an email or with an obviously wrong email format, see that it prompts user correctly). - If a honeypot field or Turnstile is present, test that a submission without the token is rejected (simulating a bot).

  • Email Links: If any email addresses are on the site (mailto links), click them to ensure they open an email client.

  • Phone Links: If a phone number is on site, on mobile make sure it's clickable and dials (tel: link).

  • External Links: Test external links (social media, partner sites) to ensure they go to correct pages and open new tab.

  • Interactive Elements: If we have any (like a lightbox gallery or slider), click through them. Try edge cases like clicking next on last slide (should loop or disable). If video embed, does it play? If map, does it load?

  • If any custom script (like an animation on scroll), ensure no console errors and it degrades gracefully if JS off (at least content is still visible).

  • Content Accuracy:

  • Proofread all text for typos, grammatical errors, and consistency (e.g., if the company name is sometimes spelled differently, fix that).

  • Double-check business-critical info: phone numbers, addresses, emails, hours of operation. These must be exactly as provided by client. It's easy to slip a number, so verify with client's original email or materials.

  • Ensure the logo is the latest version the client provided (sometimes they give a new one mid-project, use the correct one).

  • If we compiled content from various sources, unify tone and persons (e.g., don't mix first person "I" and third person "The company" oddly).

    • Check that image file names (if visible somewhere, or alt text) don't have placeholder references. Ensure no placeholder content remains anywhere (e.g., leftover lorem ipsum on an obscure page).

    • Error Handling:

    • Try accessing a non-existent page (e.g., /asdf) and see if our 404 page appears (we typically create a simple 404 page). If not, configure one (Next.js can generate one).

    • If any API calls or dynamic pieces are used, what happens if they fail? E.g., if contact form email server is down, does the user get a generic error? That might be fine, but ensure they see a message rather than nothing.

    • Backup and Version Finalization:

    • Make sure the final version of the code is committed and tagged (like v1.0 launch).

    • Export static version (if using static generation) for archival or fallback.

    • Have a rollback plan (maybe not always needed, but at least have the previous site backup if we replaced one).

    • Client-Specific Checklist Items:

    • Some clients might have special requests (like "make sure to include my certification badge on the footer"). Confirm those are in place.

    • If the client provided a checklist or content doc, double-check everything from it is implemented.

We can maintain this checklist as an internal template and physically check off each item per project. This reduces the chance of "oops, I forgot to remove that dummy text" or "the form goes nowhere" scenarios which could embarrass us or frustrate the client.

Performing QA should be done by the developer and ideally a fresh set of eyes (if available, another team member) because the developer might become blind to their own work's quirks. Even a quick peer review can catch a lot.

8.2 Testing & Review Process

Beyond the specific checklist, we have an overall testing process integrated into our workflow:

 - Incremental Testing: We don't wait until the end to test everything. During development, as each
feature/page is completed, we test it in the browser. This catches issues early. For example, after
coding the contact form, test it right away instead of discovering a bug at final QA.
- Staging Review: As noted in Project Execution, we often review the site in a staging environment
internally before showing the client. That internal review follows the QA checklist largely. We treat
staging as a dress rehearsal for production.
- Client Feedback Loop as QA: When the client is reviewing, sometimes they act as an additional QA
resource (they might notice a misspelling or a misalignment). We treat all client feedback seriously
and thank them for noticing issues. We incorporate valid points not just as one-off fixes but to

update our checklist if needed (e.g., if a client spotted we forgot favicon, we add "Favicon set" to checklist).

  • Post-Launch Monitoring (Shakeout Testing): After launch, we remain vigilant for a short period:

  • Monitor analytics or error logs if available (like Vercel/Netlify functions logs for any error spikes).

  • Use uptime monitoring (maybe a free service or Cloudflare's analytics) to ensure site remains accessible.

  • If any unusual activity happens (like form gets spam despite Turnstile, or user reports an issue), address it swiftly.

  • We sometimes manually test the live site again the day after launch just to double confirm nothing like DNS propagation issues (e.g., some might hit non-www domain and find an issue if we misconfigured redirect).

  • Regression Testing on Updates: For any subsequent update (especially major ones), we run through relevant parts of the QA list again:

  • If we add a new page in an update, test its links, responsiveness, etc.

  • If we change a core style, scan other pages to ensure it didn't break something.

  • Automated Testing (if feasible): Given small sites and quick timeline, we don't usually write automated tests. But we do sometimes use online validators:

  • HTML validation (w3c validator) to catch any broken HTML.

  • Accessibility automated check (there are browser extensions or Lighthouse can flag some A11y issues).

  • Performance and Best Practices via Lighthouse. These are not strict gating items but provide additional assurance.

  • Quality Metrics: We could track some metrics from QA:

  • How many issues were found during QA phase (if many, improve initial dev process).

  • Whether site meets certain score thresholds (like always aim for Lighthouse perf 90+, etc.).

  • Use these to continuously improve (e.g., if we always scramble last-minute for alt texts, incorporate content collection for those earlier).

  • Sign-off: We don't launch until QA is done and the project lead (or whomever is responsible) signs off that the site meets our standards. This is a soft internal sign-off (we don't literally have a sign-off form, but mentally or via a final checklist tick).

  • Also ensure the client signed off on content/design during review to avoid post-launch "I didn't approve this" scenarios.

  • Documentation: Keep a record of any non-obvious decisions or shortcuts for that project (like "Used a temporary polyfill for X, should monitor Y"). So if something arises, we know the context. This can be in project notes.

By having a strong QA and testing discipline, we significantly reduce the chance of delivering a broken or sub-par website. It also means fewer support headaches later. Clients may not explicitly see all the QA work, but they will notice its results: a smooth launch and a site that "just works" on all their devices. That contributes to their satisfaction and our professional image.

9 Risk Management

Even with careful planning, projects can face various risks that threaten timelines, quality, or client satisfaction. Fincher Labs takes a proactive approach to identify and mitigate risks. Below are common risks in our projects and how we manage them:

 - Scope Creep: Risk: The client requests additional features or pages beyond what was agreed (often
gradually, mid-project). This can throw off budget and timeline.
Mitigation: During quoting and kickoff, define the scope clearly (number of pages, specific
functionalities). If new requests arise, politely refer to the original agreement and inform the client
that it can be done as an extra (with cost/time implications) 7 . For minor additions that are quick,
we sometimes accommodate as goodwill, but we explicitly label it as an exception. Use change
orders for any significant scope increases: document the request and get client approval on new
quote or deferred to a Phase 2 after launch. Internally, train the team to recognize scope creep and
escalate to project manager to handle, rather than agreeing to everything on the fly.

- Content Delays: Risk: The client is late in providing text, images, or other content, which stalls
development and endangers our 3-5 day turnaround promise.
Mitigation: Emphasize at contract signing and kickoff that timely content delivery is crucial to meet
the timeline. Provide the client with a clear list of needed items and deadlines. If content is delayed,
start with placeholder content to continue progress (with client's okay), and set an internal drop-
dead date after which we use filler or our own copy to complete the site. Communicate
transparently: "We can't finalize the About page without your bio. If we don't have it by tomorrow, we'll
put a short placeholder and you can edit it later." This often motivates them or at least ensures the site
launches on time, with an update later. Build a small buffer in our timeline for content; if timeline is
tight (e.g., rush jobs), actively help the client with content (e.g., short interview to extract content, or
propose copy yourself for approval). Document any content provided late in writing to avoid blame if
timeline slips.

- Unrealistic Timeframes: Risk: Over-promising a delivery faster than we can do (especially if multiple
projects overlap or a particularly complex task is involved).
Mitigation: Maintain a scheduling system for projects. Never commit to a deadline without checking
resource availability. For rush projects, ensure no other critical tasks conflict or assign extra help. If
multiple clients request simultaneous quick turnarounds, be honest and stagger start dates or bring
in contractors as needed. Internally, set internal deadlines a bit ahead of client deadlines to account
for review and buffer. If a delay becomes unavoidable (e.g., developer fell sick), inform the client as
early as possible and possibly offer a small concession (like a discount on a future update or
something) to maintain goodwill. But strive to avoid this through prudent planning.

- Client Communication Gaps: Risk: Misunderstandings or lack of communication can lead to
misaligned expectations (e.g., client expected a feature we didn't include, or they are unaware of a
decision we made).

Mitigation: Keep communication frequent and documented. After meetings or important calls, email a summary of decisions and next steps. Encourage clients to ask questions. Provide updates at least once every 1-2 days during the project (so they feel progress and can course-correct any misinterpretation early). Use "client-friendly language" as per our principles to ensure they truly understand (avoiding technical jargon confusion). Also, actively listen to the client – sometimes risk signs show up as throwaway comments (like "we'll add more products later") which might imply a future e-commerce need; address or note that. To manage expectation: we sometimes share an early wireframe or design concept to confirm we're on the right track visually, reducing risk of "I don't like this design" at the end.

  • Technical Issues: Risk: Unexpected technical problems like deployment failures, domain propagation issues, or browser-specific bugs might delay launch or break functionality. Mitigation: Have a standard deployment checklist (we do). Always test in staging environment identical to production. Use reliable hosting (Cloudflare, etc., with historically minimal downtime). If a deployment fails, have a fallback: e.g., if our CI pipeline fails, be ready to deploy manually or use an alternative host temporarily. Keep credentials and access for systems handy to troubleshoot quickly (like Cloudflare account login in a password manager, so no time lost scrambling). For domain issues, we often set them up on Cloudflare early to avoid last-minute DNS changes. If a third-party API (like email service) has outage, have a backup method (maybe use a backup email address or queue messages). Keep an eye on error logs during launch to catch any environment-specific issues. In short, double-check technical integrations ahead of launch and have contingency plans (even as simple as, if contact form email fails, have form also save to a file or use a backup email).

  • Post-Launch Issues (Warranty claims): Risk: After launch, something is not working correctly or client discovers an error that slipped through. This can affect client satisfaction and confidence. Mitigation: Our QA process should minimize this, but if it happens, respond immediately. Fix bugs during the support window as top priority (this is expected anyway). If a serious issue emerges (like site goes down), have monitoring to catch it potentially before client even notices. Maintain professionalism – avoid defensiveness, apologize for any oversight and rectify. Use such incidents to improve our checklist for future. Also ensure our contract limits extreme liabilities: we usually limit our liability to the project cost, and disclaim consequential damages, so legally we're protected (though in practice issues are rarely that severe). If the issue was due to client content or third-party (like their provided plugin broke), we explain and still assist in finding a solution or workaround.

  • Payment Issues: Risk: Client delays or fails to pay the remaining balance (or any invoice), or disputes charges. Mitigation: Collect a significant deposit (50%) up front – that covers at least baseline costs and indicates commitment. Don't transfer full control of assets (like domain ownership transfer or handing over source code) until final payment is received, if possible (though the site is live, we have leverage in domain/hosting access). For small amounts, usually clients pay; for any hint of trouble, maintain friendly but firm reminder process. If a client has a history of slow payment, consider adjusting terms (maybe 75% upfront for next project or pay-as-you-go). Use Zoho to send automatic reminders. In worst case of non-payment, our contract stipulates we can take down the site after reasonable notice (this is a nuclear option; we try to avoid getting there). Clear communication: ensure client is aware of payment schedule from the start. Also, structure the final payment due at launch encourages them to pay to get launched – leverage excitement. If a client disputes something ("I'm not paying because X isn't what I wanted"), that often ties to a communication issue; work to

    resolve the concern while politely referring to agreed scope, possibly negotiate a middle ground (a
    small extra tweak done to satisfy them, then they pay). Maintain professionalism in financial dealings
    to avoid souring relationship.
    • Key-Person Dependency: Risk: Because we are a small team, if one critical person (e.g., the lead developer) is unavailable (due to illness, personal emergency) during a project, it could stall work or cause quality issues if someone else has to jump in cold. Mitigation: Cross-train team members on our standard stack so someone else can step in if needed. Keep project documentation (like current status, tasks list, credentials) accessible to the team, not siloed with one person. Use version control and cloud storage for assets, so others have access. In crunch, have a couple of trusted freelancers on call that we can bring in short-term. Schedule realistically to avoid single person working multiple rush projects at same time. If foresee any downtime (vacations, etc.), inform clients early and adjust timeline or assign backup coverage.

    • Third-Party Service Changes: Risk: The tools we rely on (Zoho, Cloudflare, etc.) change pricing or features, affecting our workflow or costs. E.g., Zoho might alter free tier limits, Cloudflare might impose new restrictions. Or an API we used might deprecate. Mitigation: Keep an eye on announcements from key services. Maintain a small buffer in pricing to absorb minor cost changes (e.g., Zoho free might become paid, ensure client aware that's separate cost, or we adjust our process to maybe use another free option if needed). Design sites to be not too tightly coupled to a single third-party if possible (for example, we can swap Turnstile with hCaptcha or similar if needed, with minimal change). If a major change happens impacting existing clients (say Zoho stops free email), proactively inform those clients and help them transition (this builds trust, even if not our fault). In new contracts, include that third-party fees are responsibility of client and subject to change outside our control.

    • Legal/Compliance Risks: Risk: Issues like not having the right to use an image or font, or not meeting accessibility requirements could pose legal problems. Mitigation: Use properly licensed resources: we either use client-provided media or free-to-use stock (CC0 or our stock accounts). Avoid using any unlicensed content. For any content client provides, we assume they have rights, but if something seems off (like they gave a famous celebrity photo), query it. On accessibility, we aim to meet at least basic guidelines; while small businesses may not be strictly held to ADA like larger ones, it's still a risk we try to mitigate by following best practices and offering to add accessibility improvements if needed. We carry basic liability insurance for business operations as a fallback. Contractually, we include a clause that client content is their responsibility and they indemnify us against IP infringement in materials they provided. And we ourselves indemnify against any infringement in what we deliver (so we ensure we don't include stolen code or such).

    • Also ensure a privacy policy on sites if required by law (especially if any analytics or cookies present). We can provide a template but often advise client consult if they have large user base – most local small biz just need a simple notice.

By anticipating these risks and handling them with clear strategies, we prevent many potential problems from ever arising, and quickly resolve those that do. This risk-conscious culture helps maintain project smoothness and protects both Fincher Labs and our clients from avoidable harm.

10 Continuous Improvement

Fincher Labs is committed to continuously improving our services, processes, and offerings. We treat each project as an opportunity to learn and refine our operations to better serve clients and enhance efficiency. This section outlines how we measure success (Key Performance Metrics), how we incorporate feedback and iterative improvements, and how we approach expanding our service offerings strategically.

10.1 Key Performance Metrics

To gauge our performance and identify areas for improvement, we track several Key Performance Indicators (KPIs) for our business and projects. North Star targets:

  • Average Delivery Time: ≤ 3.5 days
  • Client Acquisition Cost: < $50
  • Client Lifetime Value: > $1,200
  • Automation Rate: > 50% of tasks
  • Template Reuse Rate: > 70%

Additional KPIs:

 - On-Time Delivery Rate: The percentage of projects delivered within the promised timeline (e.g.,
within 3-5 days for standard projects, or within 24 hours for rush projects). Our goal is a near 100%
on-time rate. If a project goes past due (excluding client-caused delays), we record it and examine
why 1 . A trend of late deliveries would indicate we need to adjust scheduling or resource
allocation.

- Client Satisfaction & Feedback: While qualitative, we aim to quantify this via:

- Post-project feedback surveys or informal check-ins. We could use a simple 1-5 rating or Net
Promoter Score question: "How likely are you to recommend Fincher Labs?"
- We track testimonials, referrals, and repeat business as proxies for satisfaction (each referral or
repeat project suggests a happy client).

- Any negative feedback or client complaints are logged and addressed, and we count how many per
quarter (goal: zero major complaints).

- Number of Referrals: Count referrals and referral conversions (how many referred leads turn into
clients). This is tied to our referral program success. An increasing trend means our client base is
advocating for us, a strong indicator of delivered value.

- Sales Conversion Rate: How many leads or quotes result in signed projects. If we send 10 quotes
and 7 become clients, that's a 70% conversion. A high conversion suggests our sales process and
pricing are on point; a low rate might mean we need to adjust our pitch or pricing.

- Average Project Turnaround Time: Measure the average number of days from project start (after
deposit) to launch. We expect ~3–5 days, ~4 days on average, for standard projects. Track this to ensure it's
consistent and identify if creeping up (if average grows to 6-7, something needs addressing like
scope bloat or process inefficiency).

- Revision Rounds per Project: How many revision cycles do clients typically go through. If most
projects are done in 1 round of feedback, great. If we often have 3-4 rounds, maybe we need to
improve initial requirement gathering or design alignment. Our process aims for 1 major round,
maybe a minor second.

- Support Utilization: During the support window, note how many support requests or fixes were
needed. If many issues are found after launch, that suggests QA needs boosting. If support is quiet,
QA was solid. Also track how many pay-as-you-go updates clients request beyond support; an
upward trend might indicate opportunity to propose a maintenance plan or that clients are actively
engaging (which is good).

- Profitability Metrics: On the business side, monitor:

- Average revenue per project (should align with base $350 plus any add-ons).
- Average cost per project (mostly our labor hours). Ensuring that our effective hourly rate remains
healthy given the flat fee. If we consistently overspend time, might need to adjust pricing or scope.
- Add-on uptake rate: e.g., what percentage of projects include the Professional Email setup or Rush.
This helps forecast those services and evaluate if our pricing is right. If no one is buying an add-on,
maybe price is too high or it's not being pitched well.

- Lifetime value of a client: do they come back for updates or second projects? If one-off only, we
might strategize ways to increase retention.

- Quality Metrics:

- Bugs found after launch per project. (Goal: as close to 0 as possible.)
- Performance scores median. (Goal: e.g., median Lighthouse performance 90+).

- Uptime percentage for hosted sites. (Goal: 99.9% or higher, which Cloudflare gives easily).

- Growth Metrics:

- Number of projects per month/quarter.
- Revenue growth rate year-over-year.
- These aren't directly quality, but they indicate business health and can signal when to expand team
or offerings.

We will periodically review these metrics (at least quarterly). Metrics give us objective data to discuss in improvement meetings.

10.2 Process Improvement & Feedback

Continuous improvement is an ongoing cycle:

  1. Collect Feedback:
  • Internally, within 48 hours of launch, run a micro-retrospective: what worked, what didn’t, candidate assets to productize, and any manual steps to automate.

  • Externally, gather client feedback with a simple check-in: “Anything we can improve?” Capture testimonials and objections to refine messaging.

  • If a prospect didn’t convert, record reason (price, timing, features) for trend analysis.

    1. Analyze & Identify Improvements:

    2. Look for patterns. E.g., if two projects had delays due to waiting on content, maybe we need a better method for content assistance or a content template to speed them up.

    3. If we see a pattern of a certain small feature being asked (like "can I edit my site text later?"), maybe consider offering a lightweight CMS or training the client on Git, etc., as a new value-add or product variant.

    4. If internal stress points exist (like rush jobs being chaotic), refine the rush readiness checklist, limit concurrent rush slots, or pre-allocate on-call resources.

    5. Implement Changes (3x Trigger): If we do something manually three times, we automate it (n8n/Zoho). File and track an automation task.

    6. Update documentation (like this manual) with improved procedures. For example, if we create a new "client content worksheet", add that to the appendix or toolkit given to sales to use.

    7. Provide training to team if needed for new tools or methods (say we adopt a new deployment tool to reduce issues, ensure everyone knows how to use it).

    8. Refine templates (quote, email, code, prompts) based on learned best practices. E.g., add a clause to contract if we encountered an unclear area.

    9. Improvement can also mean investing in tooling: maybe adopting a project management software if tracking tasks via email gets cumbersome as we scale.

    10. Monitor Results:

    11. After implementing a change, monitor if the related metric improves. For instance, if content delays were reduced after giving clients a template, that's a success to keep using.

    12. Solicit feedback on the changes too (e.g., ask a client "was that new prep checklist helpful?").

Team Involvement: - We foster a culture where team members can suggest improvements at any time. Perhaps maintain an internal log of ideas or issues encountered and have monthly improvement sessions. - Encourage innovation: maybe a team member wants to try a new CSS framework to speed design, we can pilot it on an internal project or small project to see if it benefits. - Recognize contributions that improve process (just verbally or small reward), to motivate continuous enhancement mindset.

Quality Improvement: - If metrics like bug counts or revision rounds show issues, do root cause analysis. For example, if lots of bugs, perhaps introduce a peer review step or more automated testing for critical forms. - If multiple clients ask for something we currently don't do (like SEO services, or content writing), perhaps consider adding that offering or partnering with someone. More in expanding offerings section.

Client Relationship Improvement: - Perhaps implement a more formal client follow-up schedule (like a 6month check-in) to show we care and also possibly generate maintenance work or referrals. This process can be standardized and assigned. - Use a CRM to record all client interactions, so we remember context (like they mentioned maybe wanting ecommerce next year, then we can proactively reach out when time).

Continuous improvement isn't just reactive; it's also proactive scanning of industry trends: - Keep an eye on what similar agencies are offering or doing. If "ADA compliance review" becomes a standard offering, we might incorporate that checklist to stay competitive. - Update technical practices as new best practices emerge (for example, if Google changes SEO algorithm emphasis, adapt our SEO approach accordingly).

By consistently applying feedback and improving our process, we become more efficient (which improves profitability) and deliver better client experiences (which improves satisfaction and referrals). The key is to

close the loop: no feedback or metric insight should be ignored; everything should either result in a change or a conscious decision that current method is fine.

10.3 Expanding Service Offerings

As Fincher Labs grows and the market evolves, we may consider expanding our portfolio beyond the current core services. This could include new product offerings or enhanced packages. However, any expansion should be strategic and manageable. Here is our approach to adding new services:

  1. Market Research & Client Needs: - We pay attention to client inquiries and common requests. For example, if multiple clients ask "Do you do SEO?" or "Can you manage my social media?" – that indicates a demand. - Research what competing small agencies or freelancers offer locally and at what price points. Identify gaps or opportunities: maybe few offer a low-cost e-commerce package, or content writing, etc. - Ensure any new service aligns with our expertise or is something we can develop competency in without overstretching. We prioritize areas adjacent to web development (like SEO, content, graphic design for web, etc.) rather than something entirely different (like IT support, which is outside our scope).

  2. Pilot and Develop Process: - Before formally launching a new offering, test it with a trial or pilot: * For instance, if considering an SEO Optimization Package, perhaps pilot it on one of our own sites or offer it to a past client at a discount to gauge results and refine deliverables (e.g., keyword research, on-page SEO improvements, local directory listings). * If considering an E-commerce Website Package, maybe do one as a custom project first to understand the effort (using Shopify or integrating with a payment gateway) and then systematize it if feasible within a low-cost model. * For an ongoing maintenance plan, we might run a 3-month pilot with a willing client: set terms (like $X/month for Y updates and Z support hours), see how it goes (did we under/over-estimate usage?). - Document the process for delivering the new service, similar to how our core services are documented. Create any templates needed (like a checklist for SEO tasks, or a content brief template if offering copywriting). - Ensure we have or acquire the skill set. This might involve training existing team or hiring/contracting someone. For example, for SEO we might need tools (like keyword research tools) and knowledge of current SEO techniques 1 . Invest in a short course or have someone certified if needed. If none of us are social media experts and we want to offer that, we might partner with a specialist rather than fumble.

  3. Define Scope & Pricing Clearly: - Like our core offerings, outline exactly what's included in any new service, and what is not, to avoid confusion. - Determine pricing strategy: e.g., for a Local SEO package maybe a flat $200 for initial optimization + training, or for maintenance maybe tiered plans. - Consider the impact on our value prop: we remain a budget-friendly firm, so new services should also be affordable or clearly value-justified. Or we could introduce higher tiers gradually if demand exists (maybe a "Premium Web Package" that includes custom logo design, content writing, etc., at a higher price). - Add these new services to our quote templates and marketing materials once finalized.

  4. Soft Launch & Marketing: - Initially, perhaps offer the new service to existing clients (they are easiest to upsell because they trust us). For example, email past clients: "We're excited to now offer Monthly Maintenance Plans" or "Need help getting found on Google? We now provide an SEO Tune-Up service for your website." - Collect early testimonials for the new service to use in broader marketing. - Then update our website and brochures to list the new offerings publicly. Make sure sales team is briefed to pitch them. - Possibly run a promotion for the new service launch (e.g., first 5 clients get a discount) to spur adoption.

  5. Scale Team/Tools as Needed: - New services might require new tools or resources: * If we do social media management, we might use a scheduling tool (Hootsuite, etc.). * For more complex web apps, maybe invest in a new software or hosting capability. * If volume increases, consider hiring or contracting. E.g., if content writing becomes a service, maybe have a freelance copywriter we trust on call. - Ensure our quality on new services matches our web dev quality. Create QA processes for them too (like proofing every content piece, or verifying SEO changes via scans).

  6. Monitor and Adjust: - Treat the first few instances of any new offering as learning experiences. After delivering, review profitability (did we underprice?), client satisfaction (did it meet their needs?), and internal strain (did this overburden the team?). - Adjust scope or price accordingly. It's okay to iterate on the service description after initial trials. - If a new service isn't gaining traction or is proving more trouble than worth, consider refining or discontinuing it to focus on what works. Our agility as a small firm allows us to test and pivot quickly.

Examples of Potential Future Offerings: - Advanced Web Packages: like adding a CMS (Contentful, WordPress headless) for clients who want to edit content themselves, or an e-commerce lite solution (perhaps using a simple cart like Ecwid or Snipcart integrated in a static site). - Digital Marketing Services: Basic SEO as mentioned, Google My Business setup, basic analytics reporting, or even managing small Google Ads campaigns if we have skill or partner. - Branding and Design: Logo design, social media kit (some small businesses might want a unified look). - Hosting & Domains as Managed Service: We already partly do, but could formalize it (annual package where we keep everything running for them, essentially what we do but maybe with a small fee to cover time). - Training Workshops: Maybe offering a short training to a client's staff on updating their website (if using a CMS or our recommended update process) or best practices for using their new email, etc. Could be value-add for relationship building. - Larger Scale Projects: If we decide to go upmarket, maybe a custom web app or integration service. But those would require careful planning to not detract from our core focus or overwhelm our simple process. Possibly keep separate division or special handling.

Documentation Update: - Any new offering should be added to this operations manual in the appropriate sections: its description, scope (internal vs public), pricing, process to deliver, and any policies unique to it. - Update appendices with templates for them as needed. - Train all staff on the updated content so everyone is on the same page.

Expanding offerings should ultimately serve our business goals: increase revenue, meet client demand, and leverage our strengths. We will avoid "shiny object syndrome" (chasing every possible service) and instead grow in a controlled manner that complements our core web development niche. Each expansion will be reviewed for success and adjusted as part of our continuous improvement loop.

Conclusion: by following the guidelines in this manual – from sales and scoping, through development,

launch, and support, and by continually refining our approach – Fincher Labs can deliver consistently highquality websites and services efficiently, while adapting to our clients' evolving needs. This document should be treated as a living reference: team members are encouraged to refer to it often and suggest updates as we learn and grow. In doing so, we ensure that Fincher Labs remains a reliable, professional, and innovative web development agency for both our clients and our team.

We are an intelligent assembly shop: every delivery reduces the cost of the next — for us and for our clients. By building reusable assets, iterating relentlessly, applying AI with judgment, and keeping our terms simple and fair, we deliver enterprise-grade results at small-business speed and price.

Appendix A: Glossary

CMS (Content Management System): Software that allows non-developers to edit website content through a user interface. Example: WordPress, Contentful. (Our base sites typically don't include a CMS, but term may come up with clients.)

Cloudflare: A web infrastructure and security company providing CDN, DNS, DDoS protection, and other services. We use Cloudflare to manage domains and speed up/protect sites.

Cloudflare Turnstile: Cloudflare's CAPTCHA alternative that invisibly differentiates bots from humans on forms, improving user experience 5 .

DNS (Domain Name System): The system that translates human-readable domain names (like example.com) to IP addresses of servers. DNS records (A, CNAME, MX, etc.) configure where different services (website, email) for the domain reside.

Domain Registrar: A service/company where domain names are registered (e.g., GoDaddy, Namecheap). It manages the reservation of domain names.

PII (Personally Identifiable Information): Data that can identify a person (name, email, phone, address, etc.). We avoid storing this on our systems for privacy and security.

Responsive Design: An approach to web design ensuring a site looks and works well on all devices (mobile, tablet, desktop) by adapting layout to screen size.

SEO (Search Engine Optimization): The practice of optimizing a website to improve its visibility in search engine results. Involves on-page factors (keywords, meta tags) and off-page (links, etc.).

SSL Certificate: A digital certificate that enables HTTPS by encrypting data between the user's browser and the website. Provides the padlock icon and "https://" in the URL. We use SSL on all sites for security.

Support Window: The post-launch period during which we fix bugs and make minor changes for free (60 days standard for Fincher Labs, with possible extension to 90 days in some cases).

Next.js: A React-based web development framework for building fast web applications. We use it as our primary framework due to its performance and flexibility for both static and dynamic needs.

Static Site Generation (SSG): A method where pages are pre-built into static HTML at build time (as opposed to on each request). Next.js supports SSG. Resulting static sites are fast and secure.

Serverless Functions: Cloud-hosted functions that run backend code on demand without managing a full server. Used for tasks like form processing in our projects (e.g., Next.js API routes or Cloudflare Workers).

Zoho: A suite of online productivity tools. We reference Zoho mostly for Zoho Mail (email hosting) and Zoho Sign/CRM (which we use in our quote automation).

Google Workspace / Microsoft 365: Subscription services by Google/Microsoft providing professional email (@yourdomain) and productivity tools. We set these up for clients who need robust email and collaboration tools.

MX Record: DNS record type that directs email for a domain to the correct mail server. Setting MX records is part of configuring professional email.

Turnaround Time: The elapsed time to complete a project. Our default is 3–5 business days from content readiness to website completion (or 24 hours with Rush).

Wireframe: A simple schematic or outline of a web page's layout (no final design details). We sometimes use quick wireframes to clarify layout with clients before full design.

WAF (Web Application Firewall): Security layer that filters out malicious traffic to a web application. Cloudflare's WAF helps protect our sites from common threats (SQL injection, cross-site scripting, etc.).

Deposit: Upfront payment required to begin a project (we use 50%). Acts as commitment from client and covers initial work.

Net Terms: The period in which an invoice is expected to be paid. "Net 0" or "Due on receipt" means immediate payment. We often effectively do net 0 at launch for final payment.

404 Page: The page shown when a requested URL is not found on the server. We create a custom 404 page for user-friendliness and to guide visitors back to the site.

Alt Text (Alternative Text): A textual description for an image in HTML (the alt attribute). Important for accessibility (screen readers) and is read by search engines for context.

WCAG: Web Content Accessibility Guidelines – standards for making web content accessible to people with disabilities. We aim for basic WCAG compliance in our projects.

Net Promoter Score (NPS): A metric for customer satisfaction gauging how likely they are to recommend our service (usually by asking to rate 0-10). We informally gauge satisfaction similarly.

Root Cause Analysis: A problem-solving method to identify the underlying causes of an issue, not just the immediate symptom. We apply this if recurring issues appear, to fix process at the source.

Change Order: A document or agreement to modify the original project scope, often with new costs or timeline. Used to manage scope creep formally when needed.

Indemnify: In contracts, to secure against legal responsibility for their actions or the actions of another. Our contract indemnifies us from client-provided content issues, and vice versa within reason.

Appendix B: Standard Templates

Below are some internal templates and examples that Fincher Labs uses for consistency in documentation and communication. Team members should adapt these templates as needed per project, but they serve as a starting point to ensure we cover all bases.

B.1 Standard Quote & Agreement Template (Example)

(This is a simplified representation of our quote document structure, including key terms. In practice, this would be generated via Zoho with proper formatting.)

Quote #: FL-2025-0XX Date: August 9, 2025 Valid Until: September 8, 2025 (30 days from issue)

Client: Awesome Bakery LLC 123 Cherry Pie Lane, Hometown, CA 91000 Contact: Jane Doe, (555) 123-4567, jane@awesomebakery.com

Project: "Awesome Bakery Website Design" Create a new company website for Awesome Bakery, including design, development, and launch.

Scope of Work & Deliverables:

  • Core Website Package – Design and develop a custom, mobile-responsive website (up to 5 pages: Home, About, Menu, Gallery, Contact). Includes integrating client's logo and branding, a contact form (with spam protection), and basic SEO optimization (meta tags, Google submission). Launch on client's domain with SSL security. Includes 60 days post-launch support.

  • Professional Email Setup (Zoho Mail) – Configure one custom email address (e.g., info@awesomebakery.com) using Zoho Mail. Setup DNS (MX, SPF, DKIM) and provide login credentials and usage instructions. (No rush delivery add-on selected; standard turnaround applies.)

Timeline: Project will commence within 1 business day of quote acceptance and deposit. Initial website draft delivered by ~August 15, 2025. Client feedback/revision cycle expected to complete by ~August 18. Launch targeted by August 19–20, 2025, assuming timely client feedback and content provision. (Standard 3-5 business day turnaround.)

Pricing:

| Item | Price | | ----------------------------------- | ------------- | | Core Website Package (5-page site) | $350 | | Professional Email Setup (Zoho) | $50 | | Subtotal | $400 | | Sales Tax (N/A for services) | $0 | | Total | $400 |

Note: Domain registration fee not included (client will register domain separately or reimburse if Fincher Labs assists). No ongoing hosting fees.

Payment Terms: 50% deposit due upon acceptance (to schedule project start). Remaining 50% due upon website launch

(before site handoff). Acceptable payment methods: ACH bank transfer or credit card via online invoice (processing fees included in price). Final invoice will be issued at launch, with Net 7 terms (payment due within 7 days of launch).

Deposit Amount (50%): $200 due at signing. Final Payment (50%): $200 due at launch (est. August 20, 2025).

Additional Terms & Conditions:

  • Support: Fincher Labs provides up to 60 days of post-launch support at no additional charge. This covers bug fixes and minor updates. Significant changes or requests after launch may require a new quote or fall under maintenance fees ($50/$100 updates).

  • Client Responsibilities: Client agrees to supply all required content (text, images, logo, etc.) in a timely manner. Delays in content provision may extend the timeline. Client warrants that they have rights to all content provided.

  • Acceptance & Revisions: Fincher Labs will incorporate one round of revision feedback from the client after the initial draft. Additional revision rounds or changes in scope may incur extra charges via a change order.

  • Domain & Hosting: If Fincher Labs assists with domain configuration, the domain will be registered in the client's name. The website will be hosted on Fincher Labs' cloud infrastructure at no recurring cost to client. Domain renewal fees are the client's responsibility; Fincher Labs will offer renewal reminders as a courtesy.

  • Warranty: Fincher Labs warrants that the website will function as described on modern web browsers and devices. Any bugs reported within the support window will be fixed promptly at no cost. Fincher Labs is not liable for issues caused by third-party services or later content edits by the client.

  • Limitation of Liability: To the maximum extent permitted by law, Fincher Labs' liability for any claims arising under this agreement is limited to the amount paid by client. In no event will Fincher Labs be liable for indirect or consequential damages.

  • Referral Program: Client is eligible for our referral bonus (currently $50 credit) for any new customer referred. See attached Referral Program details.

  • Governing Law: [State] law governs this agreement. Any disputes will be resolved through good-faith negotiation; if unresolved, then binding arbitration in [County/State].

Acceptance: By signing below, the client agrees to the scope of work, pricing, and terms outlined above. This quote, once signed by client and accepted by Fincher Labs, becomes a binding agreement. Fincher Labs will commence work upon receipt of the signed agreement and deposit.

Client Name: Jane Doe__ Title: Owner, Awesome Bakery__ Signature: ___ Date: _____

Fincher Labs (Authorized Representative): Name: John Smith___ Title: Project Lead_ Signature: ___ Date: _____

(Fincher Labs will countersign and return a copy for client records.)

Thank you for choosing Fincher Labs! We look forward to creating your new website.

End of Quote/Agreement.

B.2 Sample Launch & Handoff Email to Client

Subject: Congratulations – Your Awesome Bakery Website is Live!

Hello Jane,

Congratulations! Your new website for Awesome Bakery is now live and accessible to the public at www.awesomebakery.com.

It's been a pleasure working on this project with you. Thank you for trusting Fincher Labs to build your online presence. Here's a summary of what's been done and some important next steps/information:

Website Launch Details:

  • URL: https://www.awesomebakery.com

  • The site has been tested on multiple devices and browsers. I encourage you to visit the site on your phone and computer. If you notice anything amiss, please let me know – I'm here to tweak it.

  • I've attached a screenshot of your homepage as a keepsake for this milestone. It looks great!

    Credentials & Access:

  • Domain: Your domain is registered with GoDaddy as discussed; we have pointed it to our servers. Your GoDaddy login is the same, and I recommend ensuring auto-renew is turned on for your domain (it expires in June next year).

  • Professional Email: Your new business email info@awesomebakery.com is all set up via Zoho Mail. You can log in at mail.zoho.com with:

  • Username: info@awesomebakery.com

  • Temporary Password: Bakery2025 (please change this upon first login). I've tested that it sends/receives properly. I also configured it on your website's contact form (form submissions will forward to this email). I'll send a separate email with some tips on using Zoho Mail, or we can do a quick call.

  • Social Media Links: I added your Instagram and Facebook links to the site's footer. Clicking them will take visitors to your pages.

    Handoff Materials:

  • Attached is a one-page Website Guide PDF for your reference. It covers how to:

  • Update your gallery images (I recall you might add new cake photos monthly – the guide explains the process we discussed using the simple CMS portal).

  • Access website analytics (I set up Google Analytics; the guide shows how you can log in to see visitor stats if you wish).

  • Our support and contact info in case you need help.

  • Also attached: credentials summary (domain, email admin, etc.) — please store this securely.

🛡 Support Period: As part of our service, you have 60 days of complimentary support (until October 20, 2025). This means if you need any minor updates or notice any issues with the site, I will address them free of charge, ASAP. Don't hesitate to reach out if something comes up or even if you just have a how-to question. Consider me on call to ensure everything runs smoothly.

Next Steps / Recommendations:

  • I strongly recommend announcing your new website to your customers! Perhaps a post on your social media or an email to your regulars. It can help drive initial traffic.

  • Keep an eye on the contact form – test it by sending a message to yourself to see how it comes through. (I tested it already, but one more time doesn't hurt.)

  • If you plan to update your Menu page with seasonal specials, we can show you how to do that, or we're happy to handle updates via our $50 pay-as-you-go service after the support window.

  • Consider setting up a Google Business Profile (if you haven't) and linking the website there; it boosts local SEO.

    Final Invoice: I will send the final invoice for the remaining project balance of $200 in a separate email shortly (since we took a $200 deposit). As per our agreement, it's due within 7 days. You can pay online via the link I'll provide. Thank you in advance!

Thank You & Referral Bonus: Thank you so much, Jane, for being an amazing client. Your enthusiasm and prompt feedback made this project a breeze. If you're happy with our work, we'd greatly appreciate if you share your experience — a quick testimonial or review would mean a lot to us. And remember, we have a referral program: if you know another business owner who needs a website, send them my way. You'll earn a $50 referral reward as a token of thanks (and currently $100 if it's within this promotional period!).

Once again, congratulations on the new site! We're excited to see it help your bakery reach even more people (and I'm personally craving one of those chocolate croissants after looking at all those photos ).

If you have any questions now or in the future, you know how to reach me. I'll check in with you in a week to see how things are going, but you're absolutely welcome to contact me anytime.

Enjoy your weekend, and cheers to your growing business!

Warm regards,

John Smith Project Lead – Fincher Labs john@fincherlabs.com | (555) 987-6543

(The email above is written in a friendly, non-technical tone, recapping the key points of handoff. It provides the client with clear information and next steps, reinforcing the client-friendly approach we strive for.)

End of Document

1 The 7-Step Website Development Process [A Guide] - Digital Silk https://www.digitalsilk.com/digital-trends/website-development-process/

2 The Web Design Process from Start to Finish - u7 solutions https://www.u7solutions.com/blog/website-design/the-web-design-process-from-start-to-finish/

3 Cloudflare Turnstile vs Google reCAPTCHA: 8 Key Factors Compared https://blog.geetest.com/en/article/cloudflare-turnstile-vs-google-recaptcha-8-key-factors

4 How does Cloudflare's Turnstile work? : r/webdev - Reddit https://www.reddit.com/r/webdev/comments/16gb5i3/how_does_cloudflares_turnstile_work/

5 Goodbye reCAPTCHA, hello Turnstile - Italo Baeza Cabrera - Medium https://darkghosthunter.medium.com/goodbye-recaptcha-hello-turnstile-874b648ec4aa

6 Cloudflare Turnstile is super easy to use (instead of reCAPTCHA) https://www.reddit.com/r/golang/comments/10fg6i8/cloudflare_turnstile_is_super_easy_to_use_instead/

7 Web-Development preparation and entire project workflow https://softwareengineering.stackexchange.com/questions/83540/web-development-preparation-and-entire-project-workflow