Picasso: a photography studio website and booking project

Picasso, also known as Gorod Picasso, is a photography studio project for which CoreWeb delivered the complete website scope: business scenarios, design, frontend, booking backend, CRM work, analytics, domain, hosting and launch setup.

The central task was to connect the choice of a studio room with booking time for it. This case study describes CoreWeb’s work, confirmed by a member of the development team. It is our account of the project, not an independent customer testimonial.

The task: present spaces and a booking route

The Gorod Picasso website links to studio and booking-calendar sections. The saved public catalogue shown below presents room photos, names, floor areas and starting rental prices, together with detail and booking links. These images describe the interface at the date in their captions; they do not verify the current room list or prices.

The structure supports two stages of a visitor’s decision: comparing spaces and moving towards a booking. This is the scenario shown in the saved public material, not evidence that a reservation has been completed.

A catalogue built around the choice of space

Room photographs are a substantial part of the offer. In the saved catalogue, the image sits alongside information a visitor can use to compare spaces before opening the details. Consistent names, images and descriptions help the visitor recognize a room between steps.

Public catalogue screenshot, dated 15 October 2026 by the existing case-study caption. Rooms and rental prices may change; consult the studio for current terms. These are rental prices, not CoreWeb development fees.

The booking interface

The saved booking screen presents three stages: choose a room, choose a time and complete the booking details. The sequence reflects a dependency: the resource is chosen before a time for that resource.

The existing RU case study dates this screenshot to 15 October 2026. It shows the public selection interface without creating a reservation. It does not establish current availability or a successful payment or booking.

How the room, date and interval fit together

The public booking calendar asks visitors to choose a room, then a time, before continuing to booking details. Before a room is selected, it asks the visitor to identify the resource. This is an observed sequence of screens, not proof that a particular time is available.

For someone planning a similar website, the relationship is:

1. Room: identifies the resource. Images and details support the choice, while the underlying data needs a stable link to that particular room.
2. Date and interval: define when the resource is needed. The same room at different times represents different choices; a calendar date without a start and end is insufficient.
3. Booking result: describes the state of the reservation. Selecting an interval on screen does not establish that the operation has completed.

In the inspected backend version, a booking links the room identifier to the start and end of an interval. The code checks time boundaries and searches for overlaps for that room. This establishes that those rules exist in the retained implementation. It does not establish the current production version, the outcome of simultaneous requests or actual calendar occupancy.

Booking status and payment status are separate

The model represents booking and payment states separately. Reaching checkout therefore does not mean that payment has succeeded, and a displayed interval is not necessarily a confirmed reservation. The inspected code also stores a price snapshot with the booking, rather than relying solely on the current price shown in a catalogue card.

For a new project, agree which states visitors and staff see, who changes them, which events trigger changes and how pending, cancelled or partly paid bookings appear. These planning questions do not replace Picasso's own commercial rules, and this case study does not verify payment execution.

What to check when a selection changes

The following are acceptance criteria for a similar project, not results of operations performed at the live studio:

• When the room changes, recheck the selected time for the new resource. Room labels, parameters and the final selection must stay consistent between screens.
• When the date changes, retain clear context and avoid presenting an unavailable or stale interval as confirmed. Define the time zone and duration boundaries separately.
• Before completion, check that the choice is still valid. Test concurrent requests and failure handling in an agreed test environment; an overlap check in source code does not replace that test.
• If a response is lost, give the visitor a way to check the result instead of unconditionally asking them to create another booking. Agree retry behaviour with the server process.
• Staff should be able to reconcile the resource, interval, price breakdown and states. A confirmation screen, a stored booking and a payment are separate results to verify.

The public interface shows the selection journey; source code shows the model and intended checks. Testing the running system requires its own agreed scenario. This case study did not create bookings, cancellations or payments. For your own project, record these relationships, unknown business rules and verifiable outcomes in the scope before implementation.

Backend and CRM scope

CoreWeb worked on the frontend, booking backend and CRM. That scope is confirmed by a member of the development team. A retained backend repository associated with the Picasso domain also contains booking, payment, notification and fiscal modules. This is evidence of implementation, not proof that every operation currently works in the running business.

The existence of an implementation and an operational check of every integration are different kinds of evidence. We did not create real bookings, make customer payments or inspect private business operations. The current state of each integration is not established here.

For a similar project, the public interface and server processes need to be considered together, while the integration list, external providers and acceptance criteria are agreed for that particular business.

Business scenarios, analytics and launch

Our scope included business-scenario planning, analytics and metrics, along with domain, hosting and technical launch setup. For a catalogue and booking project, useful measurement begins with the visitor’s decisions and the business rules behind them.

The presence of a website and analytics does not establish revenue or room-occupancy growth. Such a conclusion would need separate, comparable outcome data. This case study does not publish a conversion, sales or occupancy uplift figure.

Evidence and limits

The saved screens let a reader examine the room presentation and the initial booking interface. CoreWeb’s attributed contribution also includes the backend, CRM, business scenarios, analytics and launch infrastructure.

The existing RU case study dates both screenshots to 15 October 2026. They show a public version that may differ from both the original delivery and the current website. On 29 October 2026, a read-only browser check confirmed that selecting a room opens its calendar. The check stopped before choosing a time slot or submitting a booking. It did not establish the current room list, prices, free time slots or successful payment.

No personal customer information, private CRM screens or internal business reports are published. Project budget, development duration and acceptance date are not provided. No customer quotation or invented outcome figure replaces those unknowns.

Planning a booking website

Describe what is booked, how time slots and duration are defined, who manages availability and what should happen after checkout. Specify cancellation rules, whether payment is needed and which external systems are involved. These are planning questions for a similar project, not statements about Picasso’s particular commercial terms.

Read about CoreWeb’s website development scope, or describe your project. Scope, timing and terms are agreed individually; sales and support are available in Russian and English.