How the work is handled

After you submit a project inquiry

The inquiry form is built to collect enough context for a useful first response without forcing a meeting before the problem is clear. Submitted details go to Morten directly.

• The form asks for contact details, project type, problem context, timing, budget range, requested services, and optional reference links.
• A server-side validation pass checks required fields and unsafe or malformed URLs before anything is sent.
• Rate limiting, a honeypot, and duplicate-submission protection reduce spam without blocking normal inquiries.
• If the email delivery integration is not configured, the form tells the visitor to email directly instead of claiming delivery.

Checklist delivery

The Website Conversion Checklist sends a branded resource to the email address entered in the form. The current version is a guided self-audit: it helps visitors score a page, prioritize fixes, and decide what should change first.

• The checklist does not automatically crawl or inspect the submitted site.
• The submitted website URL is used to personalize the resource and the admin notification.
• Visitor email delivery is the essential path; webhook or admin notifications are secondary.
• A future automated audit would need strict privacy, timeout, size, redirect, and SSRF protections before launch.

Calendar booking

The Book a Call path uses the owner-approved Cal.com booking link. The calendar opens on Cal.com, and any booking details entered there are handled by Cal.com under its own terms and privacy practices.

• This site currently uses a link-first booking path rather than creating bookings through a Cal.com API key.
• Custom analytics records only that a booking CTA was clicked, along with the page section and destination. It does not include meeting notes, names, emails, URLs, or booking form values.
• A future API or webhook integration would need a separate backend review, server-only env names, and owner approval before launch.

Data and analytics

The site uses limited analytics to understand which pages and actions are working. Custom events are designed around interaction names and non-sensitive context such as a CTA section or case-study slug. Names, emails, URLs, project summaries, notes, and form field values are not sent as analytics properties.

• Page analytics are provided by Vercel Analytics.
• A functional visitor-counter cookie is used only to avoid counting the same browser repeatedly.
• Email and form data are used to respond to inquiries and deliver requested resources.
• No advertising pixels, session replay, cross-site profiling, or hidden third-party marketing trackers are intentionally added.

Performance snapshot

Performance is treated as part of the trust surface, not a launch-day afterthought. In August 2026, an owner-captured PageSpeed/Lighthouse run for the live homepage showed green scores across performance, accessibility, best practices, SEO, and Agentic Browsing.

Project scope and communication

The public website explains the working style, but each paid project needs its own written scope before work begins. That scope should define deliverables, timeline, payment terms, revision expectations, handoff, support, cancellation terms, and any platform or third-party costs.

• The inquiry form does not create a client relationship by itself.
• Portfolio copy is informational and does not replace a proposal, statement of work, or signed agreement.
• Timelines and budget ranges on the site are planning guidance, not a fixed quote.
• Client-provided materials, approvals, credentials, and feedback can affect schedule and scope.

Third-party services

This portfolio and related project work may use third-party tools for hosting, analytics, email delivery, design, site building, content management, commerce, or other agreed project needs. Those services have their own terms and privacy practices.

• This site is built for a Vercel-compatible deployment path.
• Transactional email delivery uses server-side email configuration.
• Project-specific third-party tools should be named in the relevant scope or handoff documentation.
• No client passwords or secret values should be shared through ordinary website forms.

Accessibility and corrections

Accessibility issues, inaccurate content, broken links, or unclear policy language should be treated as bugs. Report anything that looks wrong or hard to use by emailing hello@mortenagiraffe.com.

Related pages