Most students lose marks on the IA not because their code is bad, but because the write-up doesn't show the thinking behind it. Examiners aren't grading your program. They're grading whether you can explain a problem, justify your design choices, and evaluate your own solution honestly.
Start with a real problem, not a cool idea. The strongest IAs solve something specific for a specific client or user, not "an app that helps students study." Pick a problem you can describe in one sentence, and one where you can name exactly who benefits and how.
Success criteria come before code. Write these early and keep them concrete. "The system should be user-friendly" earns nothing. "The system should let a coach record a player's substitution in under 10 seconds" does, because it's testable.
Document your design decisions as you make them, not after. Screenshots of early prototypes, notes on why you rejected one data structure for another, records of client feedback. This is where most of the "personal engagement" marks live, and it's nearly impossible to fake convincingly after the fact.
Test against your own success criteria, not general functionality. Show the system working, and be honest about what doesn't work. A well-documented failure with a clear explanation often scores better than a vague claim that "everything works as intended."
Evaluation is not a summary. Go back to each success criterion individually and say whether it was met, how you know, and what you'd change with more time. This section is short in most IAs and shouldn't be.
The 35-hour time allocation goes fast once you're coding. Budget real time for the write-up, not just the build.