Photography businesses run on a workflow Odoo core does not natively understand: an inquiry becomes a booking with a deposit, the booking becomes a scheduled shoot with a location and gear checklist, the shoot produces hundreds of assets that move through a cull-edit-retouch pipeline, and only then does the client select images, approve proofs, and order prints or license usage. Out of the box you can bludgeon this into crm.lead, sale.order, project.task, and calendar.event, but the moment you need shoot-specific fields, deposit-vs-balance milestones, per-image selection limits, or usage-rights terms on a licensing sale, you are maintaining a fragile mess of manual stages, spreadsheet trackers, and disconnected gallery tools. There is no single object that says "this is a wedding shoot on this date, at this venue, with this package, this deposit paid, these deliverables owed, and this delivery deadline."

We build a dedicated photography suite as a proper Odoo module (or small set of modules) with its own __manifest__.py, models, security, and views — installed into your database rather than bolted on from outside. The core is a photography.shoot model (models.Model) linking the customer (res.partner), the sold package (product.template/sale.order), a shoot date and location, an assigned photographer and second shooter, and a deliverables definition. Compute fields (@api.depends) derive the balance due from the deposit and package price, days-until-delivery from the shoot date and SLA, and a live pipeline status rolled up from editing tasks. Shoot packages are configured as products so quotes, invoices, and tax flow through native Sales and Accounting untouched; deposit and balance are handled as invoicing milestones so revenue recognition stays clean. Editing work is modeled either as a dedicated photography.edit.batch model or as a tailored Project pipeline, so retouchers see a Kanban of what is culled, edited, in review, and approved. Client-facing proofing and selection are exposed through the portal / website layer with QWeb and OWL views, with per-package selection limits enforced in the model (extra selections auto-generate an upsell line). Licensing sales carry structured usage-rights fields — media, territory, duration, exclusivity — so a print sale and a commercial license are distinct, reportable order types rather than a free-text note. Security is enforced with ir.model.access.csv plus record rules so photographers see their own shoots, editors see their assigned batches, and clients only ever see their own gallery; automated actions and scheduled jobs handle balance-due reminders, delivery-deadline alerts, and proof-approval follow-ups. Everything is reachable over XML-RPC/JSON-RPC if you want to sync galleries, bookings, or delivery status with an external website, booking widget, or asset-management tool.

Because every studio's package structure, deliverables, and licensing terms differ, this is delivered build-to-order rather than as a one-click download. After a short scoping call we confirm the exact shoot types, package definitions, pipeline stages, selection rules, and portal behavior you need, agree the data model and any migrations from your current tracker, and then build, test on a staging copy of your database, and deploy to production with your team trained. Delivery is typically one working week from confirmed scope, and we target your Odoo edition and version (17.0, 18.0, or 19.0), noting where a capability leans on Enterprise (e.g. advanced Studio-style customization or certain portal features) versus what runs on Community. Pricing starts from $999 (indicative, single-company base scope); additional shoot types, deeper licensing/usage-rights logic, multi-studio or multi-company setups, external gallery/website integrations, and migrating a large back-catalogue of past shoots increase the quoted scope. You receive a fixed quote after the scoping call — the from-price is a starting point, not the final number.