Jeśli naprawdę nie zniechęca Cię pisanie wszystkiego w najdrobniejszych szczegółach (tak jak mnie), to możesz spróbować zakodować prostą aplikację (ale nie za prostą) lub też portal, która posiada wiele rzeczy z podstaw. Następnie opisz linijka po linijce, co robi.
Żeby było ciekawej – i dłużej – nie koncentruj się jedynie na tym, co masz. Dla każdej przestrzeni nazw, klasy, metody itp. napisz: dlaczego akurat taka została wykorzystana; jakie jest alternatywa, ta lepsza i ta gorsza; kiedy nie powinno jej się używać itp.
Dla każdego wykorzystanego programu podczas tworzenia (IDE, kompilator, jakiś dodatkowy parser etc.) napisz: dlaczego akurat taki program; jaka jest alternatywa itp.
Opisz dokładnie architekturę aplikacji; wymień zastosowane dobre praktyki. Porusz kwestię logowania (jeśli będzie) i bezpieczeństwa ogólnie. Poświęć rozdział możliwym błędom, którym nie jesteś w stanie zapobiec (np. brak sieci – jeśli będzie wykorzystywana). Porusz kwestię UX oraz IU oraz dobrych praktyk UI i UX (tak dla aplikacji z GUI, jak i konsolowej). Jeśli to portal, możesz w dodatku (tzw. appendix) poruszyć kwestię grupy docelowej, SEO, marketingu, zarabiania (jeśli ten portal będzie posiadał np. miejsce na reklamy czy treść sponsorowaną).
UPDATE: Tutaj masz prosty przykład, o co mi chodzi: https://silvuss.github.io/2018/10/14/my-backup-shell-script.html (ja to napisałem). Piszę: prosty, bo ma wielkość jednego rozdziału w mojej ocenie, a Ty pewnie będziesz potrzebował mieć kilka takich. Poza tym jest trochę chaotyczny... (Jeśli naprawdę będziesz to czytać i zauważysz jakieś mniejsze czy większe błędy, to napisz do mnie, to poprawię – nikt tego poza mną nie oceniał).
UPDATE2: Ten pan bardzo ładnie koncentruje się na szczegółach: https://dwheeler.com/essays/fixing-unix-linux-filenames.html, poczytaj, jeśli nie zniechęci Cię tematyka (Linux, Unix, Bash, POSIX).
UPDATE3: @inzzz, nie zapomnij uwzględnić, z jakich źródeł korzystałeś. Jeśli Twoją pracę będzie czytać recenzent, będzie widzieć, że tekst nie wpadł Ci do głowy jako Twój własny pomysł, tylko że opierasz się na doświadczeniu innych. Jeśli zaś Twoją pracę będzie czytać osoba niedoświadczona, będzie wiedzieć, jak sprawdzić, czy to, co piszesz, nie ma błędu, lub nawet jak znaleźć więcej szczegółów.
Zależnie od formatu tekstu (plain text, coś opartego na XML (np. odt), Markdown, LaTeX, TeX itp.) wybierz odpowiedni sposób zapisu źródeł. Jeśli format będzie wspierać zapis linków w tekście tak jak tu na forum, to zapisuj je w tekście; jeśli będzie wspierać przypisy dolne/końcowe, wykorzystaj je; jeśli żadna z tych opcji nie będzie dostępna, zrób zwykłą, prostą bibliografię na końcu (w tekście podając źródła w formacie np. [1], [2] itp.) – i tak dalej.
UPDATE4: Źródła mogą być dostępne w internecie (artykuły, oprogramowanie, kod, wideo itp.), ale oczywiście nie muszą. Możesz podać drukowane encyklopedie, słowniki, książki specjalistyczne; nie wiem, jak wygląda sprawa z konferencjami i wykładami – czy zalicza się je do źródeł w jakiejś metodyce, czy nie.
UPDATE5: Oczywiście najważniejsze jest, by całość działała, była zrozumiała i spójna. Lepiej skończyć coś, mając połowę funkcjonalności, ale działającą, niż mając całość, ale niedziałającą.