From an NFT project to a travel product
This product was created before ChatGPT and began as a spin-off from an NFT-based project. We developed it for a customer exploring culinary travel in Poland. The engagement reached a working proof of concept rather than a production release.
Our scope included initial market research, competitive analysis, product guidance, and technical delivery. The customer led more of the go-to-market work and user research, with our guidance. This division kept commercial discovery with the customer while allowing the product and recommendation approach to respond to what the research uncovered.
The proof of concept used AWS and a custom recommendation system. It also included data extraction needed to assemble candidate places and travel information before the recommendation logic could rank them.
The itinerary problem
Culinary travel planning is more complicated than listing restaurants or attractions. A useful day-by-day plan needs to account for traveller preferences, geography, sequence, time, and practical availability. A highly rated venue is not useful when it cannot fit the route or does not match the group’s priorities.
We separated preference matching from itinerary construction. The recommendation layer identified potentially relevant culinary experiences. The planning layer then needed to arrange selected options under constraints. This distinction prevented an attractive list of places from being mistaken for a workable itinerary.
The product was built before general-purpose conversational models became a standard interface. We therefore designed recommendation logic and data extraction directly for the travel problem instead of relying on an LLM to produce a plausible-looking itinerary from free-form text.
Research changed the commercial picture
The research identified a structural issue in Polish culinary tourism at that time. Many payments and arrangements involving smaller and medium-sized providers were not represented in consistent digital records. The available transaction information was therefore incomplete or difficult to connect to a standardized platform flow.
This did not mean that the providers lacked real businesses or customer demand. It meant that a product built around fully documented digital transactions could conflict with how parts of the market actually operated. Requiring every provider to adopt a new payment or reporting process could work against the needs of the smaller companies the product intended to include.
That finding affected the business model as much as the software. A recommendation product can identify a relevant destination, but completing the transaction requires compatible booking, payment, and settlement practices. Where those practices are fragmented, the platform must either absorb operational complexity or narrow its supplier base.
Recommendation and data extraction
The custom recommendation system combined user or group preferences with extracted information about available experiences. Its purpose was to rank useful candidates and support a structured route rather than generate descriptive travel prose.
Data extraction was necessary because source information was not available in one consistent format. The proof of concept needed to turn available material into comparable inputs for recommendation logic. AWS provided the operating environment for the PoC.
The project did not reach a stage where live availability, payment completion, or every schedule constraint could be treated as a verified production capability. Recommendation relevance and operational feasibility are different questions. A place can fit a traveller’s interests while remaining difficult to book or combine with the rest of the route.
What the PoC established
The PoC established that the product could combine extracted data with a purpose-built recommendation approach for culinary travel. It also produced a more important commercial insight: the surrounding transaction infrastructure could limit the value of the application for smaller and medium-sized providers.
The decision boundary was therefore broader than algorithm quality. The customer needed to evaluate whether its go-to-market model could include providers whose operations were not fully represented in standardized digital systems. Our research and technical work made that constraint visible before a larger implementation.
Supported outcome and limits
The supported outcome is a completed customer PoC backed by research, competitive analysis, data extraction, a custom recommendation system, and AWS. The customer conducted go-to-market and user research with our guidance.
This case study does not claim a production launch, completed bookings, payment volume, active users, increased provider revenue, or verified itinerary feasibility. It also does not characterize undocumented transactions as unlawful; the documented finding concerns the lack of standardized records needed by the proposed platform.
For a related travel planning product, the practical starting point is to test the recommendation logic together with supplier data, booking practices, payment constraints, and representative routes. The custom algorithm development overview explains how matching and constraints can be evaluated before scaling.