Camerawalk: Technical Case Study

Overview

Camerawalk is a standalone Django platform for small paid local photography walks.

The core loop is deliberately concrete: a host creates a walk, participants book and pay, attend the walk, upload up to three favourite photographs, the host moderates the images, participants vote, the system calculates results, and prize and host-payout records are created for manual fulfilment.

The platform is not a generic event system and not a social network. It is built for the full camera-walk loop: listing, booking, payment, attendance, upload, moderation, voting, results, prize record and host payout record.

The public brand domain is camerawalk.org. The currently available development and pilot sites are under walks.narian.org.uk, including the Glasgow place site and the common/global site.

At a glance

Why It Was Built

Photography walks have a simple human appeal: people get out, look more carefully, meet others, take pictures, and see how different photographers respond to the same route.

The awkward part is everything around that: bookings, capacity, payment, route information, host approval, safety notes, participant contact windows, uploads, moderation, voting, public results, prizes, and host payout records.

Generic event tools can handle the booking part. Social platforms can handle fragments of the sharing part. Neither gives a coherent workflow from walk listing through to photo results and prize record.

Camerawalk was built to make the whole loop explicit and operable in one system.

Technical Stack

Application Framework: Django

Django was used because it had become a known and trusted base platform: robust, easy to code against, and well suited to stateful server-rendered workflows.

The platform needs models for places, walks, users, profiles, bookings, payments, itineraries, risk assessments, photo entries, moderation states, votes, results, prize awards, leader payouts, host agreements, host applications and operational settings. These models encode who may do what, when, and under which conditions.

Django’s model, form, view, permission, migration and admin patterns provide the right amount of structure without needing a separate frontend application.

Database: PostgreSQL

PostgreSQL stores the platform state: bookings, walk lifecycle, payment status, photo moderation, ranked votes, result calculations, prize records and payout records.

This is a relational problem. A participant can only upload to walks they booked. Votes must be private. Hosts must not win their own participant prize. Host photos may support galleries but must not enter participant voting. Money amounts require currency and integer minor-unit storage. A payout may be blocked until the prize is fulfilled.

Deployment: Docker Compose

The project is designed as a separate Docker Compose deployment with its own database, network, runtime configuration, media/static storage, cookies, Stripe configuration and domain settings.

Runtime secrets are held outside Git under the Camerawalk environment configuration. The app is designed for place-based hostnames and eventual public deployment under the Camerawalk brand while retaining Photowalk as the internal repository/project name.

Place-Based Architecture

Camerawalk is designed around places.

A Place represents a city, town, district or local area where walks can happen. Hostnames can resolve directly to places, so a Glasgow hostname can show Glasgow walks without repeating the place slug throughout every URL.

This supports a simple growth model: prove the loop in Glasgow first, then allow other places later. The platform can support place-specific landing content, walk listings, host workflows and public results while retaining global/common management pages.

Walk Lifecycle and Safety

A walk is not publishable merely because it has a title and a nice photograph.

A publishable walk needs the operational basics: approved host, itinerary, risk assessment, meeting point, end point, expected finish time, capacity, price, currency and relevant host requirements. For new hosts, the first walk requires platform review before publication.

The itinerary records the route plan. The risk assessment records route hazards, accessibility notes, weather plan, emergency meeting point and mitigations. The aim is not to over-process a small photo walk, but to make the obvious safety responsibilities visible and reviewable.

Camerawalk is adult-only for the MVP. Age verification is visual only and stores minimal confirmation metadata rather than copies of identity documents.

Booking and Payment

Participants must be logged in to book. The booking flow preserves intent so a visitor who clicks Book is returned to the booking path after login or signup rather than being dumped into a dashboard.

Stripe Checkout is used for payment, with webhook confirmation treated as the source of truth. The success URL is only a status page and does not mark a booking paid.

Money is stored as integer minor units with ISO currency codes. The MVP keeps the financial model simple: site-controlled payments, manual prize voucher issue, and manual host payout records.

The intended monetisation route is practical and modest: lead walks directly in Glasgow, and potentially take commission on walks in other places managed through the site if the model proves useful.

Photo Upload, Moderation, Voting and Results

After the walk, booked participants may upload up to three photographs.

Each photo requires a title, controlled tags, a short “why chosen” note and a licence. Photographers retain copyright while granting the platform a limited licence to host, resize, display and promote the image in connection with the walk, voting, results, archive and related promotion.

Uploads begin pending moderation. Walk hosts can approve, reject or escalate photos for their own walks, but they cannot permanently delete participant uploads. Moderation is about relevance, legality, safety, privacy and abuse prevention. It is not artistic judging.

Voting is ranked. Eligible participants select first, second and third choices. Participants cannot vote for their own photos, cannot choose the same photo more than once, and can vote only during the voting window. Votes are private.

The system calculates the top three results after voting closes. Results are published only when ready. Top-ranked images may form part of the public archive.

Privacy and Contact Windows

Camerawalk deliberately limits personal data exposure.

Participant mobile numbers are optional at booking. If supplied, they may support walk-day contact, but booking and payment do not depend on them.

Walk leaders may see participant mobile numbers only for their own walks and only during a defined contact window, normally from 48 hours before the walk to 48 hours after expected finish. Participants may see leader contact details during the same operational window.

Public pages must not expose email addresses, mobile numbers, private bookings, payment status, votes cast, age verification, private moderation notes, host emergency contacts or private AI feedback.

Agentic Development and Manual Verification

Camerawalk was built agentically using formal repository guidance: AGENTS.md, FUNCTIONAL_SPEC.md, BACKLOG.md, and later supporting project documents.

That structure mattered. The codebase grew quickly, and the guidance files helped keep product policy, scope, safety, booking, privacy, payment, moderation and voting rules from being quietly reinvented by each coding session.

The growth in codebase size also increased the need for manual browser testing. AI-generated or AI-assisted tests were useful, but they did not always identify real workflow problems, awkward screens, missing links, or integration failures. The lesson was blunt: AI can accelerate implementation, but real systems still need to be driven through real user paths.

What Was Deliberately Not Built

Camerawalk deliberately defers features that would distract from the first real pilot:

These omissions protect the pilot. The next phase is running the first real walk rather than extending the feature set.

Summary

Camerawalk is a full-stack Django platform for running small local photography walks from listing through to public results. Its core functionality is implemented and tested, with final visual polish still being completed before the first real Glasgow walk.

It demonstrates:

The central argument is that a small community event platform still needs clear lifecycle state, explicit permissions, privacy boundaries, payment truth, safe publication, auditable decisions and enough restraint not to build a social network before the first walk has happened.