Code-Yaar
Think. Build. Evolve. — a software engineering education platform, currently in disciplined definition phase.
- Status
- Documentation phase
- Year
- 2026
- Role
- Product definition, requirements, architecture planning, and progress-tracking system.
01Context
Code-Yaar is being developed as a student-focused technology and software engineering platform intended to help learners move beyond passive tutorial consumption toward practical technical skills, real projects, and demonstrable outcomes.
The product vision: help aspiring developers Learn, Build, and Prove. The intended audience is students and beginner-to-intermediate learners interested in programming, software engineering, computer science, AI/ML, and career-oriented learning.
The repository currently contains no application implementation. It holds five product and engineering documents — a PRD, architecture, MVP roadmap, current-progress report, and AI coding rules — written deliberately so future progress is measurable instead of claimed.
02Problem
Many learners consume programming content without developing practical ability: tutorial dependence, limited project practice, weak problem-solving confidence, unclear next steps, and difficulty producing credible evidence of skill.
Most education platforms promise outcomes they cannot prove. Starting Code-Yaar with an honest status system prevents that pattern from day one.
03Approach
Write the PRD, architecture, and roadmap first — scope drift is prevented by an approved MVP definition before any foundation work.
Define a strict status vocabulary (Implemented / Verified / In Progress / Planned / Proposed / Deferred / Not Implemented / TBD) so every future claim must carry evidence.
Center the product on one loop: Learn → Build → Prove — learning direction, hands-on practice, project work, proof of work, feedback, progression.
Keep explicit non-goals: not a university replacement, not a social network, not a course marketplace, not a recruitment platform, not a full IDE.
04Architecture
Learning Direction
What to learn next
Learn
Guided content and concepts
Build
Hands-on practice and projects
Prove
Proof of work / portfolio evidence
Feedback & Progression
Review and next step
05Stack
- Product documentation
- PRD
- Architecture planning
- MVP roadmap
- Status tracking
Note — Target direction recorded in docs: Python, Next.js/React/TypeScript, Django, PostgreSQL, Supabase — no code exists yet.
06Features
- 01Product Requirements Document (v0.1, Draft) — problem framing, personas, user needs, value proposition, and functional requirements.
- 02Architecture document — records intended stack direction and states plainly what does not yet exist.
- 03MVP roadmap — four phases (Foundation → MVP → Validation → Expansion) with priorities, dependencies, and completion criteria.
- 04Current-progress report — a source-of-truth status table with evidence columns as observed on 2026-09-10.
- 05AI coding rules — boundaries for AI-assisted development on the project.
07Project state
Implemented
- Five-document product suite: PRD, architecture, MVP roadmap, current progress, AI coding rules.
- Status vocabulary and evidence-based progress tracking.
- Explicit MVP non-goals and scope exclusions.
In progress
- MVP definition and primary persona decision (flagged P0, awaiting product-owner decision).
- Architecture and stack decisions — direction recorded, nothing implemented.
Planned
- Repository foundation: source layout, package setup, basic checks.
- Learner entry point, first learning direction, hands-on practice, one meaningful build workflow, basic proof of work.
- Automated verification: tests, linting, type checking, build checks.
- Feedback workflow, progression tracking, community and AI assistance (post-MVP, proposed).
08Engineering decisions
- D01
Documentation before code
The first commit is a plan, not scaffolding. CURRENT-PROGRESS.md states honestly that no product feature exists in the codebase — planned work is never dressed up as shipped.
- D02
Evidence columns
Every status entry records where the claim is proven (which file, which test). A feature is only "Implemented" when code exists for it.
- D03
Named non-goals
University replacement, social network, course marketplace, recruitment platform, full IDE, and broad AI platform are explicitly excluded from initial scope.
- D04
No dates until they are real
The roadmap carries no deadlines because none have been decided — false dates create false pressure and dishonest reporting.
09Challenges
- C01
Resisting premature scaffolding
The temptation with a platform idea is to create repositories and boilerplate immediately. The project instead holds until MVP scope is approved.
- C02
Keeping honesty as the brand
An education platform that overstates its own progress would contradict its own message — the status vocabulary exists to make overstatement structurally impossible.
10Result
- Complete, reviewed product documentation suite published publicly on GitHub.
- A measurable baseline: anyone can compare future progress against the 2026-09-10 status report.
- Clear MVP definition work queued as P0 with acceptance criteria — before any implementation begins.
11What I learned
- “Writing "no product feature exists" in your own progress report is the most credible thing a pre-launch project can do.”
- “A status vocabulary is an engineering tool — it turns future progress claims into checkable assertions.”
- “Scope discipline (what the product is not) defines a project faster than feature lists.”