Build Daily at builddaily.io

Build Daily is a build-in-public engineering surface — and it's built the way its posts describe. One site, builddaily.io, carries field-notes essays, daily logs, project pages, a resources library, and a chat agent that answers over the whole published corpus. The thing being shipped is the publication itself: content on a cadence, riding a stack that stays cheap to run.

What's on it

The feed is the newest of these and the least like the rest. Builders worth following get tracked, their new videos pulled, and a read on what each one covers built and approved before it reaches the page. Transcripts turned out to be blocked at the source with no free way around them, so the summary is assembled from the video's own description and chapters by a local model, which costs nothing to run and is honest about what it saw.

How it's built

The delivery stack is deliberately plain where plain pays. The site is a Next.js app exported to static files, deployed to S3 and served through CloudFront; the dynamic surfaces run on Lambda behind that. Static-first keeps the reading experience fast and the hosting cheap, so the Lambdas carry only what has to be live.

The chat is where the engineering shows. It's a retrieval-augmented agent over the whole published corpus — every post, project page, and daily log becomes retrievable context, a digital twin of the published record. The output is shaped by a typed signature rather than a hand-tuned prompt string: the model fills declared fields and the bridge composes the visitor-facing text, so a malformed answer is a validation failure instead of a plausible paragraph.

Inference started on a local model at no cost and moved to a hosted one, which is the honest version of that story. Local was genuinely free and genuinely slow enough to feel broken on a first question, and a visitor who waits twenty seconds has already left. The trade was made deliberately, with a named default model, a fallback behind it, and a bounded deadline so the agent returns its own reply before anything upstream cuts the line. Answering a question now costs a fraction of a cent rather than nothing. The feed's summaries still run on a local model, because nothing there is waiting on a human.

The schedule is the deliverable. Everything else — the chat, the project pages, the library — earns its slot because it's served by something that keeps shipping.

How the chat fits

The chat agent reads the same corpus that drives the rest of the site — posts, projects, daily logs — and answers from what's already published: the work in progress, the stack in use, the take on a given tool. A privacy gate decides what enters the corpus, and it fails closed: a file that doesn't carry an explicit public flag stays out of retrieval rather than being included by default. It runs as a function behind the same edge that serves the static pages.

The failure worth recording is the one that ran for weeks. Every live answer was failing on an expired credential, and the code caught the failure and served a pre-written paragraph at a success status — so the page looked healthy from every angle except the one that mattered, and nothing in the logs said "down." The substitute is gone. The agent now admits when it can't answer, and the readiness badge reads a real check instead of a hardcoded default.

The chat isn't the product. It's an interface onto the publication.

Why a publication and not a portfolio

A portfolio is a brochure — frozen, descriptive, dated the moment it ships. A publication is alive. It updates. It produces. The cadence becomes its own proof: the work is happening today, not in some archived past.

For an engineer selling AI capability, that difference is the pitch. A publication that keeps adding posts, with real projects and a working RAG agent on it, shows the shipping before anyone has to ask about it.

Visit