Building Anzilah's Website: Architecture, Decisions, and Everything In Between

This project started as a family thing. Anzilah wanted a website, I wanted to build it properly, and those two goals aligned well enough to get started. Before I wrote a single line of code, I sat down with her and gathered requirements the way I would for any serious project. She is a curious person and wanted a place to share what she thinks. A standard blog made sense for longer pieces. But I added a second content type I called thoughts. A thought is smaller than a blog post, often a title and one or two paragraphs. The idea was to give her a way to put something out when writing a full article felt like too much work for the idea she had in her head. Both formats publish independently, and both have their own management flows.

AI Generated

The requirement that shaped every other decision was the resume. She wanted her full professional profile on her website, and by full I mean complete: Experience, Projects, Education, Skills, Certifications, Publications, Awards, Volunteering, Languages, Courses, Test Scores, and Organizations. That is twelve distinct content types, each with its own fields and information. Most websites give you a PDF download and call it a day. Anzilah wanted a live, browsable, structured resume that anyone could read directly in their browser without downloading anything. Each section lives on its own page, loads fast, and stays in sync with whatever she updates in the admin panel. That was the bar I set out to hit.

I chose a tech stack based on one question: what lets her set it up once and forget it exists, while still letting me build fast when she needs something new? The answer was Next.js, Supabase, and Cloudflare. Next.js is the framework that builds and serves the website. Supabase is where all the data lives, think of it as the database and login system combined. Cloudflare stores all her images and files. These three services together mean the site has no server to manage, no manual backups to worry about, and no hosting bill that surprises anyone at the end of the month. She updates a blog post, it goes live. She uploads a photo, it appears. Nothing in between.

The resume problem got solved with a pattern I call config-driven design. Rather than building twelve separate management screens, one for experience, one for education, one for skills, and so on, I built one form that reads a configuration file and adapts itself to whatever section it is managing. Think of it like a template that knows how to change its own questions based on what you tell it. Adding a new resume section to the site now takes one small config entry and zero new code. That decision means the site grows with Anzilah's career without requiring me to build new screens every time she picks up a new certification or joins a new organization.

For writing blog posts, I built a rich text editor directly into her admin panel. A rich text editor is the same kind of tool you use in Google Docs: you type, format text, insert images, and see the result as you work. What makes hers different is that it also handles video. She can record a video, upload it directly from the editor, and the site takes care of the rest: converting it to a format that plays on every device, at every internet speed, without buffering. A viewer on a fast connection gets crisp quality. A viewer on a weak mobile signal gets the same video, at lower quality, and it plays without stopping. The site chooses the right version automatically.

The part I spent the most thought on was page speed. When someone opens Anzilah's blog, the page they see was almost certainly built hours ago and stored at a server close to them geographically. It was built once and handed to every visitor who asks for it. The database behind the site gets asked for new data at most once a minute across the entire site, regardless of how many people are reading at the same time. When Anzilah publishes a new post, the site rebuilds only the pages that changed, in the background, while existing visitors see the current version without interruption. The result is that her website loads in roughly fifty milliseconds for most visitors. That is faster than the human eye can register a change.

I layered that speed across five distinct levels. First, a global network of servers holds copies of her pages close to wherever her readers are located. Second, the site itself caches its own pages for sixty seconds, so repeat visitors get instant responses. Third, when multiple parts of a page need the same data, the site fetches it once and shares the result internally rather than fetching it multiple times. Fourth, image files get stored in a format that is forty percent smaller than a standard photo without any visible quality loss. Fifth, each section of the homepage loads as its own independent unit, so if one section is slow, the rest appear on time and that section fills in a moment later. Every level exists to protect the visitor from waiting.

The homepage loads each section in parallel, which means the visitor sees the page layout and placeholder shapes almost instantly, and the real content replaces them as each section finishes loading. This is the difference between a site that shows a blank screen for two seconds before anything appears, and a site that feels alive from the moment you open it. The blog section, the thoughts section, and the Duolingo progress widget all load at the same time as separate processes. The slowest one determines how long the user waits for that specific section, but it has no effect on how fast every other section appears.

The site has a few security gaps I documented honestly rather than glossing over. The admin panel, which is the private area where Anzilah manages her content, currently has a missing lock on the door. Anyone who guesses the URL could reach the login screen and see the layout of the admin panel, even though they would get no actual data without her credentials. The fix is a piece of code called middleware that intercepts every request to the admin area and turns away anyone without an active session before the page even starts to load. The access rules on the database are also written too broadly right now: any logged-in user could theoretically edit records, rather than scoping that access to Anzilah's specific account. Both of these get addressed before the site goes into full public use.

After delivery, Anzilah and I agreed to keep the codebase, hosting, and infrastructure in my hands so I can continue developing and maintaining it over time. The architecture was built to grow: new resume sections cost one config entry, new blog posts publish in seconds, and the entire system runs on infrastructure that scales automatically without me touching anything. What started as a family project became one of the more complete personal portfolio systems I have built. Every requirement she had, from her blog to her full structured resume to her thoughts feed, lives under her own domain, on infrastructure she owns, with no dependency on any third-party platform telling her what she can or cannot publish.