Ecommerce for a new business line of Poland's largest catering company

Kuchnia Vikinga is the leader of Poland's box-diet catering market and one of the fastest-growing food companies in the country.

Nearly 300,000 meals a day come out of its kitchens, carried by 2,000+ employees, reaching over 50,000 Polish towns, and delivering 70,000+ orders every day.

Revenue has grown at a 96% compound annual rate since 2021, reaching 160 million+ EUR in 2025. Kuchnia Vikinga is targeting 190 million+ EUR this year, and 230 million+ EUR across the group. Forbes valued the company at 330 million+ EUR in March 2026, up 273% in a year.

Their ambition goes beyond being the biggest box-diet company. Kuchnia Vikinga is building a food brand that reaches the customer wherever the customer eats, with expansion into the Baltics and the Czech Republic, and a series of new consumer business lines launching alongside the core operation. Party Box is the first of many.

Kuchnia Vikinga wanted us to develop the commerce foundation that every new consumer business line would launch on. Party Box was the first one due.

That brief set the difficulty. The foundation had to introduce a product category that was sold in a handful of cities in Poland, and make it work nationwide, including enforcing a production calendar that changes by weekday and by postcode, and stay general enough for the business lines queued behind it.

All three at once, on a stack new to the client, inside a 10-week estimate.

The starting point was a clickable prototype the client had generated in an AI tool. It showed the idea, but carried no production code, data model, design system, or delivery logic.

A product nobody had sold nationwide in Poland

A Party Box is a large tray of ready-made event food, ordered to a home or an office. This product category existed only locally in Poland. Kuchnia Vikinga is opening the category nationwide to 92% of the Polish population, and it intends to be the number one platform for event catering in Poland before anyone else notices the category is there.

That put the entire burden of explanation on the platform. There was no competing benchmark to take conventions from. The product logic had to establish the object before it could sell it: physical size, how many people it feeds, and the occasion it is for.

Those attributes are what the purchase decision runs on, so the logic had to carry them from the product page through to the delivery step, where the customer needs to know what is arriving at the door.

One engine for several business lines

Kuchnia Vikinga is opening new consumer business lines beyond its core catering operation. The projects are commercially independent, with their own brands, customers, and unit economics, and the company wanted all of them on one engine.

That set the bar for the first build. Party Box had to ship as a finished product and work as the foundation the lines after it would sit on. A build scoped to Party Box alone would have meant paying for the same commerce core again with every launch.

A delivery area of 50,000+ towns

Party Box's courier coverage runs to over 50,000 Polish towns. This list is refreshed roughly every two weeks as routes change, and the platform has to validate a customer's address against the current version.

That ruled out hard-coding the coverage area, and it made the address field one of the highest-stakes elements on the site. Kuchnia Vikinga reaches 92% of the Polish population, which is the strongest selling point Party Box has.

A platform that cannot answer that question the moment someone types their address loses a customer it could have served. If the site confirms a town that is no longer on a route, the customer pays for food that will never be made, and finds out days later with an event already planned around it. For a product most of the country has never been able to order, that failure is the first impression it leaves.

Delivery rules that change by weekday and location

Every order carries a minimum lead time of two days or more, but the exact cut-off moves depending on the day of the week and where the order is going, with separate exceptions for weekends and blackout days when the kitchen does not dispatch.

The cut-off also has to hold at the moment of payment. A customer can put a valid delivery date in the cart, spend twenty minutes choosing boxes, and try to pay after the window for that date has closed. Validating once, at the point of selection, leaves a gap where the platform sells a date the kitchen cannot cook.

For a company producing 300,000 meals a day, that gap is not a UX detail. Every accepted order enters a production plan and a route plan. An order the kitchen cannot make is a refund, a phone call, and a customer whose event food never arrives.

Two fulfilment routes in one checkout

Party Box ships two ways: nationwide courier delivery, and pickup at one of 20+ Viking Point locations. The two routes have different availability rules, cut-offs, and information requirements.

Both routes had to run through one checkout. A customer decides how to collect the box while they are picking a date, and the two routes offer different dates, so the choice only makes sense once both sets of dates are on screen in front of them. Splitting them into two flows would force the decision first, before the customer can see what either route can do.

