Back to workbench
Reflection5 min read
Turning Old Clone Projects Into a Timeline of Growth
Clone projects are not the destination, but they honestly show the path from layouts and APIs to real systems work.
Old clone projects should not be framed as flagship work. They are better as a visible learning timeline.
What I was trying to do
I wanted the site to keep early builds honest: not overclaimed, not hidden, and not competing with newer systems, AI, and enterprise work.
What I learned
- Clone projects are not the destination.
- They show learning progression if they are grouped and labeled clearly.
- They taught routing, layout, APIs, Firebase, deployment, and state management.
- Current work makes more sense when the earlier steps are visible.
Technical notes
- Moogle belongs under earlier search/API/UI learning.
- Mewtube belongs under React, Redux, Firebase, and external API practice.
- Discord Clone and Amazon Prime Clone belong under layout, data fetching, and product UI replication.
- Shopeee belongs under ecommerce/hackathon learning rather than flagship product work.
Open questions
- Which older projects still deserve live links?
- Should each earlier project have a short lesson attached?
- How much archive detail is useful before it distracts from active work?
Next steps
- Keep older projects in Earlier Work / Learning Builds or Archive.
- Add lessons learned to timeline entries.
- Avoid letting clone projects dominate homepage or featured sections.
Tags
- Earlier Work
- Reflection
- Learning Builds
Related