Why I Built My Site in Plain Static HTML Instead of Eleventy (or Any SSG) published: false tags: webdev, staticsite, beginners, seo cover_image:

Herinirina Beranto — Tue, 15 Sep 2026 14:44:00 +0000

I'm not a developer by trade. I'm an SEO content writer, and my portfolio site was the first real "build" I owned from scratch, no template, no agency, no dev friend doing it for me. So when it came time to pick a stack, I went through the exact debate a lot of people have in their first project: hand-rolled HTML, or a static site generator?

I tried both. I ended up shipping pure static HTML. Here's the reasoning, and where it started to hurt.

Where I started: one HTML/CSS file

The first version of the site was literally a single index.html with inline <style>. No build step, no node_modules, no config file to get right before I could see anything on screen. I opened the file, wrote markup, refreshed the browser. That loop was the whole point: I wanted to spend my mental energy on content and design decisions, not on debugging a bundler.

It grew from there into three pages (index.html, apropos.html, cas-clients.html) sharing the same design system: CSS variables for colors and type, the same nav, the same footer, copy-pasted at the top and bottom of each file.

Then I needed a blog, and Eleventy looked like the obvious answer

Three static pages, fine. But a blog is a different problem: every new post needs the same header, the same nav, the same footer, the same article-card markup on the index page. That's exactly what a static site generator exists to solve. I looked seriously at Eleventy — shared layouts, a posts collection that auto-builds the index, front matter instead of hand-editing HTML for every publish.

On paper it was the right tool. In practice, I stepped back.

Why I didn't go with Eleventy

A few reasons, roughly in order of how much they actually mattered:

I wasn't going to publish at a volume that justified the overhead. A handful of articles a month, not a content site pushing dozens of posts a week. The maintenance cost of a templating layer only pays for itself past a certain publishing cadence, and I wasn't there.
Every dependency is something that can break during a deploy, and I'd have to debug it without deep Node tooling experience. Static HTML fails in exactly one way: you wrote something wrong in the file. An SSG build can fail for reasons that have nothing to do with your content.
I wanted zero ambiguity about what actually ships. With plain HTML, the file in the repo is the file the browser renders. No templating logic sits between what I wrote and what's live, which matters a lot when SEO details (title tags, meta descriptions, canonical URLs) need to be exactly right on every single page.
Migrating hosts stays trivial. I moved the whole site from Netlify to Cloudflare Pages recently after hitting Netlify's free-tier build-credit limit. Because there's no build step, that migration was: point the new host at the same repo, done. No adapting a build config to a different platform's quirks.

How the blog actually works without a templating system

No system means the process is manual, and I made that explicit instead of pretending otherwise. There's a literal comment block at the top of the article list in blog/index.html:

<!--
  To add a new article:
  1. Create an HTML file in /blog/ (e.g. /blog/my-article.html)
  2. Copy-paste an <a class="article-card"> block above
  3. Update the date, title, link, description, and thumbnail
  No templating system is used here: every article is a self-contained HTML file.
-->

Each article page is a full standalone file that reuses the same CSS variables and layout structure as the others, copied from the last one I wrote and edited in place. It's not elegant. It's honest about what it is.

Where this actually costs me

I won't pretend there's no trade-off:

Updating the nav or footer means touching every single HTML file, not one _layout.html.
There's no automatic index generation: adding a post to the blog listing is a manual copy-paste, and it's on me not to forget the thumbnail or get a date wrong.
If I ever publish fast enough that markup drift between article pages becomes a real risk, this stops being the right call.

That last point is the actual answer to "static HTML or a generator": it's not a permanent philosophical stance, it's a decision that's correct at a specific scale and wrong past it. I know roughly where my ceiling is (probably somewhere around "I can't keep the last three templates straight in my head anymore"), and I'll reach for Eleventy, or something like it, when I hit it.

The site, as it stands

It's live here: mon portfolio, running on Cloudflare Pages, zero build step, every page a plain HTML file.

Curious where others draw this line. If you've made the jump from hand-rolled HTML to an SSG, what was the actual trigger — a specific pain point, or just a rule of thumb about post count?

Why Madagascar is becoming the new hidden gem for Remote Tech Talent

Herinirina Beranto — Wed, 04 Mar 2026 16:52:02 +0000

The tech world is no longer bounded by Silicon Valley or even European hubs. As **remote work **becomes the standard for engineering teams, "Global Hiring" has shifted its focus to emerging markets. While everyone looks at Eastern Europe or India, a quiet tech revolution is happening in the Indian Ocean.

After years of building bridges between European startups and African talent, I’ve seen firsthand why Madagascar is emerging as a top-tier destination for remote developers. Here is a breakdown of the technical landscape.

A High-Standard Academic Foundation

Contrary to popular belief, the Malagasy tech scene isn't just self-taught. Institutions like ENI (École Nationale d'Informatique) produce engineers with a very strong mathematical and logical background.

In Madagascar, the curriculum often focuses heavily on algorithmic foundations before moving to frameworks. This results in developers who don't just "copy-paste StackOverflow," but actually understand what’s happening under the hood in the memory or the event loop.

The Open Source & Community Vibe

The local community is incredibly active. Whether it's through the Google Developer Groups (GDG) or local DevFest events, the sharing culture is massive. We see a lot of expertise in:

• JS Ecosystem: Massive adoption of React, Next.js, and Node.js.
• PHP Mastery: A long-standing history with Symfony and Laravel.
• Mobile: A huge shift towards Flutter and React Native for the African market.

The "Product-Centric" Mindset

What distinguishes a good remote dev from a great one is the soft skills. Malagasy developers are used to working with international clients (France, Canada, USA). This has forged a culture of:

• Strict Version Control: Git flow is a standard, not an option.
• Asynchronous Communication: Mastering Slack, Jira, and Notion is part of the DNA.
• Timezone Compatibility: Being at UTC+3 makes it a "nearshore" paradise for Europe (only 1 or 2 hours difference).

How to navigate this market?

Hiring remotely in a foreign country can be a challenge regarding vetting and legal compliance. You need to ensure the developer’s setup is professional (fiber optic is now standard in Antananarivo) and that their **technical level **matches your stack.

For those looking to scale their team without the overhead of traditional recruitment, using a specialized technical freelance platform in Madagascar is often the safest bet. It allows companies to access pre-vetted talent who are already used to international standards.

Conclusion

Madagascar isn't just about beautiful landscapes; it’s a powerhouse of code. If you are looking for your next Senior Fullstack or a dedicated DevOps engineer, it’s time to look at the 8th continent.

Have you ever worked with developers from Madagascar? Let’s discuss the challenges and wins of remote hiring in the comments!

DEV Community: Herinirina Beranto