ºÚÁÏÍø

Teaching robots on borrowed time.

How four Aalto master's students built a project that teaches industrial robots by demonstration, trained their AI models on a borrowed GPU available only on weekends, and discovered that finding customers can be harder than building the technology itself.

Most people assume the hardest part of building a robotics startup is robotics. For Deployable, it wasn't.

Deployable is a team of four Aalto University master's students building software that allows robots to learn tasks by watching human demonstrations rather than being manually programmed. In five months, they went from strangers entering a hackathon to training physical robot arms with AI models, winning against PhD-level teams, and confronting a challenge every technical founder eventually faces: proving that someone wants what you've built.

When Joris Köster came back ºÚÁÏÍø in January after the winter break, he saw a robotics competition online and thought: I know three people to try this with. His read on them: smart, worth betting on.

He was right. Pranish Munnangi, Paulius Ragauskas, and Clemens Marx said yes. All four are master's students at Aalto University. Joris and Paulius study robotics. Clemens and Pranish study data science. They entered the Robotics Nation Physical AI Hackathon, picked up a technology called VLAs, vision-language-action models, that none of them had used before, and beat PhD-level teams with it.

The insight behind VLAs is simple and significant: instead of programming a robot, you show it what to do and it learns. Deployable saw immediately where that could go. Most robotic automation is built for large companies with engineering teams to implement it. Small and medium-sized businesses are locked out. That gap is real and nobody was closing it.

The name is the idea in a word. Deployable.

The Thing That Shaped Everything

To train their models, they needed serious compute. They didn't have it. A professor offered her GPU workstation on one condition: weekends only.

This is a harder constraint than it sounds. Building a machine learning system requires tight feedback loops. You run something, it fails, you adjust, you run it again. When you can only do that on Saturdays and Sundays, the whole pace of learning slows down. An insight on Wednesday sits in a notebook until the weekend. A training run doesn't finish until Monday, and the workstation isn't available, so it stops.

"It shifted our work to the weekends," Clemens said. "Which made us have less free time. You're forced to spend the weekends working on the project."

They built within it because they had to. And they built anyway.

"It always comes from one kind person who helps. Most professors wouldn't do this. If she hadn't, we would never have started." — Joris

What the Grant Unlocked

Deployable applied for the Aalto University Prototyping and Validation Grant. They got the largest amount the program had given out at that time. They bought their own GPU workstation.

The speed gain was real. Training runs that stretched across an entire weekend now take hours. But Clemens pointed to something less visible and more important: "We have our own resources. We don't rely on anyone."

When you own your compute, the rhythm of work changes. You can plan across a full week. You can run something Tuesday, check it Thursday, iterate Friday. The work is no longer organized around someone else's calendar. That shift, from reactive to planned, was the real unlock.

They trained more models. They connected them to a physical robot arm. The constraint that had shaped the first months was gone, and the pace of what they could build changed with it.

What Five Months Actually Teaches You

Five months in, Deployable is refining.

The team won a hackathon with technology they had never used. They built working models on a borrowed computer two days a week. They received the largest grant the programme has given out. They trained a robot arm to learn tasks by demonstration.

And now they are doing the work of finding exactly who needs what they aim to build. They are focused on embedded systems shops and small manufacturers. They are narrowing. They are testing. They are building toward a version of Deployable that solves one specific problem for one specific customer, not a general problem for everyone.

That last part is not a setback. It is the job.

"First find the problem," Pranish says. "Validate that it exists across multiple people and companies. Only then start building. If you want to make a business, you need someone who wants to pay for it."

What makes a team capable of moving through that sequence is the thing that kept coming up when these four described each other. Not the word talent. Not the word vision. The word they kept using, in different forms, was commitment. Showing up when you are busy. Finishing what you said you would finish. Staying in it when the direction is still being worked out.

That is the part that does not show up in the demo. It is also the part that determines whether the demo ever becomes anything more.