Developer Tutorial Series with a Sample App and Feedback Report
A developer relations final year project for developers adopting a real API or open source library: build a realistic sample app, publish a tested three-part tutorial series with video, collect reader friction, and send a developer experience report to the product team. It shows the full loop: build, teach, listen and report back.
Intermediate
A small team, or one strong student willing to learn something new.5 to 7 weeks · 1 student
8 to ship
3 optional extrasSuggested stack
What you should ship
- A sample app in a public repository with a README, a licence and setup steps verified on a clean machine or fresh container
- A written three-part tutorial series: getting started, a realistic feature, and deploying or handling errors at scale
- A CI job that runs the tutorial's code snippets or sample app on every push so the tutorial cannot silently break
- A recorded video of at least one part with clear audio and code readable on a phone
- A live walkthrough at a meetup, study group or online session where at least five developers follow along
- A log of reader questions, comments and problems with your responses and where each was resolved
- A developer experience report ranking friction points by impact with evidence and suggested fixes, sent through the product's public channels
- An honest results page: time to first success for testers, completion rates, feedback collected, and views only as context
If you have time left
- Translate one part for developers who prefer another language, such as Urdu, and compare completion rates
- Get one documentation fix or example merged into the product's official docs or repository
- Run a second workshop after fixing the stuck points and measure whether time to first success drops
The problem developers hit with new APIs and libraries
Every developer has opened a product's quick start, followed it exactly, and hit an error on step four because the docs were written for an older version. Official docs cover the reference well but often lack a realistic end-to-end example. Community tutorials fill the gap, but most are written once, never tested again, and quietly break a few months later. Product teams rarely hear about any of this, because frustrated developers just leave.
Developer relations work exists to close that loop: build with the product, teach other developers, listen to what they struggle with, and bring that back to the product team. Most student portfolios show only the first two steps. This project shows all four, with evidence.
What already exists and the gap
- Official docs and quick starts from API companies are accurate at the reference level but tend to stop at hello world.
- DEV, Hashnode and freeCodeCamp articles cover many products, but few are tested against new releases or updated after comments point out breakage.
- The Diataxis framework separates documentation into tutorials, how-to guides, reference and explanation, a useful lens for deciding what your series is and is not.
The gap is a tutorial that is tested like code, measured with real learners, and turned into structured feedback the product team can act on.
What you build
Choose a product with a genuine free tier or an open source licence, decent docs and visible room for improvement: a payments API in test mode, a database with a free plan, an AI API, a popular open source library.
- Sample app: a small app solving a believable problem, not a hello world. Clean code, short setup.
- Series: part one gets someone to a first success fast; part two adds a realistic feature; part three covers deployment, errors or scaling.
- Tested tutorial: code snippets live in the repository and CI runs them, so a new product release that breaks the tutorial fails your build.
- Distribution: publish where developers already are, following each community's self-promotion rules.
- Feedback loop: a question log, a workshop where people follow along live, and a developer experience report.
The technically interesting part
The hard part is measuring learning, not traffic. Views and stars are easy to count and say little. Instead, run structured sessions: give five developers the tutorial with no help, record time to first success (first successful API call or first working screen), where they got stuck and whether they finished. Fix the tutorial, then run five more and compare.
The second part is keeping docs correct as code: pin versions, extract snippets from tested files rather than pasting them, and add a scheduled CI run so you notice when the product changes underneath you.
How to evaluate it
- Time to first success for tester groups before and after revisions.
- Completion rate for each part in the workshop.
- Stuck points: count and categorise them (product bug, missing doc, tutorial error, environment issue).
- Report impact: whether the product team acknowledged, replied to or acted on any item.
- Freshness: scheduled CI runs passing across the project, and how fast you fixed any break.
Suggested plan
- Week 1: choose the product, read its terms, build a spike, plan the three parts.
- Weeks 2 to 3: build the sample app and write part one; test on a clean machine.
- Week 4: parts two and three, CI for snippets, record video.
- Week 5: publish and run the first tester group.
- Week 6: revise, run the workshop and second group.
- Week 7: developer experience report and results page.
Path to a product
The realistic outcome is a career route: this portfolio targets developer advocate, technical writer and solutions engineer roles. Paid technical writing for developer tools companies is a real market, and some run community writer programmes. Longer term, you can offer tested tutorial and docs audits to API startups. Always label sponsored work clearly.
Scope warning
Do not build a large app; the tutorial is the product. Do not chase views, buy followers or present sponsored content as neutral. Do not use the product's logo as if you represent it; label your content as independent.
Learn what you need on Sefism
- Personal branding roadmap : publishing and sharing technical content well.
- Full-stack cheat sheet : quick reference while building the sample app.
- roadmap.sh: DevRel : the skills and activities around this role.
- Docs for Developers : how to plan, write and test technical content.
- Write the Docs: Documentation Guide : practical guidance on docs structure and style.
- How do I explain technical ideas to other engineers? : the core skill this project trains.
Get help with this idea
The product you choose and the way you measure learning make or break this project. Tauseef can help you pick a product with the right amount of friction, design the tester sessions, and shape the report so it is useful to both your examiners and the product team. If you are new here, create a free account first.
Ideas and guidance, not finished projects
These are project ideas and scoping guidance, published free for students to use as a starting point. I do not build, write, or sell final-year projects, and I do not complete coursework for anyone. Take an idea, make it yours, and build it.
Not sure this one fits you?
I help students pick an idea that matches their skills and their deadline, then scope it down until it is finishable. Guidance only, never done for you.
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Sessions are free for approved Sefism members, and a few slots open each week.
Follow along
New writing, resources and project ideas land here first.