# Build: “Picture of the Day” — Relaxing Natural-World Photography Website Build a complete, production-ready website called **Picture of the Day**. The site is a beautiful, relaxing destination centered around **professional photography of the natural world**: landscapes, mountains, forests, oceans, rivers, wildlife, birds, flowers, weather, deserts, night skies, and other visually peaceful scenes. The goal is not to create a social network or photography portfolio platform. The goal is to create a **calm visual experience that people can visit for a few minutes to relax and enjoy beautiful photographs**. Do not merely create a design mockup. Build the actual working application, including the backend, database, image management, RSS feed, filtering, administration interface, and responsive frontend. --- ## 1. Technology Stack Use a stack that can realistically operate on inexpensive/shared hosting. ### Frontend * Modern HTML/CSS/JavaScript * npm-based frontend tooling * Prefer a lightweight modern framework such as **Astro, Vite, or another appropriate npm-based solution** * Avoid unnecessarily large client-side frameworks if server-rendered HTML can accomplish the job * Responsive design for desktop, tablet, and mobile * Progressive enhancement where practical ### Backend * **Python FastAPI** * REST-style API where appropriate * Server-side functionality should remain simple enough to deploy on conventional shared hosting * Do not introduce Docker as a requirement * Do not require Kubernetes, Redis, Elasticsearch, or other infrastructure that makes inexpensive hosting difficult ### Database Use **SQLite by default**. Structure the application so PostgreSQL could be substituted later, but SQLite should be the default because the target deployment environment is shared hosting. ### Images Images should be stored on the server filesystem rather than inside the database. The database should contain metadata such as: * title * description * photographer * source * original filename * stored filename * upload date * capture date if known * image dimensions * dominant subject * tags * featured status * active/inactive status * sort/order information * optional copyright/license information --- # 2. Core Concept The visitor arrives at a visually beautiful **Picture of the Day** experience. The site should immediately present an excellent photograph without requiring the visitor to understand the application. The experience should feel more like: * a digital nature magazine * a sophisticated photography gallery * a relaxing screensaver * a premium nature website and less like: * a CMS * a database application * a social network * a stock photography marketplace The visual design should communicate: **quiet, beautiful, spacious, sophisticated, natural, immersive.** Avoid visual clutter. --- # 3. Homepage The homepage should prominently feature the current **Picture of the Day**. Possible presentation: * full viewport hero image * subtle dark/transparent overlay * photograph title * short description * photographer/source information * unobtrusive navigation The photograph should be the dominant element. Do not immediately surround it with large amounts of text. The interface should allow the visitor to simply sit and look at the photograph. Include subtle controls for: * next image * previous image * slideshow * information * fullscreen * browsing the gallery Controls should fade or become unobtrusive when the visitor isn't interacting. --- # 4. Full-Screen Slow Slideshow Create a dedicated immersive slideshow mode. Characteristics: * full viewport photographs * very slow transitions * configurable display duration * smooth crossfade/zoom/pan effects * minimal controls * optional metadata overlay * keyboard controls * touch/swipe controls on mobile * fullscreen support where available The default experience should feel almost like a **digital meditation/screen saver**. Do not make transitions flashy. Use subtle cinematic Ken Burns-style movement where appropriate. Allow the administrator to configure: * slideshow interval * transition duration * transition type * whether metadata is shown * whether images are selected randomly or sequentially --- # 5. Gallery / Scrolling Wall Create a separate gallery experience displaying many photographs. Use a beautiful masonry-style or justified image wall. Images should be large enough to appreciate but efficiently loaded. Implement: * lazy loading * responsive image sizing * responsive image formats where practical * infinite scroll or progressive loading * smooth hover effects * click-to-open photograph viewer Clicking an image should open a polished lightbox/viewer. The viewer should support: * previous * next * fullscreen * image information * slideshow * close * keyboard navigation * touch gestures --- # 6. Other Photography-Site Views Include several ways to experience the collection. At minimum: ### Today The current Picture of the Day. ### Gallery All available photographs. ### Explore Browse photographs based on tags/categories. ### Slideshow Immersive full-screen experience. ### Recent Recently added photographs. ### Random A randomly selected photograph. Consider additional views if they improve the experience without unnecessarily complicating the application. Examples: * Landscapes * Wildlife * Birds * Oceans * Mountains * Forests * Night * Seasons These should ultimately be driven by tags rather than hard-coded categories. --- # 7. Tagging System Every image can have multiple tags. Examples: * mountains * ocean * forest * waterfall * sunrise * sunset * winter * autumn * birds * wildlife * flowers * lake * river * desert * night * stars * clouds * peaceful * dramatic * colorful Tags should be managed through the admin interface. Visitors should be able to click a tag and see photographs associated with it. Provide a polished tag/filter interface. For example: **Nature** Mountains · Forests · Oceans · Rivers · Lakes **Wildlife** Birds · Mammals · Marine Life · Insects **Mood** Peaceful · Dramatic · Serene · Mysterious These can simply be tags with optional tag grouping. Do not force the administrator to maintain complicated taxonomy unless it is useful. --- # 8. Search and Filtering Visitors should be able to filter the collection. Support: * tag filtering * multiple tags * search by title * search by description * photographer * date added Keep the interface visually elegant. Do not turn it into a complicated enterprise search page. --- # 9. Image Metadata Each photograph should have a detail view. Display: * photograph * title * description * photographer * source * date * tags * optional location * optional camera information * copyright/license information Metadata should be visually subordinate to the photograph. The visitor should be able to hide metadata and return to an immersive image view. --- # 10. RSS Feed Provide a valid RSS feed for the site's images. Example: `/rss.xml` The RSS feed should contain the latest photographs. Each item should include: * title * description * publication date * photograph URL * link to the photograph's page * appropriate enclosure/media information if possible The RSS feed should work with RSS readers and aggregation software. Also consider: `/feed.xml` if that is more appropriate for the chosen frontend architecture. Do not require visitors to log in to subscribe. --- # 11. Image Filename Security / Obfuscation Do **not expose the original uploaded filename as the public image URL**. For example, if the administrator uploads: `yellowstone_grand_prismatic_spring.jpg` do not serve it publicly as: `/images/yellowstone_grand_prismatic_spring.jpg` Instead generate a non-obvious stored filename or image identifier such as: `/images/7f3c91a8d4e2.webp` or another collision-resistant identifier. The original filename should remain available only as administrative metadata. Do not use predictable sequential filenames such as: `1.jpg` `2.jpg` `3.jpg` Use cryptographically strong/random identifiers. If practical, separate: * original filename * internal image ID * storage filename * public URL This is intended to prevent filenames from revealing the underlying uploaded file naming scheme. Do not describe this as a security boundary; it is primarily filename obscurity. --- # 12. Image Processing When an image is uploaded: 1. Validate the file type. 2. Validate the actual image contents rather than trusting the extension. 3. Generate a random storage identifier. 4. Store the original privately if necessary. 5. Generate optimized display versions. 6. Generate thumbnails. 7. Extract dimensions. 8. Create appropriate metadata. 9. Store database information. 10. Generate responsive versions as appropriate. Prefer modern formats such as WebP or AVIF where browser compatibility and server support make sense. Maintain a reasonable fallback strategy. The system should not send enormous original photographs to mobile devices. --- # 13. Administration Interface Create a completely separate admin interface. There should be **no visible Admin link anywhere on the public site**. The administrator should access it through an obscure/direct URL such as: `/manage` or another configurable route. However, hiding the URL is NOT considered authentication. Protect the admin interface with a proper authentication mechanism. Because this is intended for shared hosting, keep authentication simple and robust. At minimum support: * username/password or configurable admin credentials * secure password hashing * session-based authentication * CSRF protection where applicable * logout * rate limiting or reasonable brute-force protection Do not create public user accounts. There should be **no visitor login system**. --- # 14. Admin Dashboard The dashboard should show: * total photographs * recent uploads * current Picture of the Day * tag counts * storage usage if practical * RSS status * basic site configuration Make the admin UI polished as well, but prioritize usability over decoration. --- # 15. Admin Image Management Allow the administrator to: * upload images * drag and drop images * edit title * edit description * edit photographer * edit source * edit copyright/license * edit location * edit date * add/remove tags * mark an image active/inactive * mark as featured * set Picture of the Day * delete images * replace an image * reorder images where appropriate Show thumbnails in the admin interface. Allow multiple images to be uploaded at once. After uploading, make metadata editing quick. A good workflow would be: **Upload → thumbnails appear → enter metadata → choose tags → publish** --- # 16. Picture-of-the-Day Selection Support several mechanisms. ### Manual Administrator explicitly chooses today's image. ### Automatic System chooses an image according to configurable rules. Possible rules: * random * newest * oldest unused * rotating through collection * weighted by featured status Store the history so the automatic system doesn't repeatedly show the same few images. Allow the administrator to override the automatic selection. --- # 17. Design Language The design is extremely important. Aim for a **high-end contemporary photography website**. Characteristics: * elegant typography * generous whitespace * large photography * restrained interface * subtle animations * smooth transitions * excellent spacing * minimal borders * tasteful shadows * sophisticated dark/light modes where appropriate * responsive layouts * excellent mobile experience The photographs should always be the visual star. Avoid: * excessive gradients * loud colors * gamification * social media-style buttons * excessive rounded cards * cluttered dashboards * cheap-looking template aesthetics * huge navigation bars * excessive text Think **premium nature photography publication**, not SaaS dashboard. --- # 18. Relaxation / Ambient Experience The application should deliberately encourage lingering. Consider: * slow animations * gentle transitions * minimal UI * ambient dark mode * fullscreen viewing * optional automatic slideshow * subtle image information * no advertisements * no notification popups * no engagement metrics * no likes * no comments * no follower system There should be nothing demanding the visitor's attention. The site should feel like a **quiet digital window into the natural world**. --- # 19. Accessibility Implement strong accessibility. Include: * meaningful alt text * keyboard navigation * visible focus states * appropriate ARIA labels * reduced-motion support * sufficient contrast * semantic HTML * screen-reader-friendly controls If the visitor enables reduced motion, eliminate or significantly reduce cinematic movement. --- # 20. Performance Photography sites can become extremely heavy. Treat performance as a first-class requirement. Implement: * responsive images * thumbnails * lazy loading * appropriate caching headers * optimized image formats * image dimensions to prevent layout shift * efficient pagination * minimal JavaScript * code splitting where appropriate The gallery should remain responsive even with thousands of images. Do not load every image into the browser at once. --- # 21. SEO Implement basic but polished SEO. Each photograph should have: * unique page title * description * canonical URL * appropriate Open Graph metadata * Twitter/X card metadata * descriptive image alt text Generate: * sitemap * robots.txt * RSS feed The site should be indexable by search engines. --- # 22. URL Structure Use clean URLs. Examples: `/` `/gallery` `/slideshow` `/explore` `/random` `/photo/abc123` `/tag/mountains` `/tag/birds` `/rss.xml` `/sitemap.xml` Avoid exposing database IDs where practical. --- # 23. Architecture Keep the architecture understandable. Suggested conceptual structure: ```text picture-of-the-day/ frontend/ backend/ database/ images/ originals/ optimized/ thumbnails/ static/ templates/ scripts/ README.md ``` Adapt the structure to the framework you choose. Separate: * public presentation * API * administration * database models * image processing * RSS generation * configuration Avoid unnecessary abstraction. This application should be maintainable by one technically competent person. --- # 24. Configuration Make important settings configurable. Examples: * site title * site description * admin URL * slideshow duration * transition duration * default image selection mode * image quality * maximum upload size * allowed image types * RSS item count * timezone * default tags * theme behavior Use environment variables for secrets. Provide an example environment configuration file. Never hard-code passwords or secrets. --- # 25. Shared Hosting Deployment The application must be designed with conventional shared hosting in mind. Provide deployment documentation covering: * Python environment * FastAPI/ASGI configuration * npm build process * static files * SQLite database * image directories * permissions * environment variables * HTTPS * scheduled tasks if required * backup procedure If shared hosting environments commonly use Apache or cPanel, explain how the application can be deployed in that environment. Do not make Docker mandatory. If FastAPI requires a particular ASGI configuration for deployment, document it clearly. If the selected frontend framework requires a build step, the final production deployment should ideally serve static assets rather than requiring a permanent Node process. --- # 26. Backups Provide a straightforward backup strategy. At minimum: * SQLite database backup * image backup * configuration backup Document what needs to be backed up to completely restore the site. --- # 27. Seed Data / Demonstration Mode Include a small set of sample images or a mechanism for loading sample/demo metadata so the application can be evaluated immediately. Do not include copyrighted commercial photographs without permission. Use appropriately licensed/public-domain/sample imagery. Make it easy to remove the demo content. --- # 28. Error Handling Create polished error pages. At minimum: * 404 * 500 * invalid image * upload failure * authentication failure Errors should feel consistent with the site's visual design. --- # 29. Mobile Experience Treat mobile as a first-class platform. On phones: * photographs should occupy most of the screen * gestures should work naturally * gallery columns should adapt * controls should remain usable * metadata should not overwhelm the image * slideshow should work in portrait and landscape Do not simply shrink the desktop interface. --- # 30. Deliverables Actually build the application. Provide: 1. Complete source code. 2. Frontend. 3. FastAPI backend. 4. Database schema/migrations. 5. Image-processing system. 6. Admin interface. 7. Authentication. 8. RSS feed. 9. Sitemap. 10. Responsive gallery. 11. Full-screen slideshow. 12. Photo detail pages. 13. Tag filtering. 14. Search. 15. Configuration system. 16. Deployment documentation. 17. README. 18. Sample/demo data. 19. Backup instructions. 20. Tests for important backend functionality. --- # 31. Development Priorities Work in this order: ### Phase 1 — Foundation Create the project structure, database, FastAPI application, frontend, configuration, and basic deployment setup. ### Phase 2 — Image System Implement uploading, validation, random filenames, image processing, thumbnails, metadata, and storage. ### Phase 3 — Public Experience Build the homepage, photo detail pages, gallery, tags, filtering, random image, and slideshow. ### Phase 4 — Administration Build the secure hidden admin area and complete image management workflow. ### Phase 5 — RSS / SEO Implement RSS, sitemap, canonical URLs, Open Graph metadata, and SEO. ### Phase 6 — Polish Improve typography, animations, responsiveness, accessibility, performance, loading states, empty states, and error handling. ### Phase 7 — Testing Test: * image upload * image processing * authentication * tagging * filtering * slideshow * RSS * responsive layouts * invalid files * large images * missing images * database errors --- # 32. Important Product Principle Do not optimize this application for maximum features. Optimize it for: **“I opened this website and immediately felt calmer.”** The photograph is the product. Everything else should support the photograph. The visitor should be able to: **open → see something beautiful → relax → explore → discover another beautiful image → continue browsing** without friction. --- # 33. Build Quality Before declaring the application complete: * run the application * test all major routes * test image uploading * test the admin interface * test authentication * test the RSS feed * test the gallery * test filtering * test slideshow * test mobile layouts * fix obvious UI issues * remove placeholder UI * remove dead code * check browser console errors * check backend errors * verify that original filenames are never exposed publicly * verify that unauthenticated users cannot access administrative functions Do not stop at scaffolding. Build a **working, polished application**. When you make architectural decisions that aren't explicitly specified above, favor **simplicity, performance, maintainability, inexpensive hosting, and an exceptional visual experience**.