Why we chose MDX and ISR for the Awiser blog
How we picked the stack for the Awiser blog: a short note on MDX, Incremental Static Regeneration, and why most blogs do not need a CMS.
Awiser is built on a Next.js front end backed by a custom API. When we sat down to add a blog, the obvious move was to reuse the same stack: an endpoint, a Redux saga, a fetch on mount. We did not.
The constraint that changed the answer
The whole point of a company blog is organic search. If a post does not rank, very few people will read it. And ranking is not just about content quality. It is about what the crawler sees on the very first byte of the response.
Our existing dynamic routes (project pages, post pages) render on the client. The HTML shell is empty until JavaScript runs. Google can handle that, slowly. Slack, X, LinkedIn, and the rest of the social unfurl bots cannot. Share a client rendered URL on Slack and you get the default site card, not the post card.
For a social network, that is acceptable: the share value of an individual project page is small. For a blog, it is the entire game.
What MDX plus ISR buys us
MDX lets us write posts in Markdown and store them in the repository as plain files. No CMS, no admin UI, no draft state machine. A post is a pull request.
Incremental Static Regeneration means Next.js renders each post to static HTML at build time, but also re-renders it on demand if the underlying file changes (revalidate every hour, in our case). The result: full HTML in the first byte, including the title, description, OG image, and the full JSON-LD graph.
That is what unlocks ranking. That is what makes the Slack card show up correctly. That is what makes the Lighthouse SEO score hit one hundred without trying.
What we gave up
Three things, none of which mattered for our use case.
- Non technical authors cannot publish without touching Git. Our team is small and engineering led, so this is fine.
- Real time editing is not possible. Posts are immutable until the next deploy or the next hourly revalidation.
- Scheduling is approximate. We can set a future date in the frontmatter, but the post becomes visible the moment it is committed.
If any of those become problems, the MDX layer is small enough that swapping it for a CMS later is a contained change.
The lesson
When the existing pattern in a codebase does not match the SEO ceiling you need, do not stretch the pattern. Pick the right tool for the job, even if it adds a small amount of architectural variance.
For a social network feed, client rendering is fine. For a blog, it is not. Different problem, different answer.