Fast because of what it is. Not what was added later.
Most sites are slow by construction and then have a caching plugin bolted on to hide it. We build static: the page is already finished before anyone asks for it, so there is nothing to optimise away afterwards.
No CMS tax. No monthly patching.
A static site has no database to breach, no plugin to update, and nothing that can go down because a server was busy. That is not minimalism, it removes entire categories of problem you would otherwise be paying somebody to manage.
Built on Astro, shipped static
Every page is rendered once at build time and served as a file. There is no server work per visitor, which is why these sites stay fast under a traffic spike instead of getting slower exactly when it matters. It is also why there is nothing to patch on a Tuesday because a plugin had a vulnerability.
Your repo, your hosting
In your GitHub organisation, on your Vercel account. Any developer can pick it up and nothing breaks if you stop working with us.
SEO handled during the build
Structured data, title patterns, clean URLs, image handling. Foundation work, not an upsell after launch.
Every change reviewable
Work happens on a branch, gets its own preview URL, and you approve it before it merges. You see the change on a real deployment rather than in a screenshot, and there is a way back from every one of them.
Branch, preview, approve, merge.
The same flow we use on our own site. Nothing reaches the live domain that you have not clicked through first.
- 01
Structure from the keyword data
What pages exist and how they link is decided by what people actually search, not by a sitemap drawn in a workshop.
- 02
Built on a branch
Every change isolated, with history. Never edited directly on the live site.
- 03
Reviewed on a real preview
Its own URL, real content, real devices. You approve what you can actually use.
- 04
Merged, then measured
Live, then checked: speed, structured data, indexation. The launch is a checkpoint rather than the finish.
Sites we build, and then have to rank.
Published case studies from accounts where the build and the marketing were the same engagement.
Are we starting to cook here, or am I getting ahead of myself? Honestly, I'm happy with all of this.
I really enjoy working with Igor. Super knowledgeable, fast, and he takes initiative. Easy to reach, always brings smart strategies, and he built us a full AI dashboard where every result is easy to read. We speak weekly. I'd recommend working with him to anyone.
E-commerce · Truck, van & 4x4 accessories
E-commerce · Modest fashion
E-commerce · Surf & vanlife
Three reasons a marketing-run build comes out different.
We have to make it perform
We run the traffic afterwards, so a site that looks good and converts badly is our problem too. That changes what gets argued about during the build.
Speed is a budget line
When you pay per click, a slow page costs money per visit. Agencies who never buy traffic treat load time as taste.
You own all of it
Repo, hosting, domain, accounts. Nothing we build stops working because you stopped paying us.
A static build, against the usual stack.
Not what you needed?
Shopify stores
If you sell products, this is the one. Built on a branch of your live theme so your apps never switch off.
From €500 →Landing pages
For a single campaign rather than a whole site. Message-matched, shipped in days.
From €397 →SEO
The build is the foundation. Ranking is the ongoing work that sits on top of it.
Explore →Fully custom build €1,500. One-page custom site €500. One fixed price per build, agreed before work starts, no hourly meter running.
Get a fixed quoteQuestions, answered.
The ones that come up before every custom build.
01Why static instead of WordPress?
Because most of what a CMS does per visitor is work that could have been done once at build time. Rendering every page on every request is what makes sites slow, and it is why so many end up with a caching plugin bolted on to hide it. Static removes the cause rather than covering it, and it takes the plugin patching and the database with it.
02How do we edit content without a CMS?
Depends what you need. For a site that changes occasionally, changes go through us on a branch with a preview. For a site with a real publishing cadence, we connect a headless CMS so your team writes in an editor and the site still builds static. The right answer comes out of how often you actually publish, which is worth being honest about.
03Is a one-page site really €500?
Yes, for a genuine one-pager: a single page, custom designed and built, on your own hosting. It is the right shape for a service business that needs to look credible and convert rather than a content library. If the scope grows past that we requote rather than quietly extending.
04What happens if we stop working with you?
You keep everything. The repository is in your organisation, the hosting is your account, the domain is yours. Any developer can take over from the commit history. There is no proprietary layer to unpick, which is deliberate.
05Do you do the design too?
Yes. It happens against what the page has to achieve rather than as a separate approval phase, because for anything carrying paid traffic the conversion argument should come before the decoration argument.
06Can you rebuild our existing site instead of starting over?
Often, and often it is the better answer. A rebuild from scratch throws away everything that already works, including the pages that rank. If you have organic traffic, the migration risk is the main thing to plan around and we treat the redirect map as the first deliverable rather than the last.
Read the thinking first.
Tell us what the site has to do.
The current site if there is one, and what it needs to achieve. We come back with scope, a fixed price, and what we would leave alone.
A site that is fast because of how it was built.
Tell us what you need. You get the scope and the number before anything starts.