We’ve built a webshop that runs fully on AI. Here’s what we’ve learned

Back in March, we built a webshop that runs solely on AI. It scrapes the news, finds a suitable topic, designs a T-shirt based on the report, and sells it on the webshop, all without human intervention. A first in Belgium - it even became national news, but sadly didn’t make the cut for a T-shirt. What have we learned during this project, the result of a hackathon together with Marketing AI Studio MARKOMATIC and AI consultant NXTGN? Our AI experts were happy to reflect on the experience and share their insights.

Learning 1: A solid architectural foundation is worth the time investment

Before writing a single line of code, aligning the team on the overall architecture and designing for scalability pays off enormously. A brief but focused session to agree on structure, services, and approach gives everyone a clear starting point for the rest of the development trajectory.

But from that starting point, the road to the finish line took some detours. During development, details and problems emerged that were simply not visible at the time of the initial analysis. The structure of services and agents shifts, process steps turned out to be more complex than initially thought, and integrating different services tends to surface additional logic layers or database tables that nobody had anticipated. But that’s normal. Multiple iterations are not a sign of poor preparation, but an inevitable characteristic of the building process.

Learning 2: AI introduces unnecessary complexity if you don't steer it

A recurring pattern is that AI assistants tend to add too much. With custom Terraform modules, AI implements every conceivable use case instead of optimising the configuration for our specific situation. Serverless configurations, on the other hand, include options that are already set by default, have since become outdated, or are simply incorrect. The same applies to Docker builds or code bundling, where unnecessary options make the configuration needlessly heavy. Critical review therefore remains essential. Especially, or precisely, when AI makes the first proposal. AI assistance accelerates coding considerably, but one's own expertise remains the driving force.

Learning 3: Shopify as a lever for rapid delivery

Shopify offers considerably more out-of-the-box functionality than initially expected. By making smart use of what the platform already provides, we avoided custom development where it was not needed and gained time for the things that truly matter.

Learning 4: Optimising AWS Step Functions development with native ASL

For many of our applications, we prefer serverless architectures, primarily because of their scalability and cost efficiency. This also applies to the "Is this real?" project. Part of the process is deterministic, for which we use AWS Step Functions, a pattern we regularly apply for deterministic AI workflows.

Traditionally, we use the Serverless Framework in combination with the serverless-step-functions plugin. By optimising our file structure, we have discovered that we can use Amazon States Language (ASL) directly, without an abstraction layer. This offered an important advantage: we could use the preview functionality of the AWS Toolkit for Visual Studio Code to visually design and validate our state machines before deployment.

This approach streamlined our development process considerably. We were able to iterate and validate locally, which drastically reduced the number of trial-and-error deployments. This resulted in faster development cycles and lower cloud costs during the development phase.

Learning 5: Upgrade to EventBridge Scheduler with native timezone support

The generation process of the "Is this real?" project runs daily at a fixed time. Originally, we used EventBridge scheduled events within the Serverless Framework for this. However, we later switched to EventBridge Scheduler, which offers an important advantage: native timezone support.

This means that the generation process genuinely takes place at the same time every day, regardless of the transition between summer and winter time. The scheduler automatically adjusts execution without any additional configuration, keeping the process consistent throughout the entire year.

Learning 6: Claude Code during rapid prototyping

We have been using Claude Code as a coding assistant for some time and are experiencing a significant acceleration of our development process. During the "Is this real?" project, however, we encountered a number of limitations that are relevant in similar contexts.

A concrete example: although we worked with a robust project blueprint, this was essentially an "empty starting point". Claude Code struggles to get started effectively when the initial briefing is limited, because the architecture and structure to be applied are not sufficiently defined at that stage.

We have learnt that it is essential to prepare as clear a briefing as possible in advance and, if necessary, to manually define a number of core structures before Claude Code can contribute optimally. This forms the foundation upon which the AI assistant can effectively continue to build.

This finding is less relevant in classic project contexts, where a detailed briefing is generally available. In hackathon or rapid prototyping scenarios such as "Is this real?", this preparation is, however, crucial for successful AI-assisted development.

Learning 7: Containers instead of Lambda layers for AI/Python

With AI projects in Python, we learned that it's better to reach for containers straight away and avoid Lambda layers. The reason comes down to a hard size constraint: Lambda layers are capped at 250 MB unzipped across all layers combined, whereas a Lambda container image supports up to 10 GB. AI and ML libraries (think PyTorch, Transformers, LangChain, and their transitive dependencies) routinely blow past that 250 MB ceiling before you've even added your own code. Containers give you the headroom you need, without the risk of hitting a packaging wall at the worst possible moment.

Learning 8: Task distribution is an active skill

The project proved more complex in execution than the original estimate suggested. That is not an unusual situation in itself, but in a hackathon context where time is the scarce resource, we needed to act swiftly. When it became apparent that the AI pipeline required more work than initially estimated, we redistributed tasks so that everyone could remain productive. Deliberately managing task distribution, rather than blindly assuming it will sort itself out, is a skill in its own right, particularly in a hackathon context where time pressure is high.

Learning 9: AI image generation exceeds expectations, but output consistency is the greatest challenge

The quality of contemporary image generation genuinely surprised the team. The T-shirt designs exceeded expectations over and over again, highlighting the potential this domain holds for future projects. However, the principal technical challenge was maintaining consistency in both the visual and textual output. AI is by definition not funny (it simulates humour based on patterns), but we have raised the quality threshold high enough that even a journalist from De Tijd indicated that the results were genuinely funny. That is a result we can be proud of, even if it required considerable iteration to get there.

Learning 10: Deployment issues respect no deadlines

Even during a hackathon, you can run into deployment issues, and that is precisely why they are so painful: they consume precious time that you would rather spend on further development. The lesson is not that you can always avoid them, but that you should account for them in advance within your time buffer.

Learning 11: The duration of a hackathon is too short for qualitative fine-tuning

The available time does not allow for the end result to be refined to the desired quality level. A concrete example: during the first live period, the news item selection agent generated content almost daily around Donald Trump. That pattern was not intended. On the contrary: diversity of topics is crucial for the credibility of the concept. We had to make adjustments, which demonstrates that prompting logic and content governance deserve more attention than a hackathon typically allows.

Bonus learning: Music was an unexpected productivity booster

Finally, a less technical finding: with loud Drum 'n' Bass music towards the end of the hackathon, everyone pushed just a little bit harder. Sometimes the simplest interventions are the most effective.

In conclusion

The journey from loosely stitched-together scripts to a working production pipeline was more demanding than expected, but also considerably more enjoyable. Productionising requires more discipline, structure, and perseverance than the initial vibe-coding phase — and that is precisely what makes it worthwhile.

Do you have a new challenge for us? Get in touch, we love to keep pushing boundaries!

‍