The days before our visit to Engestofte Gods were intense. My teammate and I worked late, slept too little, and pushed hard to get a working demo ready. By the time we went to Lolland on 29 September, we had an application we could put in front of Johan and Lise.
In the project-start post, I wrote that the most exciting part would be finding out whether Johan could see himself using what we were building. This was our first chance to find out. We could finally show how the ideas from his interview looked and worked on screen.
The demo went very well. Johan and Lise seemed curious about the application and asked a lot of questions. Several were about whether it could support something in the future. In some cases, we could already open the feature and show them.
A website connected to the working application#
We had a new public website ready, with an inquiry form for customers to contact Engestofte. Behind it was a working CMS for changing content and translations, and a dashboard where staff and administrators could work.
That combination mattered. The public website was one part of the demonstration, but we could also show the places where Engestofte would maintain the content and work with the information coming in.
In the CMS, staff write in Danish and get an AI-generated draft of the English and German versions. Nothing in those languages goes live until someone has read and approved it, and if the Danish text changes later, the translations are marked as needing an update. Translation is the only place AI is part of the finished product; the rest is ordinary code.
Behind the dashboard, we could follow an event from the first inquiry to the day itself. An inquiry can be converted into an event, and each event collects its bookings, contacts, sales lines and run sheet in one place.
The work we’d divided across modules was now something we could demonstrate together. The sprint had been about getting those pieces connected well enough to show a usable application, rather than having separate features that only worked on their own.
The questions that made the demo worthwhile#
The resource calendar was one of the best examples. Johan and Lise asked about being able to see availability across the resources. We already had a calendar showing that overview.
This went straight back to the interview: rooms and holiday houses need to be considered together, especially when a wedding requires both. Today they are tracked on separate Trello boards. Seeing that in one calendar makes the idea much easier to discuss than describing a shared availability system in a document.
The table planner was a different kind of example. Engestofte hadn’t asked for it. It was an extra feature we had decided on at the start of the project, because we thought it could bring real value to their business: today a seating plan is made by hand, in Word or on paper, and redone many times before the wedding.
The couple gets a link to their own page, where they add guests, diets and allergies and build the seating plan themselves. The plan is drawn to the real room, so a table can’t be placed on a wall or in a doorway.
When we showed it, Lise asked whether she could see the guests’ allergies. We had already thought about that, and could show a list identifying which tables had guests with allergies and which people were affected.
That feature connects the guest list and seating plan to the people delivering the event. It gives the kitchen a practical view of information that otherwise needs to be found and passed on. It was satisfying to show something we’d planned specifically around that handover.
Their questions gave us a useful connection between the plan and the business. We had spent a lot of time deciding what to build; now Johan and Lise were asking about features in terms of the work they needed to do.
What I took from the visit#
The strongest lesson for me was how much better the conversation becomes when there is something working to point at. A shared calendar or allergy list is an abstract feature in a spec. On screen, Johan and Lise could ask about it, and we could show exactly what our version did.
It also gave me more confidence in starting from the interview. The availability and allergy questions lined up with problems we’d used to shape the application. That made the effort spent understanding the workflow feel worthwhile.
The way we worked together helped us reach that point. Shared grilling, written feature slices, and parallel implementation gave us a way to move several parts forward while keeping the overall plan aligned. The final sprint was demanding, but it brought those parts into a demo we were happy to show.
What stayed with me most was Johan and Lise’s curiosity. They were thinking about what the application could do for them, and we could already demonstrate some of the things they asked for. After weeks of working through specs and tickets, that was a good moment: the people we were building for could finally see the result and talk to us about it.
This is part ten of my posts on this semester’s AI-driven applications elective.