Behind simonij.com: How I Built a Fast, SEO-Friendly Freelance Developer Website

My freelance developer website, simonij.com, is hand-coded in Next.js and Tailwind CSS, runs in English and Danish, and sets no cookies, so there's no consent banner in the way. Blog posts are files in the code repository rather than entries in a CMS. Below are the choices behind it, what I deliberately left out, and which parts are worth copying for your own site.

It's my own project, so no client vouches for the result. Read it as one developer's choices, not a recipe.

The short answer

For a bigger build from scratch, I've written about from idea to SaaS: choices and priorities. This post covers a narrower job: a website that gets a business to contact me.

Why I rebuilt it: a nice template that didn't win work

The old simonij.com ran on a purchased Tailwind UI template built with Next.js 13. It looked tidy, but it was English only, and the homepage was mostly about me as a person. Nothing explained what I build, what it costs or how working together goes. Contact meant copying an email address from the about page, and the template's newsletter form was switched off.

It's a common problem on freelancer sites: the site becomes a business card instead of a sales tool. If you're a freelancer, test yours with one question: could a buyer decide to contact you without calling first? Mine couldn't. So the rebuild had three requirements:

1. Explain services and pricing so a decision-maker in Denmark or elsewhere in Europe can judge the fit alone.
2. Be findable for the words businesses actually search for, in both languages.
3. Make contacting me easy, and give me enough context to reply with a real answer.

The design is deliberately plain: few colors, plenty of whitespace and two typefaces (Bricolage Grotesque for headings, Inter for body text), so it loads fast and reads well on a phone.

The stack, and why not WordPress or Webflow

I work with Laravel and React for clients, so the choice came down to what I can maintain for years without friction.

The site uses the Next.js App Router with React Server Components. Pages are rendered to HTML on the server, and only interactive parts, like the contact form, run in the browser. The code is strict TypeScript, and Tailwind CSS v4 keeps colors and fonts as tokens in a single CSS file.

Why not WordPress? For me it would mean plugin updates, a database to back up and an admin panel I'd never open. Webflow or Framer suit designers and marketing teams, but I'd be paying for a visual editor I don't need. Either can still be the right choice for you, and I've written an honest comparison of WordPress and a custom-coded website for anyone weighing that decision.

Blog posts are MDX files (Markdown that can include components) in the same repository as the site. A validation library called Zod checks each post's title, description, date and language at build time. If a description is missing, the build fails and nothing ships. The rest of my setup is in my list of the tools I use as a freelance developer.

Speed: mostly a list of things I left out

Slow sites are rarely slow because of the framework. They're slow because of what gets bolted on: a cookie banner, a chat widget, a tag manager and fonts from several servers. I skipped nearly all of it:

• No cookies. According to Vercel's privacy documentation, Web Analytics identifies visits with a hash of the request instead of cookies and discards it after 24 hours. No cookies means nothing to ask consent for, and no banner.
• Self-hosted fonts. Inter and Bricolage Grotesque load through next/font, which the Next.js font docs describe as self-hosting Google Fonts with your deployment. The browser never calls Google, and text doesn't jump.
• Prebuilt pages. Pages and posts are generated ahead of time and refreshed once a day, so a post with a future publish date appears on its own.
• No heavy third-party scripts. No chat and no embedded social posts. Spam protection on the form is a hidden honeypot field that bots fill in and people never see, with Cloudflare Turnstile as an optional extra on the contact page only.

I measure with Google's three Core Web Vitals: Largest Contentful Paint (LCP) within 2.5 seconds, Interaction to Next Paint (INP) at 200 milliseconds or less, and Cumulative Layout Shift (CLS) at 0.1 or below. Per Google's overview on web.dev, those thresholds apply at the 75th percentile of page loads. That's why I watch Speed Insights, which reports on real visits, rather than chasing a Lighthouse score from my own laptop.

SEO that lives in the code

