This website is a working product, not a design exercise. I built it to publish practical AI guides, document real projects, and keep the reading experience simple enough that the content stays useful. The current build uses React and TypeScript for the interface, Vite for bundling, a small Node.js server for runtime concerns, PostgreSQL for operational data, and version-controlled Markdown for articles. The problem I wanted to solve AI content is easy to publish and difficult to organize well. Tool lists become outdated, disconnected tips do not build repeatable skills, and a large content system creates maintenance work before it creates value. I wanted a smaller system with clear boundaries: articles should be easy to review in Git the public reading layout should stay consistent unfinished sections should remain hidden backend features should exist only where runtime state is genuinely required claims should describe what the product does today Why articles are static Markdown The first version included an article editor and database-backed article records. That added an admin workflow, rich-text dependencies, mutation endpoints, and more failure modes than the publishing cadence required. I replaced that system with Markdown files under src/content/articles. Each file contains frontmatter for its title, summary, tags, publication date, reading time, difficulty, and intended outcome. At build time, Vite imports those files. A small renderer converts the supported Markdown into sanitized HTML while the existing article page continues to handle navigation, headings, reading metadata, and related content. What still needs a backend Static content does not mean every feature should be static. The Node.js backend still handles operational concerns such as database-backed workshop records, payment verification, and transactional communication where those features are enabled. That separation keeps publishing simple without pretending that stateful workflows can be solved with files alone. Building for honest launch states Several homepage features are optional. Social links render only when verified URLs are configured. The starter kit remains hidden because there is no reviewed resource or consent-safe signup flow to publish. Workshop visibility and new checkout creation are controlled by one environment flag. This prevents empty cards, placeholder buttons, and promises that the site cannot fulfil. Testing the result For each meaningful change I check more than compilation: Build the production bundle. Start the production server locally. Exercise the public routes and removed or disabled API boundaries. Capture the rendered pages in a real browser. Inspect the layout at desktop and mobile sizes. The goal is not to claim perfection. It is to make the current state observable and avoid shipping obvious regressions. Current limitations The Markdown renderer intentionally supports a focused subset rather than every Markdown extension. The site does not yet have a reviewed email publication workflow. Project content is currently small because I would rather publish one documented build than fill the page with placeholders. Those constraints are visible by design. When a feature becomes real, it can be added without changing the editorial standard. What I would improve next The next useful improvements are richer project case-study metadata, automated accessibility checks, and stronger content validation during the build. I would also add verified social and video links only after confirming that every destination is ready for public traffic. The principle behind the site stays the same: build something useful, test the result, and explain the process—including the parts that changed along the way.