HaskTolk Website

Overview

HaskTolk.com is the production website for HaskTolk AS. The project combines a modern Astro-based frontend with a dedicated document verification service.

The website presents the company’s interpreting and translation services, while a separate verification workflow allows recipients to confirm the validity and current status of issued documents.

Problem

The company needed a professional production website that could clearly present its services while remaining fast, maintainable, responsive, and accessible.

A separate requirement was to provide QR-based document verification without exposing internal systems or granting the public website unnecessary access to unrelated resources.

Goals

Build a responsive and production-ready company website. Keep the frontend lightweight and performant. Present interpreting and translation services clearly. Provide a secure public document verification workflow. Prevent direct client access to internal verification data. Keep the validation service isolated from unrelated systems. Return only the minimum public information required for verification. My role

I designed and implemented the website architecture, frontend, deployment configuration, DNS setup, and document verification workflow.

My work included the Astro frontend, service architecture, access-control design, infrastructure configuration, custom-domain setup, and QR-based document verification.

Approach

The main website was built with Astro and TypeScript to maintain a small client-side footprint while supporting reusable components and structured content.

Document validation was implemented as a separate backend service.

The verification flow is:

QR code → verification domain → validation endpoint → verification service → verification data

The browser does not communicate directly with the underlying verification storage.

The validation service checks the verification identifier before performing a lookup and returns only the information required for public verification.

Key implementation details

The verification service operates with a dedicated, restricted runtime identity and read-only access to verification data.

Public clients cannot directly read or modify the underlying verification records.

Verification records contain only the public information required for validation, such as document number, document type, issue date, and current verification status.

The validation endpoint accepts only a strictly validated verification identifier and returns an explicit allowlist of public fields rather than exposing complete internal records.

The production website is available at:

https://www.hasktolk.com

Challenges

One challenge was separating public document verification from the company’s broader infrastructure while keeping the verification process simple for recipients.

Another challenge was maintaining a clear separation between deployment permissions, runtime permissions, and public access.

Custom-domain configuration also required coordinating website hosting, DNS configuration, verification routing, and TLS certificate provisioning.

What I learned

This project strengthened my understanding of production web architecture, least-privilege access control, public API design, DNS configuration, custom-domain routing, and deployment workflows.

It also reinforced the importance of separating public-facing services from internal resources and exposing only the minimum information required for each request.