Courier delivery brought a requirement most eCommerce checkouts never have. The boxes are bulky and unrefrigerated, so the customer has to supply an intercom or entry code during checkout. The delivery experience also had to set expectations about the size of what was arriving.

We designed and built the commerce engine Party Box runs on, and that the business lines behind it will run on.

The work covered the full lifecycle: discovery and feature specification, the data model and system architecture, wireframes and a complete design system built from the brand book, the storefront, the backend, eight external integrations, automated end-to-end test coverage, and deployment.

The 10-week estimate was not a realistic number for this scope. A stack nobody on the client's side had worked with, a prototype with no production code behind it, a delivery model no commerce platform ships with, and a fixed date at the end of it. On a conventional agency process, the question would have been how far past that date we landed.

We delivered in 8 weeks thanks to Canso, our AI-native delivery framework that no other agency in this market has.

Canso moves a project through three governed phases with eight approval gates between them, and no code is written against a specification a human has not signed off.

Discovery came first. We took the client's brief, its sales materials and the prototype, and turned them into feature specifications, a data model and a complete system architecture. AI drafted each specification and scored its own confidence in it, so anything ambiguous was flagged and resolved with the client. Nothing entered the build queue until the specification behind it was approved.

Then design, in one pass. We ran an on-site design workshop with the client's team, then built the entire frontend against mock data: every page, every state, and a full design system derived from a brand book that supplied a logo and colours.

Development ran to a daily standup with the client's team. Our experts built the backend modules against the approved specifications, the eight integrations were wired one at a time as each provider cleared its own compliance process, and end-to-end tests were written for every critical path before the code that had to pass them.

Medusa as commerce foundation for several business lines

We built Party Box as the first new business line on Medusa, which runs the commerce engine: catalogue, product pages, cart, checkout, customer accounts, order history, promotions, and the admin panel.

With Medusa, Kuchnia Vikinga owns the code, pays no licence fee, and takes no cut of each transaction, because it is open-source.

Without a shared engine, every new business line would be a new build from scratch, which means months of development and tens of thousands of euros spent before that line sells anything. Time is an even bigger saving. The next line only needs its own products and way of getting food to the customer, so it reaches the market in weeks.

Adding new business lines does not add overhead. The team who set cut-offs and take phone orders for Party Box do the same work for the next line, in the same panel, so no extra headcount is needed to run it. And when something is fixed or improved, every line gets it, so a single maintenance budget covers the whole business.

Custom features in detail

Delivery cut-off and blackout-day engine

We built a cut-off engine the client configures per weekday from the admin panel, along with the days the kitchen is closed and no food goes out. The engine re-validates at checkout, immediately before payment, so a cart holding a delivery date whose window has closed gets caught at that point.

This gives the operations team control of its own calendar. A change to the production plan reaches the shop immediately, without paying for developer time or waiting for a release. Speed matters here, because a kitchen closure that takes two days to show up on the website is two days of orders that have to be cancelled and refunded.

Two fulfilment routes in one checkout

A single selector handles both routes. Nationwide delivery collects the entry code needed for courier drop-off as a required field, and pickup routes the customer through Viking Point selection instead. Each route applies its own availability rules, so the dates a customer sees always match the route they picked.

The customer never has to understand that two different sets of rules sit behind the choice. Kuchnia Vikinga gets both channels selling through one flow it maintains once, and the Viking Point network turns from a collection of physical locations into a second revenue route for Party Box.

Delivery-area validation across 50,000+ towns

Address entry runs as a searchable autocomplete over the live list of served towns. The client refreshes that list by uploading a CSV in the admin panel, which takes effect without a deployment. Coverage is checked against the current dataset during checkout.

Kuchnia Vikinga can sell into its whole delivery area with confidence. A customer in a small town gets an answer while typing the address, so those who can be served place the order and those who cannot find out before they pay.

Operations keep the list current as routes change, without booking developer time. Every day that list is out of date is a day of orders taken for towns no route covers, refunded later at the company's cost.

Two-step checkout with a direct payment redirect

