How complex should an IB Computer Science IA be?

An IB Computer Science IA should be complex enough to demonstrate algorithmic thinking, programming decisions, data handling, testing, and evaluation. Complexity should arise naturally from the problem rather than from the number of frameworks or features used. A focused system with validation, persistent storage, searching, and one meaningful algorithm can provide more assessable depth than a large unfinished platform. You should be able to explain how each major component works and why it was selected. If the system cannot be completed, tested, and demonstrated clearly, its scope is too large.

How many features should my Computer Science IA include?

The IB does not prescribe a required number of features. In practice, a small group of connected functions is stronger than a long list of unrelated additions. Begin with one complete workflow and identify the functions required to make it useful from start to finish. Link every major function to a measurable success criterion and remove features that have no clear connection to the problem. The appropriate number is therefore the number you can design, implement, test, document, and evaluate properly.

Does the IB Computer Science IA need an external client?

For the course first assessed in May 2027, the official task does not require a named external client. Students choose a real-world problem and develop a computational solution, although consulting an intended user can still improve requirements and evaluation. The previous course, with final assessment in 2026, placed greater emphasis on a client or adviser and related consultation evidence. This is why older guides and exemplars frequently state that a client is compulsory. Always follow the guide for your examination session and confirm uncertain requirements with your teacher.

Is a database necessary for a high-scoring Computer Science IA?

A database is not an automatic requirement for a strong IA. It is appropriate when users need to store, relate, update, search, or aggregate persistent records. For a smaller dataset, structured files or another storage method may be sufficient if the choice is justified. Adding a database solely to make the project appear advanced can create unnecessary setup and testing work. Marks depend on the quality and appropriateness of the solution evidence, not on including a particular technology.

Can I use AI or external libraries in my IB Computer Science IA?

External libraries can be used when they are suitable for the problem, but their use and sources must be documented appropriately. Generative AI use must follow the IB's academic integrity expectations and any instructions established by your school. You remain responsible for understanding, verifying, testing, and being able to explain every submitted part of the solution. Code or explanations produced by another source must not be presented deceptively as entirely your own work. Ask your teacher how AI-assisted work should be acknowledged before using it in development or documentation.

When should I stop adding features to my CS IA?

Stop adding features when all must-have success criteria have been implemented and the remaining time is needed for testing, documentation, and evaluation. Optional features should never endanger the reliability of the core workflow. A useful rule is to freeze the scope before final testing begins and permit only defect fixes or small changes supported by evidence. If a new idea requires major changes to the data model, interface, or architecture, record it as a future improvement instead. A complete and well-evaluated solution is normally safer than an ambitious product with unfinished components.

Back to all posts

IB Computer Science IA Without Overengineering

IB Computer Science Internal Assessment IB IA

• 4 Oct 2026•11

IB Computer Science IA Without Overengineering

Join 650k+ students breezing through the IBReady to breeze through the IB?

IB Computer Science IA Without Overengineering | RevisionDojo

Back to all posts

IB Computer Science IA Without Overengineering

IB Computer Science Internal Assessment IB IA

• 4 Oct 2026•11

The strongest IB Computer Science IA is not necessarily the largest or most technically fashionable project. It is a focused computational solution that addresses a clearly defined problem, uses appropriate programming techniques, works reliably, and can be tested against measurable success criteria.

Overengineering becomes a problem when technical ambition consumes time needed for planning, documentation, testing, and evaluation. The aim is not to avoid complexity completely, but to include only complexity that helps solve the chosen problem.

Check which Computer Science guide applies

The IB introduced a revised Computer Science course for first teaching in August 2025 and first assessment in May 2027. Under this course, the IA is called the computational solution and involves developing software for a real-world problem of your own choosing.

For first assessment in 2027, the project is allocated 35 hours, marked out of 30, and contributes 30% at SL or 20% at HL.

Criterion	Focus	Marks
A	Problem specification and success criteria	4
B	Decomposition and planning	4
C	System model, algorithms, and testing strategy	6
D	Development, functionality, techniques, and testing	12
E	Evaluation and justified improvements	4

The revised guide specifies a 2,000-word maximum for the documentation and a demonstration video lasting no more than 5 minutes. A named external client is no longer compulsory, although consulting a real user can strengthen requirements and testing evidence.

Students taking their final assessment in 2026 follow the previous guide, which has different criteria, deliverables, and client expectations. Confirm your examination session with your teacher before following online advice or older exemplars.

What appropriate CS IA scope looks like

A feasible project solves one bounded problem for one identifiable user group. It usually has a clear central workflow, a manageable data model, and a small number of supporting features.

Consider a music teacher who needs to allocate weekly practice tasks and monitor completion. A suitable solution could create student and task records, assign tasks by date and difficulty, record completion, and generate progress summaries. Authentication for multiple schools, live chat, payment processing, machine-learning recommendations, and a native mobile application would add substantial work without necessarily solving the original problem better.

A useful scope statement is:

