--- title: Case Studies & Stories description: Case studies from DevRel and developer communities, written to show the problem, the work, the evidence, and the lesson. url: https://pr-2-5bfc5f2f5cb7.thally.app/case-studies --- # Case Studies & Stories Case studies from DevRel and developer communities, written to show the problem, the work, the evidence, and the lesson. Case studies are where principles meet reality. A framework can tell you how a community program *should* work. A case study shows what happened when real people tried it with real constraints. For this guide, we want stories that are useful enough for another DevRel practitioner to learn from: not just success pages. ## Our case-study standard Every case study should answer: 1. What was the context? 2. What developer or business problem existed? 3. What did the team know before acting? 4. What did they choose to do? 5. What evidence did they collect? 6. What changed? 7. What did not work? 8. What would they do differently? ## Case study: Mojo Africa community meetup ### Context Mojo Africa is a community focused on learning and discussion around Mojo and the Modular ecosystem in Africa. A public Modular/Luma event page describes a community-led meetup in Uyo, Nigeria focused on **the role of Mojo in AI infrastructure**. The event aimed to give attendees a practical introduction to Mojo and the Modular ecosystem through explanations, demos, and real-world examples. Modular later highlighted the Uyo meetup in its own Modverse community update and credited Ekemini Samuel as the community organizer. ### The developer need Mojo and the surrounding AI infrastructure ecosystem were still unfamiliar to many developers in the region. The community opportunity was not simply “host an event.” It was: > **Create a local place where developers can understand an emerging technology, see it used, ask questions, and meet other people learning it.** ### The approach The public event description emphasizes: - a practical introduction; - AI infrastructure context; - live demos; - real-world examples; - a local in-person community; - a connection back to the wider Modular Discord community. That combination matters. It connects **education**, **hands-on understanding**, and **community continuity**. ### What we can verify publicly - The event was community-led in Uyo, Nigeria. - It was presented/supported through Modular's community ecosystem. - The topic focused on Mojo's role in AI infrastructure. - Modular later featured the meetup in a community update. ### The May 2026 event The [Mojo Africa 2026 event](https://lnkd.in/p/erXYFN3z) was the community's second major event. It was held in Uyo on May 2, 2026 with the theme **The Role of Mojo in AI Infrastructure**, and Modular provided sponsorship. Attendance was recorded as 98 people: 78 in person and 20 online. The in-person audience included 30 developers, 10 students, 30 technology enthusiasts, and 8 newcomers. The program covered: - the two-language problem; - Mojo and Mojo 1.0; - MAX; - GPU programming and AI infrastructure; and - improving efficiency in AI delivery. The event produced a livestream, an event recap, and photographs. These are useful output and reach signals, but they do not prove adoption by themselves. ### The lesson Mojo Africa created local context around an emerging technology. The strongest reusable lesson is that education comes before adoption. Developers need a place to understand the problem, see the technology, ask questions, and continue learning after the event. The next evidence to collect is follow-through: repeat attendance, workshop participation, community questions, projects started, documentation friction, and contributions back to the ecosystem. ## Case study: DXMentorship ### Context DXMentorship is a Developer Relations mentorship program. Its public site currently describes a **seven-week** program aimed at helping people build skills, confidence, industry connections, and practical experience for Developer Advocate careers. The site also shows a network of past mentors and mentees and links to a DXM Champions program. ### The problem DevRel can be difficult to enter because the role is broad and job titles are inconsistent. People may know they enjoy writing, community, engineering, or teaching but still struggle to understand: - what the job actually looks like; - what skills to prioritize; - how to build credible experience; - how to meet practitioners; - what evidence hiring teams expect. ### The approach DXMentorship combines: - time-bounded cohorts; - mentorship; - real-world scenarios; - industry connections; - community; - contributor/champion opportunities. The public DXM Champions repository describes a program where participants can help organize and champion cohorts, including moderation and program decisions. That is important because it moves learning toward participation. ### What we can verify publicly - The program is positioned around Developer Relations / Developer Advocacy. - The public site describes a seven-week experience. - It lists past mentors and mentees. - It links a Champions program and community channels. ### What still needs contributor evidence A stronger case study should add: - cohort completion; - portfolio outputs; - mentee stories; - role transitions; - mentor feedback; - changes made between cohorts; - what did not work. Do not convert “mentees now work at global companies” into a causal claim unless the individual stories and evidence support that relationship. ## Case study: Advorel's contributor-led content practice Advorel is a Developer Relations company that helps developer-focused teams with: - DevRel strategy; - developer marketing; - community management; - technical content; - developer-focused video; - developer events. The Advorel team contributing experience to this guide includes Faith Ayoola Oni, Joy Ndukwe, Abimbola Adedotun, Samuel Uzor, and Ekemini Samuel. The repository contains published examples from each contributor, ranging from beginner tutorials and framework explainers to community writing and detailed technical projects. ### What the team did The content examples use several educational approaches: - task-focused tutorials for developers completing a specific integration; - beginner guides that establish context before introducing a tool; - community writing that turns an abstract idea into a practical discussion; and - project tutorials that teach through a complete implementation. ### Evidence and limits The published articles are verifiable artifacts of the work. They show technical education, editorial choices, and public contribution. We do not have approved traffic, conversion, client, or adoption figures, so this case study does not claim them. ### The lesson A DevRel team needs more than one content format. The right format depends on the reader's problem, prior knowledge, and desired next step. The team's examples are most useful when we study why each piece works, not when we treat the links as a portfolio wall. See [Content Creation](/content-creation) for the verified articles and the workflow behind them. {/* CONTRIBUTOR REVIEW: Add approved client outcomes, constraints, and lessons when the source material and publishing permission are available. */} ## Case-study template ### Background What does the reader need to know? ### The problem What developer friction or organizational problem existed? ### Baseline What evidence did we have before the work? ### Strategy What did we decide and why? ### Execution What did we actually do? ### Evidence Numbers + developer feedback + artifacts. ### Outcome What changed? ### Attribution How confident are we that the work influenced or caused the outcome? ### What did not work Include it. ### Lesson What should another team reuse? ### Resources Talks, repositories, screenshots, recordings, docs, dashboards, templates. ## Related pages - [Real-Life Examples](/real-life-examples) - [Lessons Learned](/lessons-learned)