Personal site / Engineering case study
Portfolio Website
Django portfolio site for projects, experience, and contact.
Project facts
Django application and content model
Responsive interface
Generated PDF CV
Publishing and contact protections
Overview
A Django-powered personal portfolio with database-backed profile content, projects, experience, and a contact form.
01 / Context
The problem
Project details and a downloadable CV need to stay consistent as experience and work samples change. Maintaining a separate PDF by hand creates duplicate editing work.
My role
I designed and implemented the Django site, its content models, generated CV, responsive interface, publishing controls, contact protections, and automated test coverage.
Constraints
Website and CV content needed one source of truth, drafts could not become public, and the site needed to remain maintainable without a large CMS.
02 / Engineering
Technical decisions
Django admin owns structured portfolio content and explicit publication status. Website pages and the ReportLab PDF use the same content provider, reducing drift between formats. Stable project slugs provide canonical URLs, while draft records and unpublished evidence remain outside public responses.
The site stays a single Django application because its scale does not justify service boundaries or a large CMS.
Validation
Automated checks cover shared website and CV content, draft visibility, contact protection, canonical project routes, and responsive behavior.
03 / Delivery
What the project delivers
Visitors can browse structured case studies and download a CV generated from current published content. The site also provides responsive navigation, accessible themes, SEO metadata, contact abuse protection, and regression tests.
Lessons and next steps
A small content system benefits more from one authoritative data path and strong publication controls than from additional infrastructure. Privacy rules also need tests, not only editorial guidance.
Architecture overview
Django models and admin provide the content source. Public views filter publication state, templates render the website, and ReportLab produces the CV from the same provider.
This public summary omits private domain rules, data relationships, security policies, and operational details.
Engineering challenges
Preventing content drift
Context: Maintaining website and CV content independently creates inconsistent information.
Decision: Use one content provider for both HTML and generated PDF output.
Trade-off: A shared provider reduces duplication but requires website and PDF consumers to evolve together.
Validation: Automated checks compare the content supplied to both outputs.
Controlling public visibility
Context: Editorial content needs a safe path from draft to public display.
Decision: Apply explicit publication controls before rendering public output.
Trade-off: Explicit publishing controls add editorial steps but make public exposure intentional and testable.
Validation: Validation focused on draft and published visibility behavior.
Technical focus
Django class-based views
Database-backed content
Contact form persistence
Public architecture diagram
Interested in work like this?
This public case study demonstrates engineering judgment without exposing internal business logic.
Let’s start a conversation ↗