Comidas Bracamonte

Context

Comidas Bracamonte is an established food-service business in Spain that needed to bring a fragmented offline operation into a single online platform.

Before the project, the business already had a WordPress landing page and a separate PHP-based system for managing dishes. Customer-facing information, menu management, and operational workflows lived in different places and were difficult to keep synchronized.

The goal was to create one platform where customers could understand the service, configure a subscription, select their meals, complete payment, and where the business could manage the rules behind that experience from a central administration interface.

My role

I developed the platform end to end between November 2024 and February 2026.

My work covered the customer-facing application, CMS architecture, business rules, menu and subscription flows, geographic pricing, checkout and payment integration, administrative workflows, SEO, deployment, and ongoing maintenance.

The application was built with Next.js and Strapi and deployed as a production system for the business.

The challenge

The main challenge was not simply putting a menu online.

Comidas Bracamonte runs a subscription-based meal service where the customer's location affects pricing, availability, and the meal-selection experience.

The first version of the geographic model was based largely on Spanish provinces. That eventually proved too broad for the way the business actually operates.

A town close to the service base can belong to a different province, while two locations inside the same province may have very different delivery conditions.

The geographic rules therefore evolved from province-based logic toward postal-code-based configuration.

This allowed the platform to model service areas according to actual proximity and operational requirements rather than relying only on administrative boundaries.

Subscription and menu flow

The customer journey begins with a postal code.

That location is used to determine the rules and pricing that apply to the customer.

The customer then selects either five or seven services per week. The combination of service frequency and postal code determines the subscription price.

From there, the customer chooses meals from the dishes available for that location and configures their menu across a five-week cycle.

Once the menu is complete, the customer proceeds through checkout and pays for the monthly subscription in advance.

The subscription logic also supports adjustments for the first month when a customer starts partway through a service period, as well as refund calculations when a cancellation requires money to be returned.

Postal-code pricing

One of the important changes during the project was redesigning how geographic pricing was represented.

Rather than maintaining a separate complete price configuration for every postal code, I implemented a default price with explicit exceptions for locations that required different pricing.

This allowed the business to apply discounts or other price variations to specific nearby areas without duplicating the entire pricing model.

The rules remain manageable from the administration interface, so routine changes do not require modifying application code or deploying a new version.

Recommended menus

Selecting meals individually across several weeks can involve a large number of choices.

To reduce that friction, I developed a custom Strapi plugin that allows the business to prepare recommended meal sets for one or more postal codes.

The business can configure weekly combinations based on the dishes it wants to recommend for those locations, including combinations informed by what sells well.

When a customer selects Use recommended, the application preloads the configured meals across the menu cycle instead of requiring every week and meal to be selected manually.

The recommendation logic remains controlled by the business through the CMS rather than being hardcoded into the frontend.

CMS-first administration

A major architectural goal was to give the business direct control over as much of the product configuration as practical.

Where possible, business rules and operational content were modeled in Strapi rather than embedded directly in application code.

The administration interface allows the client to manage areas such as dishes, menus, recommendations, coupons, geographic pricing exceptions, and other content used throughout the purchase flow.

Administrative restrictions and validation were also applied to help protect the integrity of the underlying data.

This approach lets the business make routine operational changes without depending on developer intervention.

Payments

The checkout integrates Redsys for online payments.

Customers can complete payment using card or Bizum.

Bank transfer is also supported as an alternative flow. The order is coordinated through the website, while predefined WhatsApp communication provides the customer with the information required to complete the transfer externally.

The final amount reflects the customer's location, selected weekly service frequency, subscription rules, and applicable pricing configuration.

Connecting checkout to kitchen operations

The platform also needed to bridge the online purchase flow with the physical preparation of meals.

After the customer's menu and order are completed, the system generates a PDF containing the selected meals.

That document is provided to the kitchen service provider and becomes part of the operational workflow used to prepare the customer's food.

This allowed the digital flow to continue beyond checkout and produce information directly usable by the fulfillment side of the business.

Technical decisions

Several architectural decisions were shaped by the need to keep the system maintainable while giving the client operational independence.

Moving from provinces to postal codes aligned geographic rules more closely with how the service actually works.

Using a default price with explicit exceptions reduced redundant pricing configuration while still supporting local variations.

Keeping menus, recommendations, pricing rules, and other operational content inside Strapi made those workflows editable without requiring code changes.

The custom recommendation plugin extended the CMS specifically for the client's workflow instead of forcing that process into generic content-management screens or hardcoded frontend logic.

Result

The completed platform brought previously disconnected customer and operational workflows into a single production application.

Customers can move through postal-code validation, subscription configuration, meal selection, payment, and order generation as one connected process.

The business can independently manage menus, dishes, recommendations, coupons, geographic pricing exceptions, and related configuration through its administration interface.

I continued maintaining the application after its initial delivery. The final maintenance update in February 2026 added JSON-LD structured data to improve the site's machine-readable SEO metadata.