Join 650k+ students breezing through the IBReady to breeze through the IB?
To finish your Computer Science internal assessment before winter break, begin meaningful work in the first week of September and complete the assessed content by November 21-28. This provides roughly 12 weeks for defining the problem, designing and developing the solution, testing it, evaluating the outcome, and checking the submission.
This schedule is realistic if you choose a manageable problem, maintain contact with the client or intended user, and document decisions while developing. Your school's internal checkpoints remain compulsory and should be added to this timeline first.
Confirm which Computer Science course applies
The revised Diploma Programme Computer Science course began teaching in August 2025, with first assessment in May 2027. Its internal assessment is called the computational solution, in which students use computational thinking to develop a solution to a real-world problem.
The official IB Computer Science subject brief recommends 35 hours for this component. It contributes 30% at SL and 20% at HL. These are official course allocations, not guarantees that every student will personally finish within exactly 35 hours.
Students taking the final assessment under the earlier course in 2026 follow the previous IA structure. Terminology and criteria differ, so confirm your examination session and use the guide provided by your teacher. Do not combine templates or criterion headings from different syllabus versions.
The broad process is similar in both versions:
Identify a genuine problem.
Establish requirements and success criteria.
Decompose and design the solution.
Develop and document the product.
Test it systematically.
Evaluate it against the original criteria.
September-to-November IB Computer Science IA timeline
This schedule assumes approximately 3-4 focused hours per week, with extra time during development and testing.
min read
min read
min read
min read
Dates
Main focus
Required output
September 1-7
Problem and feasibility
Confirmed user, problem summary, platform, and feasibility check
September 8-14
Requirements
Consultation evidence and measurable success criteria
September 15-21
Planning
Decomposition, feature priorities, chronology, and risks
September 22-30
Design
Interface plans, data model, algorithms, and testing strategy
October 1-12
Core development
Working structure and essential features
October 13-26
Main development
Minimum viable product with critical workflows
October 27-November 2
Integration
Feature-complete beta and debugging evidence
November 3-9
Formal testing
Tests showing expected and actual outcomes
November 10-16
Evaluation
User feedback and success-criteria judgments
November 17-23
Complete draft
Report, product, source files, and supporting material
November 24-30
Quality assurance
Corrected, submission-ready package
September: define and design the solution
The first fortnight determines whether the schedule will work. Select a real problem that needs a computational solution, but avoid depending on several unfamiliar technologies at once. Check platform restrictions, data access, deployment requirements, and the availability of your client before committing.
The client or intended user should be able to explain the problem, review a prototype, test the developed product, and provide final feedback. The guide to choosing a Computer Science IA client provides a practical feasibility checklist.
By September 14, translate user needs into specific, measurable success criteria. “The system will be easy to use” is vague. A stronger criterion states that a coordinator can add, edit, search, and archive member records through labelled controls without modifying the database directly.
During the second half of September, divide the problem into components such as validation, data storage, searching, reporting, and interface handling. Produce appropriate designs, which might include interface sketches, database schemas, class diagrams, flowcharts, or pseudocode. Designs should guide development rather than being reconstructed after the product is finished.
Plan testing at the same time. Link tests to success criteria and include normal, boundary, and invalid inputs where appropriate. The Computer Science IA documentation guide explains how planning, implementation evidence, testing, and evaluation should connect.
October: build a complete core solution
October should contain the largest development block. Build one end-to-end workflow before creating numerous disconnected screens. For a booking system, this could mean entering, validating, storing, retrieving, and displaying one booking correctly before adding optional visual features.
Aim for a minimum viable product by October 26. Every essential success criterion should have a functioning implementation, although validation, error handling, and presentation may still need refinement.
Maintain a development record while coding. Note important technical decisions, failed approaches, algorithm changes, test discoveries, and reasons for modifications. Save versioned backups and capture evidence when the relevant code and output are available.
A long feature list does not automatically produce a strong IA. A focused solution with suitable algorithms, clear reasoning, systematic testing, and defensible evaluation is safer than an ambitious application that remains incomplete. The Computer Science IA topic guide can help identify oversized ideas.
November: freeze, test, and evaluate
Set a feature freeze by November 2. After this point, add something only when it satisfies an essential criterion or resolves a serious usability problem. Optional expansion can destabilize working code and consume the time required for evaluation.
Formal tests should identify the input or action, expected result, actual result, outcome, and supporting evidence. Test individual functions, connected components, and complete workflows. When a test fails, document the correction and retest instead of removing the failed result.
Ask another person to complete realistic tasks without constant coaching. New users often expose unclear labels, invalid sequences, and assumptions that developers overlook. Record the feedback and implement only changes that are justified and achievable.
From November 10, judge every success criterion as met, partially met, or not met, supported by test results, outputs, observations, or user feedback. Improvements must address identified weaknesses. For example, replacing a free-text date field with a date selector is more precise than proposing to “improve the interface.” See the Computer Science IA evaluation guide for further guidance.
Protect the final buffer
Complete the report and submission package by November 23. Use the remaining week for broken links, missing assets, source acknowledgements, file naming, unreadable evidence, and teacher-approved corrections rather than new development.
Open every document, run the product from the submitted files, and check any demonstration recording at normal speed. Keep backups in two separate locations. Use only the templates, limits, file structure, and recording rules specified for your assessment session.
Use three scheduled sessions instead of relying on one open-ended weekend block:
60-90 minutes: design or implement one defined component.
60-90 minutes: integrate, test, and debug it.
45-60 minutes: update documentation and evidence.
Finish each session by recording the next physical action, such as “validate duplicate email addresses.” Continue short exam-practice sessions alongside coursework. The IA time-management guide explains how to protect separate coursework and revision periods.
Common scheduling mistakes
Coding before confirming user requirements.
Choosing technology without checking feasibility.
Leaving documentation until November.
Treating testing as a final demonstration rather than part of development.
Adding optional features after the beta deadline.
Following an online date instead of the school's internal deadline.
Schools set their own proposal, draft, feedback, authentication, and submission dates. Confirm these in writing using your teacher's instructions, not student forums. RevisionDojo's IA deadline guide explains why internal deadlines differ.
Conclusion
For a fall finish, define the problem in early September, complete design by the end of that month, develop the core solution in October, and reserve November for testing, evaluation, assembly, and quality assurance. The decisive milestone is the feature freeze, when you stop expanding the product and begin proving how effectively it solves the original problem.
RevisionDojo can support the process through criterion-focused IA Feedback, Jojo AI, documentation resources, and the Computer Science IA Grader. Use these tools throughout development rather than waiting until the report is complete.
