Before any code, every project starts with a proposal — what are we building, for whom, and why is it worth doing? This is the project brief for our biggest AIDA (AI-drevne applikationer) project: a digital system for the Christmas market at Engestofte Gods. A classmate and I built it together; this post is the “before” picture.
The Problem#
The market has a real organizer, Lise, and a very manual process. Vendors — stadeholdere — apply to get a stand, and today that happens over e-mail. Lise reads each application, decides what kind of vendor it is, keeps track of who’s approved, and works out where everyone stands on the day. The following year, she starts more or less from scratch.
Two things stood out as the actual pain:
- It’s manual and time-consuming. Categorizing applications, keeping a list, and laying out the floor plan are all done by hand.
- It has no memory. There’s no record that ties this year’s vendor to last year’s — no easy way to see “we placed them here last time, and here’s the note about their stand.” The knowledge lives in Lise’s head.
The Proposed Solution#
The proposal was to replace the e-mail-and-memory process with one connected system:
- A digital application form so vendors apply through a real form instead of free-text e-mail.
- AI categorization of each incoming application into a consistent set of categories, so Lise doesn’t have to sort them by hand — with a plain keyword-based fallback when there’s no API key.
- A public, visitor-facing vendor list that’s browsable by area and building first, so guests can find stands by where they are rather than digging through a flat list.
- An admin dashboard for Lise with the thing that’s missing today: year-over-year memory. A vendor is treated as a permanent entity, and their notes, photos, and stand placements accumulate across markets.
- A drag-and-drop floor plan for laying out stands visually instead of on paper.
- Voice notes Lise can record and have transcribed, attached to the right vendor.
The system is the kind of thing that’s small enough for two students to actually finish, but real enough to solve a genuine workflow — which was exactly the goal for the assignment.
Who It’s For#
The primary user is Lise, the organizer — she’s the one whose work the dashboard replaces. The secondary users are the market’s visitors, who get a cleaner, location-first way to see who’s attending. The vendors themselves benefit indirectly from a smoother application process.
The Value#
If it were realized, the payoff for the organizer is concrete: less time spent sorting and laying out, and — for the first time — institutional memory. When a vendor reapplies, last year’s category, notes, and placement are right there instead of forgotten. Faster categorization, faster placement, and a record that survives from one year to the next.
Scope and Assumptions#
A proposal is as much about what you don’t build as what you do. The project rests on a few assumptions:
- Vendors recur year to year — which is what makes the memory feature worth building. (If every vendor were new, there’d be nothing to remember.)
- The content is Danish, and there’s one organizer, so a single shared admin key is enough for now rather than a full login system.
- It runs locally for the demo; hosting was a deliberate non-goal.
Consciously left out of scope: real user authentication, payments, multi-tenant SaaS, and hosting. These were cut not because they’re hard but because none of them were the point — the value is in the memory and the AI-assisted workflow, and adding accounts or billing would have been speculative work for a single-client demo.
How We Split the Work#
This was a two-person build with a clean division. My classmate owned the public side — the Christmas-market website, the application form, the e-mail handling, and the visitor list, including following up with previous years’ vendors. My half was the admin dashboard and all the AI features on top of it: the data model, the floor plan, the voice notes, and the layer of AI that categorizes, summarizes, suggests placements, and extracts structure from speech.
The detailed write-up of how it actually got built — and what I’d change — is in the project progress post. The code is on GitHub.