We collapsed checkout into two steps: delivery details, then a direct redirect into the payment gateway. Customers reach the payment screen one step sooner, and that is one less place to abandon a cart.

The payment-method selection step came out of the flow entirely, because the gateway already presents the methods on its own screen.

Dual identity scheme for business and consumer orders

We implemented separate identifier prefixes across the platform. The distinction holds from the storefront through the admin panel into every export.

Finance issues the right document every time: a VAT invoice for a company and a receipt for a consumer, with nothing to sort by hand at month-end. Kuchnia Vikinga also reads business and consumer sales as two separate revenue lines from the first day of trading, so it can see which one is growing.

Draft orders with payment by link

Not every order starts on the website. We built a draft-order flow so the customer service team can assemble an order on a caller's behalf in the admin panel and email them a payment link to complete it.

Kuchnia Vikinga keeps the sales it would otherwise lose to a caterer who takes orders over the phone. The customer service team works in the same admin panel as everyone else, so there is no call-centre system to buy and keep matching the shop.

B2B registration with GUS company registry autofill

Business customers register by entering a NIP tax number. We integrated the GUS API, the Polish company registry, so company details are filled in automatically from that number.

A business buys as easily as a consumer. Registration takes one number, so an office manager never has to leave the checkout to go and find the company's legal name and registered address, which is the point where a corporate order gets postponed and forgotten. The details arrive from the registry, so the invoice is right the first time.

Enova export for accounting

A CSV and Excel report of paid orders is built into the Medusa admin panel. The client's accounting team uses it to issue invoices and receipts in Enova, their accounting system.

ING Pay for payments

ING Pay is the payment gateway behind the store, covering BLIK, card payments, and PayPo deferred payment. Card and wallet methods stayed gated behind the provider's own compliance process, so the integration was built to work as each method was released.

Hosting, monitoring, and transactional email

Medusa Cloud hosts the backend, Vercel hosts the frontend, and AWS S3 stores product images and assets. Kuchnia Vikinga controls what the platform costs and can change the plan or move to a different provider.

The rest of the setup is there to keep the shop selling. Sentry handles error monitoring and logging, and Resend delivers transactional email.

Errors are reported to the team the moment they happen, so a broken checkout is caught when it has cost one order and not a morning of them. The hosting grows with the traffic on its own, so a campaign or a busy week before a holiday does not bring the site down.

Party Box has been live and selling nationwide since July 2026. Kuchnia Vikinga opened a new nationwide consumer business line, in a product category that had only ever been served city by city, without pausing an operation that produces 300,000 meals a day.

The company brought the product idea, the kitchens, and the delivery network. We built everything that turns those into sales: the product logic for a box nobody had sold nationwide before, the delivery engine that holds every order to the production plan, the coverage check across 50,000 towns, and the invoicing that lets a company buy as easily as a consumer.

The platform was delivered 20% faster than planned, and Kuchnia Vikinga owns all of it outright.

New business line in 8 weeks against a timeline the market treats as impossible

A commerce platform with these requirements takes six to eight months of development at a conventional agency, where the specification is written by hand over weeks of workshops, the design is still being argued about while development runs, and every change to the frontend sends the backend back for rework.

The estimate here was 10 weeks, but we delivered it in 8. The difference is Canso, the AI-native delivery framework we built and run every project on, that no other agency in this market provides.

The next business line launches in a fraction of the time

The platform was built to carry more than Party Box. Kuchnia Vikinga's next consumer line begins with the catalogue model, checkout, delivery logic, and admin already in place, on the engine Party Box runs on today. None of that has to be specified, built, tested, or put through compliance a second time.

A commerce build of this kind takes months of development before a single order is taken, and Kuchnia Vikinga did that only once. The next line is scoped only around what makes it different, which brings it to market in weeks, and it lands in the same admin panel the team uses today.

Company data entry reduced to one number

Business customers enter a NIP tax number, and the rest of the company record fills in from the Polish company registry. Registration collects one number, and the legal name, address, and registration details arrive with it.

Order channels increased

The customer service team builds phone and email orders in the same admin panel and sends a payment link to complete them.

Those orders land in the same stream as online ones, so there is one set of records to reconcile and no second tool to license or keep in sync with the shop.