from capstone project to real-world impact: aelo swiss academy alumni reflect

Every spring, the last two weeks of the programme at AELO Swiss Academy get loud. Corridors fill with borrowed projectors, half-panicked rehearsals, and students arguing about whether a chart needs one more axis. It's capstone season. I've sat through enough of these presentations, first as a nervous participant and later on the jury side, AELO to know the question that hangs over every single one of them, even when nobody says it out loud: does any of this actually survive contact with the real world?

For years our honest answer was "we hope so". We had anecdotes, the occasional LinkedIn update, a startup here and there. What we didn't have was a proper look back. So a few months ago we tracked down eight alumni from the past three cohorts and asked them a blunt question: what actually happened to your capstone?

Their answers were messier than any brochure version of the story, and a lot more useful.

most projects don't launch. they land somewhere else

The first thing that struck us: almost nobody described their capstone as a straight line from presentation to impact. The projects that "made it" rarely looked like it from the outside. They bent, shrank, changed shape, or died in one form and came back in another.

Marta, who finished two years ago, built her capstone around cold-chain logistics for small Swiss food producers. On paper it was a mapping exercise. In practice, she spent six months driving to dairies and village cooperatives, drinking enormous amounts of coffee, and writing down where product got lost between the farm and the shelf. She interviewed 23 producers in total. Her final deck was fine. The deck was never the point.

"One of the producers basically hired me before I'd graduated," she told us. "Part-time at first, fixing the exact problem I'd spent months poking at. Three years later I run logistics for a cooperative of around 40 producers. People assume the project launched something. It didn't. It proved to one employer that I could be useful. That turned out to be enough."

Jonas's story is the one we now quote back to current students the most. He built a small network of water-quality sensors for a mountain catchment area, 14 units in all, and deployed them in September with complete confidence. Nine survived the first winter. The rest froze, flooded, or quietly went offline while he was writing his report about how well everything was going.

"It was embarrassing," he says, laughing about it now. "My presentation showed beautiful live data. Half those sensors were already dead and I didn't know it yet." He graduated anyway, and the failure became the most valuable thing he owned. In job interviews for environmental consultancies, he talked about the nine that lived and the five that died, and what the post-mortem taught him about calibration cycles, maintenance budgets, and who actually owns environmental data. Two different firms told him the failure story was the strongest part of his candidacy. "Nobody remembers the successful project. Everybody remembers the person who can explain, calmly, why their sensors died."

the table we keep pinned in the briefing room

After those interviews, we put together a simple summary of four arcs. It hangs in the capstone briefing room now, next to the schedule.

| alumnus | the capstone | where it landed |

| --- | --- | --- |

| Marta | cold-chain mapping for small dairies | part-time fix-it job, then a full logistics role |

| Jonas | stream sensors in an alpine catchment | consultancy career; working sensors handed to a local association |

| Priya | slow-travel app for the Jura | a trail newsletter and printed guide with a local partner |

| Daniel | energy dashboard for a school campus | shelved at the school, revived at his current employer |

Four rows, four completely different trajectories. Not one of them matches the trajectory the final presentation promised. That's not a criticism of the students. It's how real projects behave.

when a project dies and still pays you back

Daniel's capstone took us longest to classify. He built an energy dashboard for a school campus, and by every technical measure it was a success. The school loved the demo. The headteacher gave a speech about it. And then it went on a shelf, because there was no budget line for running it and no staff member whose job it was to look at it. Classic.

By the narrow definition, the project failed. Daniel doesn't see it that way. When he moved into his current role at a facilities management company, the dashboard came with him, dusted off and adapted in about three weeks. The code was reusable. More importantly, the experience of building something a real organisation almost wanted taught him the questions he now asks before starting anything: who owns this, who pays for it after we leave, and what happens on a random Tuesday afternoon when it breaks?

"A capstone that dies quietly is not a wasted capstone," he told us. "It's a cheap lesson. Imagine learning that a dashboard nobody owns is worthless at your first job, on a project with a real budget and a client breathing down your neck. No thanks."

Priya's arc was the slowest burn. She pitched an app for slow travel in the Jura region, all hiking routes and farm stays and trains instead of motorways. The jury loved it. She then spent a year after graduation trying to make the app happen, and it wouldn't. Users wanted the content, not the product. The routes and the stories were the asset; the app was just the wrong container for them.

So she killed the app and started a newsletter with a local tourism association. Then a printed trail guide. It now goes out to a few thousand subscribers, and a guesthouse owner told her recently that guests arrive with her pages printed and folded in their pockets. "The capstone didn't fail," she says. "Two versions of it failed. The third one is small, but it's alive and it pays for its own printing."

the trade-offs nobody puts in the brief

One debate came up in nearly every conversation: sponsored topic versus self-picked topic. The alumni split almost evenly on which is better, which is itself informative.

Sponsored projects come with real constraints, a real contact, and usually a real deadline. That friction is gold, as long as the sponsor actually shows up. Three separate people described spending their first two months on a project whose sponsor was, in one memorable phrase, "a name on an email I never met". Self-picked projects avoid that risk but carry a different one: with no external stakeholder, it's tempting to build for the jury instead of for a user. Priya admitted she spent weeks polishing app screens that looked fantastic in a lecture hall and solved nothing for an actual hiker in the rain.

There's also the scope question, and here the veterans were ruthless. Every single person we spoke to had cut something significant, usually late, usually painfully. The ones who cut early kept their weekends. The ones who cut in week eleven delivered something fragile and remembered the semester as a blur. The advice that repeated itself, in different words from different mouths: a smaller thing that works beats a bigger thing that almost works, every time, in every context, forever.

what transferred, what didn't

We asked each alumnus the same two questions: which parts of the capstone experience turned out to matter, and which parts evaporated the week after graduation?

The answers overlapped so much we could nearly predict them by the third interview. What survived: stakeholder conversations, scoping something down to what one person can actually finish, writing a one-page summary a busy person will read, and the strange skill of continuing to work when your sponsor goes silent for three weeks. What evaporated almost immediately: the specific tech stack, the polished slide deck, and the forty-page report that exactly two people ever opened, both of them jury members.

The pattern behind it is simple and a bit deflating. The transferable part of a capstone is almost never the artefact. It's the judgment you built while making the artefact. Which is why the alumni kept steering our conversations back to moments of decision, the week they killed a feature, the day they realised their interviews contradicted their assumptions, rather than the final deliverable itself.

what we changed because of these conversations

Here's the part we didn't expect: the interviews turned into a review of our own programme. The alumni were diplomatic about it, but the same gaps kept surfacing, so we fixed what we could.

Sponsor matching now happens earlier and includes an actual meeting, because nobody should discover their sponsor's level of commitment in week three. There's a mid-project review where the explicit question is kill, pivot, or continue, and continuing without a stated reason is treated as the weakest possible answer. And every capstone, finished or abandoned, now requires a short handover document: what exists, where it lives, what it needs, who to thank. Jonas's surviving sensors went to a local hiking association with exactly that document, and three years later somebody is still reading the data on Sunday mornings.

None of these changes are dramatic. All of them came from people who had already graduated telling us, in effect, what they wished the programme had forced them to do.

a checklist for anyone choosing a capstone right now

If you're a current student staring at a blank topic proposal, here's the distilled advice from eight people who already did it:

• pick a problem with a name and a face attached, not just an interesting topic
• budget real time for the boring parts