The solution will enable [user] to perform [core process] through [essential functions], while excluding [explicit boundaries].

Explicit exclusions, such as public registration, cloud synchronization, or live messaging, help prevent uncontrolled expansion.

Build one complete workflow first

Identify the smallest sequence that delivers genuine value from beginning to end. For a tutoring appointment system, that sequence might be:

An administrator creates tutors and available time slots.
A student searches for a suitable slot.
The system checks availability and records the booking.
The administrator views or exports the schedule.

This is a vertical slice because it includes the interface, processing, storage, and output required for one complete workflow. Building it first is safer than producing several unfinished screens or disconnected technical components.

Once it works, add features that strengthen the same process. Conflict detection, validation, filtering, and summary generation are generally more defensible than themes, avatars, or social features.

Turn the problem into measurable success criteria

Success criteria control scope because every major feature must have a testable purpose. A statement such as “the application will be user-friendly” is too subjective to provide a reliable target.

Stronger criteria describe observable results:

The administrator can add, edit, archive, and retrieve student records.
The system prevents two appointments being assigned to the same tutor and time slot.
Users can filter appointments by tutor and date.
Invalid dates and blank required fields produce explanatory messages.
The system generates a weekly summary containing the tutor, student, date, and booking status.

Choose a coherent set rather than a long wish list. Every criterion creates work in design, implementation, testing, demonstration, and evaluation. If you cannot explain how a criterion will be implemented and tested, it is not ready for the final scope.

Choose purposeful technical depth

Avoiding overengineering does not mean writing a trivial program. Technical depth should arise naturally from computational requirements such as:

validation involving related conditions
searching, sorting, filtering, or ranking records
conflict-detection algorithms
persistent storage and structured queries
classes with meaningful responsibilities
aggregation and report-generation logic
modular functions with defined inputs and outputs

Ask why each technique is needed. A database is appropriate when users must store, update, relate, and query persistent records. A machine-learning model is unnecessary when a transparent scoring algorithm would solve the problem more reliably and be easier to explain.

There is no official minimum line count. As the RevisionDojo guide to lines of code in the Computer Science IA explains, code volume is a poor substitute for coherent functionality and justified decisions.

Prioritize before coding

Classify proposed features before development starts:

Priority	Meaning	Booking-system example
Must have	Required to solve the problem	Create, validate, store, and cancel bookings
Should have	Valuable but not essential	Filter bookings and export schedules
Could have	Added only after assessment evidence is complete	User-selected colour theme
Will not have	Explicitly outside the scope	Payments, live chat, and public deployment

Complete and test every must-have feature before attempting optional work. A practical sequence is to define the problem, freeze the initial success criteria, design the data and algorithms, build a vertical slice, add essential functions individually, and test normal, boundary, and invalid inputs throughout development.

Record design changes while they are fresh. RevisionDojo's guide to how long the Computer Science IA takes can help convert this sequence into weekly checkpoints.

Common overengineering traps

Starting with technology rather than a problem

“An AI-powered platform” describes technology, not a user need. Begin with an inefficient or error-prone process, then select the least complicated technology capable of improving it.

Building a platform rather than a solution

School management systems, social networks, and e-commerce platforms contain many separate subsystems. Reduce the idea to one process, such as tracking equipment loans for one department or managing stock for one small organization.

Adding unnecessary authentication

Authentication can require password hashing, authorization, recovery procedures, and security testing. Include it when distinct users genuinely require different permissions, not simply because professional websites have login screens.

Using too many unfamiliar frameworks

Each framework adds setup, integration, debugging, and documentation costs. One familiar language, one suitable interface method, and one storage approach are usually safer than several services combined to appear sophisticated.

Leaving testing until the end

A larger system creates a larger testing obligation. Test each module as it becomes functional and connect important tests to success criteria. Early testing reveals scope problems while features can still be simplified or removed.

Freeze scope and document decisions

Before full development, check that you can identify one complete workflow, connect every must-have feature to a success criterion, design the important algorithms, and test each criterion with observable evidence. You should also be able to demonstrate the essential functionality within 5 minutes and explain the purpose of every major code section.

Preserve wireframes, algorithm designs, data models, test plans, failed approaches, and reasons for significant changes. For each important technique, explain the problem it addresses, how it works, why it was suitable, how it was tested, and what limitations remain.

The RevisionDojo Computer Science IA rubric guide, IA evaluation guide, and Computer Science IA examples can support this review. However, your teacher and the official guide for your examination session remain authoritative.

Conclusion

A well-scoped IB Computer Science IA has one clear problem, one complete workflow, measurable success criteria, purposeful algorithms, and sufficient time for testing and evaluation. Technical ambition is valuable only when it improves the solution and produces work you can explain convincingly.

Freeze the must-have scope early, test continuously, and keep optional features genuinely optional. RevisionDojo's IA exemplars and coursework feedback tools can then help identify missing evidence without encouraging unnecessary expansion.

Sources and referenced URLs

Add as a preferred source on Google