mdshab.com — this website
Most personal sites are pages. I wanted a graph — events, thinkers, career entries and essays referencing each other — and I wanted it to survive neglect. This site is the result, and it is its own case study.
Context
Twenty years across telecom and cloud, plus a long-standing interest in history and philosophy, produce a lot of connected material. The site is the intersection, structured so that every event, thinker, question, journey entry and article can reference its neighbors.
The problem
Personal sites usually isolate their content: an about page, some posts, no connective tissue. Meanwhile every 'personal brand' template optimizes for appearing impressive rather than being explorable. I wanted the opposite: a site whose structure communicates how the person thinks.
Constraints
Static-friendly with no backend or database; fast on flaky connections (some of my readers are behind restricted networks — which is also why the fonts are self-hosted); accessible to keyboard and screen readers; honest content with no invented facts; maintainable by one person in spare time.
Architecture
Next.js App Router with static prerendering; content as typed TypeScript modules forming a knowledge graph with Map-backed lookups; a shared design system on Fluent UI v9 primitives under a custom theme; a ⌘K command palette driven by a search index built from the same content modules the pages render; MDX essays compiled as React Server Components with zero client-side MDX runtime.
Product reasoning
The product decision is the graph: every entity is an entry point, and every page offers its neighbors. The homepage was redesigned around a professional narrative — value, evidence, thinking, then the deeper library — while the library sections (a 115-event historical timeline, 34 thinkers, a breathing space) remain one click away, repositioned as depth rather than noise.
Trade-offs
TypeScript data files are heavier to write than a CMS but type-checked, diffable in git, and free of runtime dependencies — the right trade for a site that must survive neglect. Dual-rendering the timeline (spatial for desktop eyes, semantic list for screen readers and small screens) costs code and buys accessibility. Serving no analytics protects readers and costs me data I decided I don't need.
Execution
Design system first (tokens, type, Fluent theme), then content models, then rendering. The timeline engine positions 115 events across thirty centuries with d3-scale in one view and a semantically ordered list in the other; filters are URL state so every view is shareable and works without JavaScript. The command palette implements the WAI-ARIA combobox pattern with aria-activedescendant tracking.
Outcome
This site: fully static, bilingual (English and native Persian), WCAG-AA-minded, with zero trackers and a content graph a single person can extend by editing typed files. You are reading an entry in it.
What I learned
Content models are architecture: deciding what an 'event' is — fields, types, relations — was harder and more valuable than any page layout. The same is true of every product I have worked on; this site just made it visible.