Hello!
How did buildandmarket.dev come about?
When I came up with the “brilliant” idea of starting a blog about marketing from a programmer's perspective, I was initially most excited about the technical side of things. I could create a new website. A new framework to test. UI design. But the whole point of this blog is to do more and think less.
When I decided to write a blog, I had to decide what to create it with. There were several options:
- WordPress - archaic, I wanted something fresher
- Next.js - a technology I'm familiar with, good for SEO due to SSG, a slight overkill for a blog
- Astro - cool, fast, components can be written in different frameworks
- Medium/Substack - I didn't want vendor lock-in, plus it's easier to experiment with SEO and conversion if I have full control over the blog
I rejected WordPress because I wanted something fresher and with less clicking around the UI to configure things. Medium was also out because I wanted to have control over every aspect of the application.
So what did I decide on?... drum roll ... Next.js
This is what the whole blog looks like under the hood

CMS for a blog
But that's just it. A blog isn't just about the UI. You have to fill it with content somehow, so Strapi came into play as a blog CMS, hosted on Railway. I also considered Payload CMS, but I've used it before, so now I wanted to try something new. There may be some photos on the blog from time to time, and they need to be hosted somewhere, so I went with R2 storage on Cloudflare.
What are the benefits of Next.js for a blog?
- Easy hosting – I connected the GitHub repo to Vercel, and after merging the PR to main, the blog automatically rebuilds and publishes the latest version.
- Server Actions – all the newsletter logic runs on the server side, so nothing leaks to the client.
- React - very fast UI building, I use shadcn/ui components, which I have styled appropriately
- Server Components - the vast majority of components are generated on the server side to minimize the amount of JS sent to the browser
- SSG and ISR - SSG, where the entire page is generated on the server side when the blog is built, and nothing else needs to be added. ISR, or Incremental Static Regeneration, is a bit more interesting. The pages are still generated on the server side, but if I make a change on the CMS side, e.g., add a new post or edit an existing one, the CMS fires up the application and Next.js automatically rebuilds only the pages I have edited, so I don't have to worry about anything and always have efficient pages that rebuild themselves.
How ISR works in Next.js
When fetching posts, I create a corresponding tag for them:
fetchStrapi<StrapiPost[]>(“posts”, {
tags: [“posts”],
}),Refreshing posts via tag:
if (payload.model === “post”) {
revalidateTag(“posts”, “max”);
}And that's it. Why is this better than a full rebuild? For example, if I have 200 posts in two language versions, that's 400 pages to build. Thanks to ISR, if I make a change on only one page, I rebuild one page, not 400.
Lighthouse score for the post buildandmarket.dev

Tools I use
In addition to the stack itself, the blog uses several marketing and analytics tools:
MailerLite
I also wanted to capture some of the traffic on the site for a newsletter for those interested. For a moment, I had the idea of building my own system, but fortunately, I quickly rejected it—it would have been overkill for my purposes. It's better to use a ready-made solution and focus on creating content. So I reached for MailerLite. It's a pretty cool solution. I can create dedicated groups for each language version and add automation that sends a welcome email after signing up.
PostHog
I'm not a UI/UX expert, but I did what I could on this blog. But “what I could” is not enough to know if it works. I can guess and pretend to read people's minds, but in the end, it will be my subjective opinion. How do I know if someone is actually reading my posts or leaving the site after reading the first sentence? PostHog came to the rescue. I can see what visitors to the site are doing, where they click and where they don't, how far they scrolled, and how long it took them to leave the site. An additional advantage is the European servers on which PostHog is hosted. And, of course, everything only starts working after you accept cookies. :)
Sentry
I also needed to track potential errors that may or may not occur (I hope this won't happen, but you never know). Here, I used a classic tool, Sentry. Very efficient and easy to configure.
Bilingualism (next-intl)
From the very beginning, I created the blog with bilingualism in mind: Polish and English. Adding i18n at later stages can be problematic, so I recommend doing it right away. I used next-intl to handle bilingualism, which allowed me to localize URLs (not just prefixes, but entire paths). The glossary is available at /pl/slownik and /en/glossary, the “about me” page /pl/o-mnie and /en/about. Google sees these as two separate pages with correct hreflang, not duplicates.
Summary
| Technology | Application | Why this one |
|---|---|---|
| Next.js | Framework | ISR and cache tags – pages rebuild themselves after changes in CMS |
| Strapi CMS | Content management | Self-hosted on Railway. Full control, low cost |
| Cloudflare R2 | Photo hosting | Low cost, free egress, global CDN |
| Vercel | Hosting | Push to main automatically deploys the application, image optimization |
| MailerLite | Newsletter | Free plan, simple API, double opt-in |
| PostHog | Analytics | Hosted in the EU, session recordings, UTM tracking, clear charts |
| Sentry | Error monitoring | Quick integration with Next.js |
| next-intl | Bilingualism | Localized URLs, e.g., /slownik and /glossary |
| shadcn/ui | UI components | No imposed styles, I can style everything myself |
// Chcesz więcej konkretów?
Konkretne taktyki marketingowe dla programistów. Bez teorii, tylko rzeczy do wdrożenia.
Dołącz do programistów, którzy już czytają.