A statically generated blog powered by Draftbase.https://demo-blog.draftbase.co/https://demo-blog.draftbase.co/posts/write-the-boring-version-first/https://demo-blog.draftbase.co/posts/write-the-boring-version-first/The abstraction you skip today is the one you would have got wrong anyway.Sat, 28 Mar 2026 00:00:00 GMT<p>Nobody has ever been paged because a function was too obvious.</p> <h2 id="two-implementations-then-a-pattern">Two implementations, then a pattern</h2> <p>The rule that survives contact with real codebases: write it inline the first time, write it inline again the second time, and extract on the third — when you can finally see which parts actually vary.</p> <h2 id="the-cost-nobody-counts">The cost nobody counts</h2> <p>An abstraction built on one example encodes one example's assumptions. The second caller bends to fit. The third adds a flag. Now the shared helper has three modes and every change to it is a change to everything.</p> <h2 id="what-lazy-actually-means">What lazy actually means</h2> <p>Not fewer features. Fewer moving parts per feature — which is the only kind of simplicity that is still there in a year.</p>processhttps://demo-blog.draftbase.co/posts/pagination-is-a-content-decision/https://demo-blog.draftbase.co/posts/pagination-is-a-content-decision/Cursor or offset is an implementation detail. How many items belong on a page is not.Mon, 09 Mar 2026 00:00:00 GMT<p>Most pagination arguments are about mechanics — cursors versus offsets, stable sorts, the total count query nobody needs. Those matter, but they are downstream of a question the engineering team usually skips: what is a page for?</p> <h2 id="cursors-briefly">Cursors, briefly</h2> <p>Offset pagination re-scans rows it has already skipped and shifts under you when something is inserted. Cursor pagination hands you an opaque marker and continues from there. For an API that feeds a build, cursors are the right default — you are walking the whole set once, in order.</p> <h2 id="the-part-that-is-not-mechanical">The part that is not mechanical</h2> <p>Five posts per page is a reading decision. So is whether the archive is paginated at all, or is one long list that a browser's find-in-page can search. Ask what a reader is doing on that screen before picking a number.</p>architecturehttps://demo-blog.draftbase.co/posts/build-time-secrets/https://demo-blog.draftbase.co/posts/build-time-secrets/A static site has no server to leak from, which makes it easy to forget the build had credentials.Fri, 20 Feb 2026 00:00:00 GMT<p>Static output is reassuring: there is no runtime, so there is nothing to compromise at runtime. The build is a different story.</p> <h2 id="the-three-ways-it-goes-wrong">The three ways it goes wrong</h2> <ol> <li>The key gets a public prefix. Every framework has one — <code>PUBLIC_</code>, <code>NEXT_PUBLIC_</code>, <code>VITE_</code> — and it means "inline this into the browser bundle". Renaming a variable is enough to publish a credential.</li> <li>The key gets committed. Usually in a <code>.env</code> that was never added to <code>.gitignore</code>.</li> <li>The key is over-scoped. A read-only delivery key that leaks is an inconvenience. A management key that leaks is an incident.</li> </ol> <h2 id="what-to-do-about-it">What to do about it</h2> <p>Use the narrowest scope that can build the site. Keep write-capable keys off CI entirely — if seeding needs one, run it from a laptop. And grep your build output for the key before you trust the setup, because that check takes five seconds and assumptions do not.</p>securitycihttps://demo-blog.draftbase.co/posts/cms-should-not-know-your-layout/https://demo-blog.draftbase.co/posts/cms-should-not-know-your-layout/Page builders are a trap. Model the content, then decide separately how it renders.Mon, 02 Feb 2026 00:00:00 GMT<p>The fastest way to make content unusable is to store it as a layout.</p> <h2 id="symptoms">Symptoms</h2> <p>You know you have this problem when moving a post to a new design means opening every entry, or when the answer to "can we put this on the mobile app too?" is no.</p> <h2 id="model-the-shape-not-the-page">Model the shape, not the page</h2> <p>A blog post has a title, a body, an author and a date. That is true whether it renders as a web page, an RSS item, a newsletter, or a card in an app. The two-column layout with the pull quote on the right is a rendering decision, and it belongs in the code that renders.</p> <h2 id="the-test">The test</h2> <p>Ask whether you could rebuild the front end from scratch, in a different framework, without touching a single entry. If the answer is no, the layout has leaked into the content.</p>cmsarchitecturehttps://demo-blog.draftbase.co/posts/static-sites-are-back/https://demo-blog.draftbase.co/posts/static-sites-are-back/Rendering pages at build time is not a nostalgia trip. It is the cheapest way to serve content that changes a few times a day.Wed, 14 Jan 2026 00:00:00 GMT<p>Every few years the industry rediscovers that most pages do not change between requests. A marketing site, a documentation set, a blog: the content shifts when someone publishes, not when someone visits.</p> <h2 id="what-you-actually-pay-for">What you actually pay for</h2> <p>A server-rendered page costs you compute on every request, plus the operational surface that comes with it — scaling rules, cold starts, a database that has to stay up. A static page costs you one build.</p> <h2 id="where-it-stops-working">Where it stops working</h2> <p>Static rendering falls over the moment content has to be personalised per visitor, or the catalogue is large enough that a full rebuild takes longer than the publishing cadence. Both are real limits. Neither applies to a blog.</p> <h2 id="the-practical-setup">The practical setup</h2> <p>Content lives in a CMS. A webhook fires on publish. CI rebuilds and pushes HTML to a CDN. The whole loop takes a minute or two, and nothing is running in between.</p>architectureperformance