How we built mantek.io for the price of a domain
Static Astro on Cloudflare Pages, a git-based CMS, a serverless contact form, and a perfect Lighthouse score — the whole stack.
The site you're reading costs us almost nothing to run. There's no server invoice, no hosting bill, no monthly platform fee — just the domain name, renewed once a year. Everything else runs on infrastructure that's free at our scale and fast everywhere in the world.
That isn't a corner we cut. It's a set of deliberate choices — static output, edge delivery, git as the backbone — that happen to be cheaper and faster and simpler than the alternative. Here's the whole stack, and the thinking behind it.
The whole bill is the domain
Take the site apart and look for the costs, and there's only one line item.
Hosting and CDN: nothing. The site lives on Cloudflare Pages, which serves it from data centres in hundreds of cities, with unlimited bandwidth on the free tier. The thing that usually costs the most — global delivery — costs zero here.
DNS: nothing. Managed on Cloudflare alongside the domain.
Email Sending: nothing. Contact-form mail goes through Resend's free tier.
The domain: the only invoice. Renewed yearly, and that's the entire running cost.
The infrastructure is free; the engineering is the investment. That's the trade — and for a site that has to be fast, bilingual and maintainable for years, it's the right one.
Static output, Git as the pipeline
The site is built with Astro and compiled to plain HTML and CSS. There's no application server running in the background — nothing to patch, scale, or wake up when a visitor arrives. Cloudflare serves the finished files from the edge location nearest each reader, which is why pages feel instant.
Deployment is just git. We push to the main branch; Cloudflare builds the site and publishes it worldwide in a minute or less. Every branch gets its own preview URL, so a change can be reviewed on a real address before it goes live. And because the repository is the source of truth, undoing a bad change is a git revert — not a 2 a.m. restore from backup.
A CMS with no database
This blog is editable in the browser, but there's no database behind it and no CMS server to keep alive. The editor is git-based: saving a post commits a Markdown file to the repository and rides the same automatic deploy as the code.
That has quiet benefits. Every edit is versioned like code, with full history. There's no database to back up, secure, or migrate. The editor sits behind GitHub sign-in, so there's no separate set of passwords to manage and very little for a scanner to find. Content and code live in one place, and ship the same way.
A contact form without a back end
A contact form normally means a server somewhere waiting to receive it. Ours is a single serverless function that runs at the edge, on demand: it validates the submission and hands it to Resend, which sends the email. No always-on back end, no queue, no infrastructure to maintain between messages.
The credentials never touch the codebase. The Resend API key lives in Cloudflare's encrypted environment variables, read by the function at run time — it isn't in the repository and isn't in the published site. Spam is caught with a hidden honeypot field and server-side checks rather than a third-party CAPTCHA. And the form degrades gracefully: with JavaScript switched off it submits natively and returns a thank-you page; with JavaScript on it posts in the background and shows inline status. No cookies, either way.
Chasing a perfect score
A static site is a fast start, not a finished one. Getting to a perfect Lighthouse score — 100 across Performance, Accessibility, Best Practices and SEO — took a series of small, deliberate decisions:
Self-hosted fonts, preloaded. The fonts are served from our own domain, not a third-party font CDN, and the one the headline renders in is preloaded so it's ready for the first paint. The Arabic typeface only downloads on Arabic pages.
No render-blocking JavaScript. What little script the site needs is inlined and tiny; there's no framework runtime shipping to the browser. These are HTML pages with a few grams of JavaScript, not an app pretending to be a page.
One shared stylesheet. The CSS is a single file, cached across every page, so moving around the site re-downloads nothing.
Work the browser can skip. Sections below the fold are marked so the browser doesn't spend layout effort on them until they're about to be seen.
No flash, no shift. The colour theme is resolved before the first paint, so nothing flickers from light to dark or jumps around as it loads.
None of these is dramatic on its own. Together they're the difference between "fast enough" and a perfect score.
Cached hard, but never stale
Speed and freshness usually pull against each other; the right caching rules give you both. Build assets get fingerprinted filenames, cached for a year and marked immutable — the browser never asks about them again. Images are cached for a week. But the HTML itself is always revalidated, so the moment we publish, every reader sees the new version.
The one lesson worth passing on: immutable means exactly that. It belongs only on files whose name changes when their contents do. Put it on a stable URL and you'll spend a day fighting your own cache.
Secure and findable by default
A set of security headers is applied at the edge, for free: strict HTTPS (HSTS), protection against clickjacking and MIME-sniffing, a conservative referrer policy, and a permissions policy that switches off the camera, microphone and location access the site never uses. There's one canonical hostname; everything else redirects to it.
Findability is built in the same spirit. Every page declares its canonical URL and its English/Arabic alternates, so search engines read the two languages as one site rather than duplicate content. Each post generates its own social-share card. Structured data, an auto-generated sitemap and an RSS feed ship on every build. And the analytics are cookieless — which means no consent banner slowing the page down or greeting the reader with a pop-up.
Two languages, one build
The site is fully bilingual: English at the root, Arabic — right-to-left — under /ar/. There's no duplicate site and no translation plugin. The same components render both languages from a dictionary, down to mirrored layouts and translated structured data. Adding a language is additive, not a rebuild.
If you're building something similar
Default to static. If a page can be HTML, it should be. Everything downstream — speed, cost, security — gets easier.
Make git the backbone. Deploys, content, rollbacks and history in one place beats four systems that have to be kept in sync.
Spend the savings on judgement. Free infrastructure frees the budget for the part that actually matters — the engineering.
This is the same discipline we bring to client work: systems that are fast, cheap to run, and built to last. If you'd like a site that behaves like this one, see what we do or start a conversation.