I recently started a side project, and I want to do something I've never done before: build it in public. Not with the daily "Day N" theatrics, but milestone by milestone, with honest write-ups of how it actually went. This is post number one.

What's worth writing about isn't the app — it's how I started it. The default move with a capable AI assistant is to ask it to do the work: "set up a Django project with PostgreSQL and Docker." Three months later you're staring at a folder structure you can't justify, a license you didn't think about, and a branching strategy you didn't pick. I wanted to flip the dynamic — the agent surfaces options and documents decisions; I make them. Along the way I picked up a couple of patterns — CLAUDE.md and compound engineering — that I think deserve more attention than they get.

This is the first post in a series I'm calling Building We Remember. One long-form article per milestone here on dev.to, shorter updates on X as issues get closed.

Meet We Remember

We Remember is a calendar and reminders app I'm building with Django. The eventual goal is a personal productivity tool with a plugin-based architecture, so it can integrate with external services over time — but that's roadmap, not today.

I'm building it because I want a calendar app I actually own and can grow as I learn. I'm starting small on purpose: a cheap VPS, a single domain, and a minimalist 0.1.0 milestone — "Foundation — minimal Django app with healthcheck endpoint, Docker Compose setup, linting, testing and first production deploy with CI/CD pipeline." No plugins yet, no integrations, no premature architecture.

The stack is intentionally boring: Django on Python 3.12 with uv, ruff, pytest, Docker Compose, GitHub Actions, deployed to a Hetzner VPS behind Cloudflare. Full details in the next post.

The project is licensed under AGPL v3 — copyleft that extends to network use, same model as Nextcloud, Grafana, and Cal.com. The repo is public from day one. I'm not committing to a commercial path; I'm not ruling one out either. AGPL keeps the door open both ways: as long as I'm the sole copyright holder, dual-licensing remains a future option.

That's the app. The rest of this post is about how the foundation was laid.

What this looks like in practice

Before any code was written, I went through a series of micro-decisions out loud with the agent. A few examples:

• License. MIT vs Apache 2.0 vs GPL v3 vs AGPL v3 — the agent laid out the trade-offs, I picked AGPL v3 for copyleft that extends to network use.
• Project structure. Default Django layout, src/, or apps/ for grouping Django apps? apps/ won — middle ground between flat default and over-engineered src/.
• First milestone scope. I almost over-scoped 0.1.0. The agent pushed back: "if the goal is foundation, drop the plugin system and external integrations from this milestone." Right call. The plugin system, the integrations, the actual product — that all comes later.

None of these decisions are special on their own. What's special is that I made them, with the agent acting as a structured devil's advocate.

Where CLAUDE.md comes in

If you stop here, the next session starts from zero. The agent doesn't remember the license discussion, the dependency management decision, or why you chose apps/ over src/. You'd have to re-explain everything, every time. That's where CLAUDE.md comes in.

CLAUDE.md is a markdown file you commit to the root of the repo. It's not a prompt. It's not instructions in the imperative mood. It's a context contract — a short document that captures the conventions, decisions, and shape of the project, so that any future session (yours, the agent's, or a contributor's) starts already grounded.

A simplified version of mine looks like this:

# CLAUDE.md

## Project overview
Calendar events and reminders management app built with Django,
with a plugin-based architecture for external service integrations.

## Tech stack
- Python 3.12, managed with uv
- Django (latest stable)
- ruff in strict mode for linting and formatting
- pytest with pytest-django
- django-environ for environment variables

## Project structure
- `apps/` contains Django applications
- `config/` contains the Django project (settings, urls, wsgi)

## Conventions
- Conventional Commits (feat, fix, chore, docs, refactor, test)
- Branches: `<type>/<issue-number>-<short-description>`
  - Types: feature, bugfix, chore, hotfix
- Simplified Git Flow: master, develop, plus typed branches off develop
- One issue per branch, merged via PR

The point isn't to constrain the agent. It's to make sure the agent doesn't waste your time re-litigating settled decisions, and that any code it suggests aligns with the conventions you've already chosen.

The compound loop

There's one more piece I'm experimenting with: compound engineering, a philosophy described by Kieran Klaassen and the team at Every in their guide. The core idea is that every unit of engineering work should make subsequent work easier, not harder. Most codebases get worse over time because each feature negotiates with the old ones; compound engineering flips this — features and fixes teach the system new capabilities, and the codebase compounds instead of decaying.

Their main loop has four steps: Plan → Work → Review → Compound. The first three are familiar. The fourth is the one most people skip, and it's where the gains live: capturing what worked — documenting solutions, updating CLAUDE.md, encoding new patterns so the next session starts smarter than the last.

On Claude Code, Every ships this whole workflow as a plugin. I've installed it and folded it into my workflow. The non-obvious operational question for me has been when to invoke the Compound step. On the feature branch, before merging? Premature — the code is still in motion. On develop, after the PR is merged? Stable, reviewed, tested code. Much higher signal. I'm going with the second.

So in practice my loop looks like this:

1. Pick the next issue from the milestone.
2. Plan the implementation in dialogue with the agent.
3. Implement, test, open PR, review, merge into develop.
4. Run the Compound step on develop — capture what worked, update CLAUDE.md if a new pattern emerged, file new GitHub issues for any refactors that surface.
5. Move to the next issue without breaking flow.

Step 4 is the key. Insights don't interrupt current work and don't get acted on impulsively — they become artifacts: notes in CLAUDE.md, issues in the backlog, prioritized like everything else.

Why boring, in an era that isn't

Compound engineering, taken to its logical conclusion, points toward a place where you describe an outcome, the agent plans, builds, reviews itself, and hands you a PR. Vibe coding. Idea to merge with minimal contact with the actual code. For a senior engineer building production software at speed, that's a real productivity unlock — and it's where I want to end up too, eventually.

Where I am, where I'm going

But "eventually" is the operative word. I'm a computer engineering student, working toward becoming an engineer — not just for a well-paid job, but because I want to understand the systems I build.

So in this phase I'm following the boring loop on purpose. I plan with the agent, I implement, I read every diff, I review my own PRs. The compounding I care about right now isn't only in the codebase; it's in me. A student who vibe-codes too early ends up with a working app and an empty head. I'm choosing not to be that student.

This changes over time, deliberately. As the mental compounding accumulates, I'll hand more over to the agent. The point isn't to refuse the future of engineering; it's to walk into it with a foundation, not a façade.

A note on writing in public

That's also the real reason I'm writing this in public. Not because I expect the first article to find an audience — most don't, and that's fine. The project is a vehicle for my own growth, and these posts are the trace of that trajectory. If they help someone else thinking through the same trade-offs, even better. If they don't, they still help me.

What's next

The next post will cover Milestone 0.1.0 end to end: the actual Django setup with uv, ruff, pytest, the healthcheck endpoint, Docker Compose, and the production deploy on Hetzner with Cloudflare in front. Code, configs, and the things that didn't work the first time.

If you want to follow along, the repo is public — github.com/OranguEngineer/we-remember — licensed under AGPL v3.

This is part 1 of the **Building We Remember* series — milestone-by-milestone notes on building a Django side project with an agentic AI workflow. Repo: github.com/OranguEngineer/we-remember · AGPL v3.*