From Folding Bikes to Global Harmony: A Non-Technical Founder’s Journey to Stop Wasted Effort

It started with a simple, practical goal: to build a folding bike that could fit in a backpack. For Ryan, this wasn't just a fun engineering challenge; it was a way to help people, especially those in the suburbs, reduce their dependence on cars. But this personal project soon uncovered a much deeper, more troubling problem—one that sent him on a multi-year journey from his personal spreadsheet to hundreds of global conversations, all in search of an answer to a single, profound question: How do we stop doubling up human effort?

This is not a story about a finished product or a venture-backed startup. It’s a story about the messy, human process of identifying a systemic problem and the relentless, often lonely, work of trying to understand it. It’s for anyone who has ever felt that their hard work could have a bigger impact if only it could connect with the right people, and for those who believe that even with limited skills, they can contribute to solving the world’s biggest challenges.

The Spark: A Spreadsheet Full of Wasted Time

Ryan’s motivation was clear from the start. "I want to have high positive impact in general," he explains, "and want to make sure that the work I do benefits the most amount of people." The folding bike project was a tangible expression of this desire. To build the best possible version, he needed data—specifically, the dimensions and weights of every folding bike ever made.

He assumed this information would be readily available online. He was wrong. What followed were months of painstaking, manual research. Ryan scoured countless websites, forums, and product pages, meticulously compiling the data into a single, comprehensive spreadsheet. It was a classic case of what he calls "exhausting research."

The spreadsheet was a personal success. It gave him the information he needed to start imagining his ideal bike design. But a nagging feeling began to grow.

"I knew that having all this information be storing a digital folder staying untouched forever was inefficient for humanity. I was deeply troubled from this idea."

He tried sharing his findings, posting his data on Reddit and Quora in response to questions about the lightest folding bikes. But this felt like a small fix for a huge problem. He couldn't shake the thought that somewhere else in the world, another person was likely starting the exact same tedious research. His personal frustration had revealed a systemic flaw. The problem wasn't just about bikes; it was about duplicated human effort. This realization became the true starting point of his journey.

The Journey: From a Global Search to a Local Experiment

Armed with a new, much larger question, Ryan set out to find who else was trying to solve this problem. His journey unfolded in three distinct phases, each revealing a new layer of the challenge.

Phase 1: The Search for a Global Platform

Ryan’s initial resources were simple but effective: a basic understanding of spreadsheets and the ability to connect with people over video calls. He wasn't a programmer or a Silicon Valley insider. He was just a curious and persistent person.

He embarked on a year-long quest, conducting hundreds of video calls with people all over the world. He sought out anyone building or even just thinking about global knowledge-sharing platforms. He wasn't trying to build his own tool yet; he was trying to see if one already existed.

His investigation uncovered a startling paradox. He found many brilliant and passionate people who saw the same problem he did. They were all trying to build a tool to connect everyone and stop duplicated work. But there was a catch.

"It seemed like the consensus I found was that everyone is themselves trying to build the tool which connects everyone but the builders aren’t able to work together to find a collective solution."

The very people trying to solve the problem of collaboration were not collaborating themselves. They were working in isolation, creating yet another layer of duplicated effort. This discovery was a major turning point. The problem wasn't just technical; it was deeply human.

Phase 2: The Cohesion Summit Experiment

Realizing that a global, online-only approach was hitting a wall, Ryan shifted his focus. He decided to go local, bringing the conversation to the ground in his city, Toronto. He started talking to people at local events, sharing his idea of working together to reduce wasted effort.

This grassroots effort led to the creation of the Cohesion Summit, an in-person event series Ryan co-created with others. The goal was simple: get people in a room to share what they were working on, discover where their projects overlapped, and hopefully, inspire them to work together.

The summit was a valuable experiment. People showed up and were appreciative. However, it also surfaced the messy reality of human collaboration.

"I realized that from this event format, there were so many barriers to collaboration, ego, vibes, would people defect from a project to profit from it, etc."

The event format didn't magically solve the problem. While it created connections, Ryan found it impossible to track whether any real collaborations emerged. He spent a significant amount of his own money on venue costs without being convinced he was achieving the goal. The experience taught him a crucial lesson: simply putting people in the same room isn’t enough to overcome deep-seated barriers like ego, trust, and misaligned incentives.

Phase 3: Discovering Wikidata

Though the Cohesion Summit didn’t produce the results he hoped for, it kept him engaged in the local community. By consistently showing up to Civic Tech Toronto, a weekly meetup for people interested in technology and public good, he stumbled upon his next big lead: a thing called Wikidata.

He learned that Wikidata is a free, collaborative, multilingual knowledge base that anyone can edit. It’s part of the same ecosystem as Wikipedia but is designed to store structured data—facts and figures that can be read and understood by both humans and machines.

For Ryan, this felt like a breakthrough. "This seemed like the ultimate global collaboration tool. Wow!" he recalls. It was an existing, global infrastructure that was built for the very purpose he had been searching for—a central place to share knowledge so it wouldn't have to be rediscovered again and again.