SEO on a small site comes down to two things: Google understanding what each page is about, and content someone is actually searching for. Code handles the first. The second needs a blog.

Two languages without confusing Google

URLs are translated: /ydelser in Danish, /en/services in English. Every page points to its other-language version with hreflang tags, and an x-default points to the English one as the fallback for browsers set to any other language. Google's guide to localized versions requires each version to list itself and all the others, or the tags get ignored. Posts only get hreflang once both versions are live.

The site also never redirects visitors based on browser language. Google's guidance on multi-regional sites advises against it, because it can hide versions from both people and crawlers.

The technical groundwork

• A sitemap listing every page with its language alternates, generated from the content.
• Structured data for me (Person), my services (ProfessionalService and Service) and each post (BlogPosting plus breadcrumbs).
• An auto-generated 1200 x 630 social image for every post.
• Permanent 301 redirects from old URLs, such as the former /articles and /projects pages, so existing links keep working.
• An RSS feed for the blog.

None of this is advanced, but it's exactly what gets skipped on a template nobody looks at again.

Built for enquiries, not compliments

A fast site that ranks is pointless if nobody gets in touch. These choices turn visits into enquiries:

• One page per service, from websites and web apps to SaaS development and maintenance. Visitors find what they came for, and Google gets one clear page per topic.
• Visible pricing. My pricing page explains how I charge, including a paid, fixed-price discovery phase before larger builds. My assumption is that most buyers would rather rule me out on price than spend a call finding out.
• A form that asks the right questions. It asks for project type, budget range and timeline, so I can reply with something concrete instead of follow-up questions.
• No pop-ups. Every post has one call to action mid-article that matches the section above it, and one at the end.
• Direct contact. The person who replies is the person who writes the code. That's the biggest difference between me and an agency.

What happens after that first message is covered in how a project with me runs, from first call to launch.

What to copy, and when a site like mine is the wrong choice

Some parts transfer to any business site: remove scripts nobody uses, give each service its own page with a price range, and ask for budget and timeline on your contact form.

Hand-coding itself is the wrong call when:

• Several people edit content. Files in Git mean every text change needs a developer. WordPress or a headless CMS fits better, and either can sit behind a custom-coded frontend.
• You need a simple site, fast and cheap. A builder like Webflow or Squarespace is often enough. A coded site costs more up front and pays off only when speed, SEO or integrations matter to the business.
• The site needs logins, payments or bookings. That's a web app, not a website, and it should be planned as one.

My own trade-off is clear too: the day someone other than me writes for the blog, the site will need a CMS.

Next steps

For a website that loads fast, ranks and brings in enquiries, see how I build websites for businesses. If your project needs user accounts, data or payments, it's closer to a web app, and my MVP development process, week by week is a better starting point.

Frequently asked questions

Does a freelance developer website need a blog?+

Not to exist, but it helps if you want to be found. Service pages rank for a narrow set of searches, while posts answer the questions buyers ask before they hire anyone. A blog also shows how you think, which matters when a stranger decides whether to trust you. A few useful posts beat a dozen thin ones.

Is a template good enough for a freelance developer website?+

A template is a fine starting point if you rewrite it around your buyers. The problem is rarely the design but the generic copy, placeholder sections and forms that aren't wired up. Replace those with real service pages, pricing and a working contact form, check speed on a phone, and a template can do the job well.

Should my website be in English as well as my local language?+

Only if you want clients who don't read your local language. For a Danish business selling across Europe, English is usually the one extra language worth adding, rather than one version per country. Each version needs its own keywords and natural copy, because machine-translated pages often undermine trust.

What does a site like simonij.com cost to build?+

It depends mostly on the number of pages and languages, and whether you need to edit content yourself. A coded, bilingual site with a blog and a working contact form is more work than a template setup, so it typically costs more. My current rates are on the pricing page, and larger builds start with a fixed-price discovery phase.