From my personal experience, as a successful UK Graduate, I can assure you that something like is worth writing about. The main thing I learned from my time at University was that, for the majority, the final product plays roughly 40-50% in what you should talk about for these sorts of things. The remaining comes from the ability for said demo's to convey the new skills you learned along the way.

These include, but are by no means limited to:

• Identifying and overcoming programming hurdles; seeing there is a problem, searching books and the internet (making brief notes of references like forum posts, text passages), and applying the information from these to your own product. This is extremely important as it shows self-motivation in problem solving, two things which my lecturers instilled within us.
  
• Time-management; a DEFINITE skill to demonstrate as it shows you won't be the student that lets the course, along with its numerous module assignments, get the better of them.
  
• Self-motivation; I realise I have already mentioned this, but it deserves its own sub-heading. When lecturers are in the process of reading hundreds upon hundreds of statements, to determine the best students for interview/their courses, the ones that show this skill with an accompanying demo will make them go "hang-on, let's get this guy in for an interview, I would really enjoy seeing this demo that he has written about". This gives them an opportunity to see visually what you are capable of whilst also allowing them to identify your programming experience. A student that shows this is better than one with near no experience that loses motivation after they realise the introductory 'Hello World' lesson might be all they can achieve, which in turn slows the learning experience of the entire class.
  

• Identifying faults; this can apply to two areas, the first being faults in the software with the second being faults in your demo-making process. Software could be linked to things such as inefficient code solutions to certain problems that could be improved upon next time. The second is identifying where in your project length you could have done things more efficiently, such as slowing down on parts with limited knowledge. This could lead to you saying "next time I will make a list of what needs to be done, I will order this list based on things I know can be completed from easiest to hardest." This gives you the opportunity to complete things you know can be done quickly and where you excel, whilst allowing more time for the things that require research. This means you don't get bogged down going "I've spent so much time researching, that I missed out on [insert easy objective here]'s 1-5 and now they haven't turned out as great.
  

These are only a few that you will discover along your journey, I also think it will be a little difficult what with the 4,000 character limit to be able to talk about any of them in any real detail. The best thing I can say is dedicate a paragraph to your project, saying what you achieved and how it bettered your understanding along the way. Then link it into your application in a way that shows your passion for the course/wanting to be involved in this educational experience by showing you have some of the basic skills required to be able to take on the challenge.

One thing that is different from College to University is that tutors won't chase you up if your close to missing deadlines. They won't be on your backs asking the assignment is coming along, if it's late, it will have its marking reduced/mean you might miss out on full marks and have to take a resit. Showing that you have skills pre-university is a great way of showing that you have the commitment, and that the lecturer is not wasting their time, as well as yours by accepting you.

One final thing, if in the time between submitting your statement to the point of interview that you decide to add features/improve your demo, take two versions. Take the one you had at the time of submission as well as the updated one, to show to willingness to improve on past performances, as well as printouts of your code. This is so you can guide your interviewer through the underlying mechanics as they appear on-screen. And remember to test it on as many different computers before you go, to ensure it will run successfully as there is nothing worse than realising you forgot to include a library with your exe.

I hope this helps in writing your statement and I do apologise for the novel..

Regards,

Stitchs.