Date: 2026-03-06 Status: Accepted
This site is a portfolio for DeFlo & Co, an interior design studio in Los Angeles. The original site was built by a prior developer as a WordPress template. A second attempt rebuilt it as a Django + Next.js monorepo with Docker, nginx, and a custom admin panel - functional, but over-engineered for the use case. As such, we've decided to reduce our stack in order to avoid future complications.
The client is a design-forward small business. Their priorities are visual: how the site looks, how the photography is presented, whether it "feels right." They should not need to think about tech stack, infrastructure, or deployment.
The codebase should be easy for any Next.js developer to pick up without onboarding overhead.
Why not a VPS with Docker? A VPS requires infrastructure knowledge (nginx, compose, TLS, process management) that a future developer may not have. Every layer of infrastructure is a maintenance burden and a potential point of failure that the client cannot diagnose or fix. For a portfolio site serving mostly static content, this overhead buys nothing.
Why Vercel? Vercel is purpose-built for Next.js. Deployment is "connect repo, push to main." There is no server to manage, no Docker to configure, no nginx to debug. The free tier covers this site's traffic. Preview deployments make the client review loop trivial. Any developer who knows Next.js can work on this without learning the deployment pipeline.
Why not keep Django for content management? The Django admin solved a real need (self-service content updates) but at disproportionate cost: a Python backend, a database, migrations, seed scripts, API serializers, Docker orchestration, and a reverse proxy. All of this to let the client occasionally swap a photo or edit a paragraph.
A headless CMS provides the same self-service capability through a polished visual UI, with zero infrastructure to maintain. The client gets a better editing experience, and the codebase stays simple.
The client can manage projects and blog posts (text, images, galleries) independently through Sanity's editing UI. This is the content that grows over time and changes frequently. See ADR 002 for the CMS decision and what's in/out of scope.
Static pages (landing, team, process, contact) are hardcoded in components. Their copy is tightly coupled to layout decisions - spacing, parallax breaks, background transitions - so editing them is inherently a design change, not a content update. These pages change rarely, and when they do, a developer should be involved anyway. Pulling them into the CMS would either create a rigid schema that mirrors the layout (no benefit over editing the component directly) or a flexible one that gives the client the ability to break the design.
For structural changes (new pages, layout modifications), any Next.js-literate freelancer should be able to pick up the codebase - there are no custom abstractions, no clever patterns, just components and a CMS integration.