What participants post publicly
No polished testimonial deck, just real posts published right after the hackathons.
The posts are loaded from LinkedIn, which may process data and set cookies of its own. They only load once you request them here.
The skills gap this closes
Most teams do not have an AI knowledge gap any more. They have a fluency gap. People have read the headlines, a few sat through a webinar, and yet the weekly work looks exactly like it did a year ago. That gap has four concrete causes, and none of them yields to another slide deck.
Practice never happens. A course shows a clean example prompt. The messy, real work case, the one with edge cases and sensitive context, never gets touched, so the skill has nothing to attach to.
Confidence stays low. People who have not shipped anything with a tool quietly avoid it. Avoidance reads as resistance, but it is really a missing first win.
The stack is a blur. Employees hear ten tool names and cannot tell which one fits their task. Choice paralysis keeps them on the old workflow.
Nothing carries over to Monday. Without an artifact they own, the week fades. There is no reporting bot, no automation, no draft assistant left running to reinforce the habit.
Upskilling that sticks reverses the order. Instead of learning first and maybe applying later, your team builds on a live case from hour one, and the fluency forms in the building.
Goals of the upskilling sprint
The aim is not a good feeling on Friday. The aim is that your people work visibly differently the following week and keep choosing AI tools on their own.
A working artifact each team owns and keeps running, so the new habit has something to reinforce it.
Practical fluency that formed on a real case, which is why it survives a busy week.
A documented internal AI literacy measure, useful as a building block toward EU AI Act Article 4.
A clear read on which tool fits which task, so people stop waiting for a central expert to choose for them.
What the programme entails
An upskilling hackathon is a guided work sprint for teams who cannot and do not need to code. Participants work with Cursor, Lovable, n8n, Gamma, Figma Make, Claude Code, Custom GPTs and NotebookLM on their own data. Facilitators keep the focus on one tightly framed problem per team so a usable result exists at the end and the learning has a spine.
A typical sprint has four interlocking parts:
- Challenge scoping. Each group gets a real, narrow use case with a named user and a desired output, for example turning a weekly manual report into an automated draft, rather than a vague brief to "try AI".
- Tool workshop. Before building, each group learns exactly the tools its challenge needs. Not a tool zoo, the right stack for the case.
- Build phase. Teams build with a facilitator beside them, unblocking, showing the next step and holding the boundary of the prototype clear.
- Pitch and handoff. Each team demonstrates its result, names open risks and assumptions, and hands the artifact to an owner with a next step, so the fluency has somewhere to live.
Deliverables
Pre-scoping with a per-team challenge design.
A curated tool stack per challenge, including access.
A facilitated build sprint with a coach present throughout.
At least one working prototype per team (automation, dashboard, Custom GPT, app prototype or workflow).
A skills library that records the prompts, patterns and workflows the team built, so others can reuse them.
A handoff document per prototype with owner, access, open risks, acceptance criterion and next step.
Documentation of the AI literacy measure for participants.
Who it fits, and who it does not
Honest fit saves both sides time. Upskilling by building is the stronger lever when these points hold. When they do not, we say so.
| Good fit when | Not a fit when |
|---|---|
| a team has real recurring friction (manual reports, slow replies, scattered knowledge) to practise on | you only want broad AI awareness delivered to a large plenary |
| someone will keep using and improving the artifact after the sprint | no one can take ownership once the week ends |
| data and tool access can be approved in principle | real data cannot be touched for legal reasons under any circumstances |
| you want fluency you can see in the work, not just a completion badge | a certificate without application is genuinely enough for your goal |
Classroom AI course vs upskilling hackathon
| Criterion | Classroom AI course or e-learning | AI Hackathons upskilling hackathon |
|---|---|---|
| Output | certificate or completion badge | a working prototype your team built and keeps |
| Skill retention | unclear without transfer measurement | visible through the artifact, its usage and the handoff |
| What people practise on | generic example tasks | your own real work case |
| Tool choice confidence | still theoretical afterwards | tested against a live task, so people can pick the right tool |
| Proof of value | hard to show | a tangible artifact as the starting point for your own measurement |
| Time to first result | weeks to months | ready to start in one week, outcome depends on scope |
The table compares ways of working, not vendors, and deliberately carries no invented percentages. Reliable figures only come from your own baseline. A hundred people who can actually build with the tools get more done than a thousand who only watched a demo, which is why we measure upskilling by output and adoption, not attendance.
How the value can add up (a model, not a client number)
An honest view of the payback uses your own figures, never a borrowed case number. The model has three inputs and one formula.
Weekly time a person spends on one recurring manual task, say report assembly.
The share a prototype realistically removes.
Internal hourly rate times the number of people affected.
Formula: hours saved per week × hourly rate × 45 working weeks × people − the one-off cost of the sprint and the rebuild weeks. Put your own numbers in. As an illustrative model only: if report assembly costs each person three hours a week and a working draft-bot removes two of them, that is two hours across, say, eight people over a year, an order of magnitude you can weigh the investment against honestly. We run exactly this in the discovery call with your real numbers, not ours.
Interactive calculator: /tools/ai-enablement-readiness/.
Does this match your team? Decide with a person, or read first.
The one-week path, as an animated timeline
| # | Step | Owner | Output |
|---|---|---|---|
| 1 | Intro call | AI Hackathons + sponsor | agreed goal, rough scope, date |
| 2 | Tools and challenges call | AI Hackathons + team leads | tailored challenges, tool stack chosen per challenge |
| 3 | Finalise info and data | Client (IT, privacy) | approved data access, documented boundaries |
| 4 | Hackathon prep | AI Hackathons | prepared environments, access, run of show |
| 5 | Tool workshop | AI Hackathons + teams | every participant can operate their stack |
| 6 | Hackathon sprint | Teams (coached) | working prototypes, fluency formed on a real case |
| 7 | Pitches and handoff | Teams + owner | shown results, handoff documents, a skills library, next steps |
Social proof
Teams from Adobe, YOYABA, Onventis and NavVis have worked with us.
See the case studies
Book a discovery call