But this discovery brought a new challenge. He had found a powerful tool, but he had no idea how to use it or, more importantly, how to make it accessible to the average person who just wanted to contribute their knowledge.

The Team: A Lone Wolf Building a Network

Throughout this journey, Ryan didn't have a formal team or a company. In many ways, he was a team of one. However, his real "team" was the sprawling, informal network he built through sheer persistence.

• The Interviewees: The hundreds of builders he spoke to during his year of research were his first collaborators. They helped him map the landscape and understand the depth of the problem.
• The Summit Co-Creators: The people he met in Toronto who helped organize the Cohesion Summit formed a temporary, mission-driven team to test a hypothesis on the ground.
• The Civic Tech Community: The attendees of Civic Tech Toronto provided the environment for discovery, connecting him with the knowledge and tools he wouldn't have found on his own.

Ryan's story shows that you don't need a formal organization to make progress. His approach was to act as a human network connector, absorbing insights from dozens of sources and sharing his vision with anyone who would listen. His momentum was maintained not by funding or staff, but by his unwavering belief in the mission and his willingness to keep asking questions.

Building & Delivering: A Process of Learning

In a project like this, "building" and "delivering" look different from a typical tech startup. The product wasn't an app or a platform; it was clarity.

• Building the Data: The first act of building was the manual creation of the folding bike spreadsheet. It was a tangible asset created to solve a personal problem.
• Building Understanding: The hundreds of calls and the Cohesion Summit were acts of building a deep understanding of the human dynamics of collaboration. The deliverable was the insight that the problem was not a lack of tools, but a lack of trust and coordination among the builders themselves.
• Delivering the Vision: At each stage, Ryan delivered what he had. First, he delivered bike data to online forums. Then, he delivered a space for in-person connection at the summit. Finally, he started delivering the news about Wikidata to his network, acting as an evangelist for a tool he believed could be the solution.

The key process decision was to prioritize conversation over code. Instead of rushing to build a solution, Ryan spent years just talking to people. This non-technical approach allowed him to uncover the human-centric nature of the problem, a crucial insight he might have missed if he had immediately started developing a product.

Impact & Feedback: The Currency of Insight

Ryan is refreshingly honest about the tangible impact of his work. He can't point to a chart showing a reduction in duplicated effort. But the impact is real, albeit harder to measure.

The feedback was often quiet but affirmative. People he spoke with confirmed his intuition: "Someone mentioned that getting people to work together is like herding cats - impossible." Attendees of the Cohesion Summit expressed their appreciation, and he even saw another organization replicate a similar event format, a sign that the idea had resonated.

The most significant impact was on Ryan himself. He gained a profound understanding of the barriers to collaboration.

"I did benefit from understanding that an in-person event to encourage people to work together didn’t end up accomplishing the goal. I ended spending lots of money on venue costs and I wasn’t convinced that the outcome of people working together was being achieved."

This honest self-assessment is perhaps the project's most valuable outcome. Instead of a successful product, he produced a rich, lived experience of what doesn't work and why. He learned that the promise of a tool like Wikidata is massive, but its potential is locked behind a steep learning curve and a lack of community awareness. His current focus is now on this accessibility gap.

Lessons Learned

Ryan's journey offers powerful lessons for anyone trying to tackle a large-scale, systemic problem, especially those without a technical background.

1. Validate the Problem Endlessly: Ryan’s greatest strength was his refusal to assume he knew the answer. He spent over a year just listening. By talking to hundreds of people, he confirmed the problem was real and discovered its unexpected nuances, like the fragmentation of the builders themselves.
2. Human Problems Resist Technical Solutions: The Cohesion Summit showed that even with the best intentions, human factors like ego and trust are the biggest hurdles. A new tool or platform can't solve a problem if the underlying social dynamics aren't addressed.
3. Look for Existing Infrastructure: Before building from scratch, Ryan’s discovery of Wikidata highlights the importance of searching for existing tools that might already solve 80% of your problem. The challenge then shifts from building to adoption and accessibility.
4. Learning is a Valid Outcome: Not every project needs to end with a product launch or a successful company. Ryan's project succeeded in deeply mapping a complex problem space. This knowledge is an invaluable asset for whatever comes next, for him or for others who learn from his story.

Key Takeaways

• Start with your own "folding bike" problem. A personal, tangible frustration is often the doorway to discovering a much larger, more universal challenge. Don't dismiss the small annoyances; they can be signals of systemic issues.
• Map the ecosystem through conversation, not just code. Before you write a single line of code or build a website, spend time talking to the people already working on the problem. You might discover the solution already exists, or that the problem is completely different from what you thought.
• Embrace the role of a non-technical catalyst. You don't need to be a developer to drive change. Skills like listening, connecting people, and persistently asking questions are just as powerful for identifying and framing problems that technical people can then help solve.
• Don't underestimate the "last mile" problem. Discovering a powerful tool like Wikidata is only half the battle. The next, and often harder, challenge is making it accessible and understandable for everyday people who want to contribute. This is where non-technical contributors can have a massive impact.

This article generated by Gemini LLM from self-reflection/interview conducted by Llama 4 LLM