Computer Science Dissertation Proposal Sample: Real-Time Data Web App for Smarter Consumer Decisions

This is the research proposal chapter of a masters computer science dissertation, written for a student at a UK university. A full dissertation adds five more chapters on top of it, listed below; for a sample that carries a whole project through to results, read our data mining dissertation sample, which runs the analysis on a real dataset and reports what it found. The project builds a real-time market web application in Django and Python that pulls current price, availability and performance data so buyers can compare high-value purchases such as cars and property. Everything a UK proposal has to contain is here: aims, objectives, research questions, a hypothesis, background, the technology stack, a literature review and a dated Gantt plan.

For the service pages, see computer science assignment help and thesis and dissertation help. There are more computer science samples and more dissertation and research proposal samples in the archive.

What Goes into a Computer Science Dissertation Proposal?

Nine sections, in this order: project definition, aims and objectives, research questions, hypothesis, expected outcomes, background, tools and technologies, a dated project plan, and ethics and data approval. A literature review and a challenges section follow in most briefs. Markers judge whether the objectives are testable in the time available, not how ambitious the idea sounds.

Where the proposal sits in a masters computer science dissertation

1. 1 Proposal Aims, objectives, research questions, hypothesis, background, tools, plan and ethics: the chapter on this page.
2. 2 Literature review What is already known, organised by theme, ending in the gap the project fills.
3. 3 Design and methodology Architecture, data sources, the evaluation method and why each choice was made.
4. 4 Implementation What was built, with the decisions that changed along the way and why.
5. 5 Evaluation Results against the research questions, with the tests, the numbers and the limits.
6. 6 Conclusion What was answered, what was not, and what a follow-on project would do.

1. Project definition. One paragraph saying what you will build or investigate, and for whom. Name the artefact.
2. Aims and objectives. One aim, then three to five objectives. Each objective starts with a verb and can be ticked off, as in the sample below.
3. Research questions. Two or three, each answerable by the work you have actually proposed rather than by a wider literature.
4. Hypothesis. A null and an alternative where the project tests something. Leave it out where the project is a build with no comparison; a bolted-on hypothesis weakens a proposal.
5. Expected outcomes. What exists at the end: an artefact, a dataset, a measured finding, or all three.
6. Background. Why the problem matters now, with citations. This is not the literature review; it is the case for doing the work.
7. Tools and technologies. Languages, frameworks, databases and hosting, with a reason for each choice over the obvious alternative.
8. Project plan. A Gantt chart with dependencies and dates. Supervisors read this first, because it shows whether the scope fits the term.
9. Ethics and data. If you will collect data from people, say what you collect, how you store it, and which approval you need. Most UK departments require this before any data collection begins.

The Sample: In the Market Web Application

What follows is one student's proposal, reproduced with its own citations. The project is called "In the Market", a web application that collects current price, specification and availability data for high-value goods such as cars and houses, and presents it so a buyer can compare options at the moment of deciding. Read it for three things: how narrowly the objectives are written, how the hypothesis is tied to one specific design decision, and how the Gantt chart exposes the dependency that decides whether the project finishes.

Real-Time Data Web App for Smarter Consumer Choices

The title states the claim the project is testing. Buyers comparing a car or a flat are working from listings that are often stale, and the proposal argues that the useful intervention is not more data but fresher data, presented in a way that matches how people actually search. The sections below follow the order a UK computer science department expects.

Project Definition

The project builds a market web application, "In the Market", that connects consumers with sellers of high-value goods and supports the comparison stage of a purchase. The application holds current price, availability and performance data for each listing, links each product to its manufacturer or supplier, and lets a user navigate by keyword, by image and by stated preference rather than by browsing a flat list. Web applications have become the standard channel for this kind of commerce, and the technical question this project asks is what it takes to keep such a platform current rather than merely comprehensive.

The application is built on the Django web framework. Django is a Python framework aimed at fast, secure and scalable web development, and Bakshi et al. (2020) compare it with Spring on exactly those grounds. The choice matters for a one-term project because the framework supplies authentication, an admin interface, an object-relational mapper and a set of security defaults that would otherwise have to be written and tested by the student.

The build will be evaluated with users. Students recruited from the department will use the application and give structured feedback on its interactivity, its practicality and whether it shortened the comparison they were asked to make. That feedback is the data the hypothesis below is tested against.

Aims and Objectives

The aim is to put current data in front of a buyer at the point of decision, so that a comparison of cars, motorbikes, flats or houses reflects what is available now rather than what was available when the listing was written.

The objectives are:

• To develop a scalable and secure market web application using the Django framework.
• To implement scraping and validation methods that build and refresh datasets on price, performance, market demand and key features.
• To design preference-based sorting with keyword and image navigation over listings whose descriptions and sale details are refreshed on a schedule.
• To evaluate the application with users and report whether the navigation design measurably shortened the comparison task.

Research Questions

• How does an interactive, scalable web application affect the way a user carries out a high-value product comparison?
• What does a refreshed dataset on demand, performance and pricing change about a purchase decision, compared with a static listing?
• Is preference-based keyword and image navigation a more efficient route to a decision than conventional filtered search?

Hypothesis

The project claims that a data-driven platform with preference-based navigation improves the buyer's experience of an online marketplace. That claim is testable, so it is stated as a pair.

H0: A preference-based keyword and image-navigated market web application does not improve the efficiency of customer purchase decisions compared with conventional filtered search.

H1: A preference-based keyword and image-navigated market web application improves the efficiency of customer purchase decisions compared with conventional filtered search.

Outcomes

Two outcomes are expected. The first is the artefact: a working application with a refreshed dataset and a navigation design that can be demonstrated and inspected. The second is a measured result, reporting whether the navigation design changed how long the comparison took and how confident the user was in the choice they made.

A third, smaller outcome is methodological. The project produces a documented scraping and validation pipeline for listings drawn from several sources, and a record of where those sources disagree with each other. That record is useful beyond this project, because inconsistency between sources is the standing problem for any comparison platform.

Background

Online marketplaces are now one of the common shapes an internet business takes, but they are not the most common. Schmuck (2021) analysed 700 websites and mobile applications against ten online business model types and found the intellectual property landlord model in use in the majority. In the breakdown of model implementations the paper charts, that model accounts for 218 of 382 and the online marketplace for 27, about 7%. The first chart above shows the split. For this proposal the point is that the marketplace pattern is well established and not saturated, which is the case for building another one.

Implemented online business models in Schmuck's breakdown, by model type

Chart data

Item	Value (implementations)
Intellectual property landlord	218 implementations
Intellectual property broker	108 implementations
Online marketplace	27 implementations
Intellectual property creator	12 implementations
HR broker	9 implementations
Five other models combined	8 implementations

Mobile share of website traffic worldwide, fourth quarter of each year, 2015 to 2025

Chart data

Point (%)	Mobile share of web traffic, Q4
2015	38.43%
2016	48.33%
2017	51.12%
2018	47.19%
2019	52.6%
2020	52.2%
2021	54.4%
2022	59.16%
2023	54.67%
2024	62.54%
2025	51.29%

What decides whether a marketplace is used is the interface rather than the catalogue. Chou et al. (2020) set marketing strategy against the components of attitude to identify the factors that shape customer behaviour, and information quality, pricing and satisfaction are among them. A platform that presents accurate, current information is therefore working on a factor the literature already treats as decisive, which is a stronger position than competing on catalogue size.

The second background fact is where that interface is used. Mobile devices accounted for 31.16% of website traffic worldwide in the first quarter of 2015 and 54.67% in the fourth quarter of 2023 (Statista, 2026). The second chart above plots the year-end values. The full quarterly series is noisier than the headline suggests: it passes 50% in the first quarter of 2017, falls back to 47.19% in the last quarter of 2018, and peaks at 59.54% in the third quarter of 2022. Since the proposal was written it has reached 62.73% in the second quarter of 2025 and fallen to 51.48% a year later. A comparison interface for high-value goods therefore has to work on a small screen first, and the preference-based navigation this project proposes is partly a response to that constraint, because filter-heavy search is what small screens handle worst.

The third fact is about the data itself. Boegershausen et al. (2022) document web scraping as an established method for building marketing datasets and set out what it costs to do properly: source selection, legal and ethical constraints, and the validation work that turns collected pages into a usable dataset. That work is the part students most often leave out of a proposal, and it is the part that determines whether the application has anything current to show.

Which Tools and Technologies Does the Project Use?

Python with Django on the server, HTML, CSS and JavaScript on the client, MySQL for the database and Bootstrap for styling, with Docker for portable deployment. Django was chosen for its built-in protection against SQL injection, cross-site scripting and request forgery, and for the admin interface that comes with it.

The five tool choices in this proposal, each against its obvious alternative

Point of comparison	Chosen	Alternative	Reason given
Server language	Chosen Python	Alternative JavaScript	Reason given The scraping and validation pipeline is the largest single piece of work, and Python's data-handling libraries shorten it
Web framework	Chosen Django	Alternative Flask	Reason given Authentication, an admin interface and an object-relational mapper come built in; written by hand they cost a fortnight of the eight weeks
Database	Chosen MySQL	Alternative A document store	Reason given The listing schema is stable and the queries are relational
Styling	Chosen Bootstrap	Alternative Hand-written CSS	Reason given Styling is not the part being marked
Deployment	Chosen Docker	Alternative Manual setup on each machine	Reason given The application runs the same way on the development machine and the marker's, which removes one category of demonstration failure

Each choice is made against the obvious alternative rather than by preference. Python over JavaScript on the server, because the scraping and validation pipeline is the largest single piece of work and Python's data handling libraries shorten it. Django over Flask, because the authentication, admin and object-relational mapper that Django ships are otherwise a fortnight of the eight working weeks available. MySQL over a document store, because the listing schema is stable and the queries are relational. Bootstrap over hand-written CSS, for the same reason: it is not the part being marked. Docker is used so that the application runs the same way on the development machine and on the marker's, which removes a category of problem from the demonstration.

Farshidi et al. (2021) built a decision model for programming language ecosystem selection from seven industry case studies, and the lesson a student proposal should take from it is that the choice is made against constraints such as available skill, library support and deadline, not against a general claim about which language is best. Stating those constraints is what turns a tools section from a list into an argument.

Design and Implementation

The application is built in three layers. The collection layer runs scheduled scrapers against listing sources, normalises the fields each source uses, and writes candidate records with a source identifier and a timestamp. The validation layer resolves duplicates, drops records that fail range or type checks, and flags conflicts between sources rather than silently preferring one. The presentation layer serves the surviving records through Django views, with keyword search, image navigation and preference-based sorting over them.

The interface is designed for a small screen first and widened for a desktop. Listings carry a price, a specification summary, an availability state and the age of the record, because a comparison platform that hides how old its data is has given up the thing it claims to offer. Docker images cover the application, the database and the scheduler, so that the whole system can be started with one command for the demonstration and the viva.

Future Insights: AI Integration and Real-Time Data Expansion

Two extensions are outside the scope of this project but shape how it is built. The first is recommendation. Zhang, Lu and Jin (2021) survey how artificial intelligence is used in recommender systems, and the relevant point for this design is that a recommender needs interaction data to learn from, which this application would have to collect and store before any model could be trained on it. The data model is therefore designed to record which listings a user compared and in what order, even though nothing in this project consumes that record.

The second is engagement measurement. Gupta et al. (2020) set out a framework for integrating new technologies into digital analytics, running from the external forces on a firm through its capabilities to the insights and outcomes it can produce, and Bag et al. (2022) examine how AI technologies affect user engagement and conversion in online retail. The design requirement this project takes from both is that instrumentation has to be decided before launch, because engagement data cannot be reconstructed afterwards. The application logs the events a later study would need, and stops there.

What Does the Literature Say About Real-Time Data and Consumer Decisions?

Three findings recur. Buyers rely on current rather than historical data when comparing high-value goods, so a stale dataset undermines the whole proposition. Scraping is the practical way to keep that dataset fresh, and it carries its own costs. And interface quality, not data volume, decides whether people return to a comparison platform.

Start with the data. Boegershausen et al. (2022) treat scraping as a research method with a procedure attached: choose the sources deliberately, work inside the legal and ethical limits of the sites involved, and validate what comes back before analysing it. Khder (2021) reviews scraping and crawling techniques and their applications, and the practical contribution is the comparison of approaches, because the choice between parsing rendered pages and consuming an interface determines how fragile the pipeline is when a source changes its markup. For a dissertation project, fragility is the risk that matters, because a scraper that breaks in week six takes the evaluation with it.

Next, what the freshness is for. Chou et al. (2020) identify the factors that shape customer behaviour from an integrated marketing and attitude perspective, and information is one of them alongside price and satisfaction. Shahid and Sheikh (2021) review the effect of large-scale data on decision-making and competitive advantage and reach a similar conclusion from the firm's side: the value is in the decision the data supports, not in the volume collected. Both readings point the same way for this project. The application is not competing on how much it holds; it is competing on whether what it shows is true at the moment it is read.

Then the interface. Stocchi et al. (2022) review marketing research on mobile apps and map where the field has concentrated, and the recurring theme is that the experience of using the application, rather than its feature list, is what predicts continued use. Tolstoy et al. (2022) find that online marketing capabilities affect e-commerce performance indirectly, through what those capabilities let a firm do, rather than directly. For a comparison platform that means the navigation design is not cosmetic. It is the mechanism through which the data has any effect at all, which is why it is the thing this project's hypothesis tests.

Finally the framework. Bakshi et al. (2020) compare Django with Spring and describe Django's aims as simplicity, flexibility, reliability and scalability. Django's own documentation is more specific and more useful to a student, setting out the framework's protections against cross-site scripting, cross-site request forgery, SQL injection and clickjacking, together with the deployment settings those protections depend on (Django Software Foundation). A proposal that cites the documentation rather than a survey paper for this is doing the right thing, because the documentation is what the implementation will actually be written against.

What Are the Challenges and Opportunities?

The challenges are scalability under load, inconsistency in scraped data, and the security burden of holding personal data. The opportunities are machine-learning personalisation, reach beyond a single geography, and interface features such as augmented reality product views. Naming both, with mitigations, is what a supervisor looks for in this section.

Challenges

Scalability and technical complexity come first. As the user base grows, the application has to absorb more traffic without response times degrading. Django's own documentation treats caching as the first answer to that problem, and sets out per-site, per-view and low-level caching alongside database and template optimisation (Django caching documentation). Database indexing, query reduction and load balancing across application servers do the rest. Scraping introduces a second problem at the same layer: records pulled from different sources disagree with one another, so the pipeline needs de-duplication and validation rules before anything reaches a user.

Security is the other major concern, because the application holds personal data. The OWASP Top 10 for 2025 ranks broken access control, security misconfiguration and software supply chain failures as the three most common categories of web application risk (OWASP, 2025). The third of those is worth noting in a student project specifically, because a Django application pulls in dozens of packages and the dependency list is the part nobody reviews. Django documents its own defences against cross-site scripting, cross-site request forgery, SQL injection and clickjacking, together with the deployment settings that have to be right for those defences to hold (Django security documentation). Encryption in transit and at rest, regular dependency updates and an audit of the authentication flow are standing tasks rather than one-off ones.

Opportunities

Machine learning is the first opportunity. A recommender trained on comparison histories could rank listings against a user's revealed preferences rather than their stated ones, and Zhang, Lu and Jin (2021) survey the methods available for exactly that problem. The constraint is data: the model needs interaction histories that do not exist until the application has users, which is why this project builds the logging and stops.

Reach is the second. A comparison platform has no inherent geographic limit beyond the sources it scrapes, so extending it is a matter of adding sources and handling their formats rather than rebuilding anything.

Interface features are the third. Augmented reality product views, which let a buyer place a piece of furniture in a room or inspect a vehicle before travelling to see it, are already shipped by large retailers and would suit a category where the purchase is high value and the viewing is inconvenient. Guided virtual tours and a support chatbot cover questions a static listing page cannot answer. Each of these differentiates the application from a plain listings site, and each is a separate project rather than an extension of this one.

Project Plan and Gantt Chart

The plan, drawn as a Gantt chart in the proposal and reproduced above, runs from the initial report submission on 2 August to final submission on 30 September, with eight working weeks in between and eleven milestones. Weeks 1 and 2 cover the dissertation introduction, the literature review and practice web development, so that the writing and the technical preparation happen alongside each other rather than in sequence. Weeks 3 to 5 cover building the application, refining the code and beta-testing it with users, which is where the data comes from. Weeks 5 and 6 are data analysis, weeks 6 and 7 the first draft revision, and week 8 the final check before submission.

The dissertation project plan, weeks 1 to 8, as drawn in the proposal's Gantt chart

Weeks

1 2 3 4 5 6 7 8

1. Starting dissertation introduction

   Week 1

2. Conducting literature review

   Weeks 1–2

3. Practising web development

   Week 2

4. Developing web application

   Weeks 3–4

5. Refining coding

   Weeks 3–4

6. Beta-testing web app for data collection

   Weeks 3–5

   Cannot start until the application runs; this is where the evaluation data comes from.

7. Data analysis from results

   Weeks 5–6

8. First dissertation draft revision

   Weeks 6–7

9. Final draft checking

   Week 8

Timeline data

Phase	Start (week)	End (week)
Starting dissertation introduction	1	1
Conducting literature review	1	2
Practising web development	2	2
Developing web application	3	4
Refining coding	3	4
Beta-testing web app for data collection	3	5
Data analysis from results	5	6
First dissertation draft revision	6	7
Final draft checking	8	8

Two dependencies decide whether the plan holds. Beta-testing cannot start until the application runs, so any slippage in development pushes data collection and therefore the analysis. The analysis then has to finish before the draft revision, because the findings chapter is what the revision is for. For what a finished findings chapter looks like, with the SPSS output for each test, see our findings and discussion chapter on agile project management. A supervisor reads a Gantt chart for exactly this: whether the critical path leaves room for the work to go wrong once.

The plan above also shows where the float is. Weeks 1 and 2 carry writing that can be moved, which is the only slack in the plan, so a delay in development has to be absorbed there or not at all. Saying that in the proposal is better than presenting a chart with no risk in it, because a supervisor who cannot see the risk assumes it has not been thought about.

Conclusion

The proposed application, "In the Market", helps a buyer compare high-value goods by holding current data and presenting it through preference-based keyword and image navigation. The technical contribution is the collection and validation pipeline that keeps the dataset current; the research contribution is a measured answer to whether the navigation design shortens the comparison task, stated as a testable hypothesis rather than as a claim.

The risks are named with mitigations: caching and indexing against load, validation rules against source disagreement, and the security settings Django documents against the categories OWASP ranks highest. The opportunities in recommendation, wider geographic reach and richer interface features are set out as later work, with the logging this project needs in order for any of them to be possible. What the work produces at the end is one artefact and one result, which is what a masters proposal should promise.

Need help with a computer science dissertation or research proposal? Message us on WhatsApp with the brief, your supervisor's requirements and the deadline.

Sources

• Bag, S., Srivastava, G., Bashir, M.M.A., Kumari, S., Giannakis, M. and Chowdhury, A.H., 2022. Journey of customers in this digital era: understanding the role of artificial intelligence technologies in user engagement and conversion. Benchmarking: An International Journal, 29(7), pp.2074-2098. https://doi.org/10.1108/BIJ-07-2021-0415
• Bakshi, N., Kumar, P., Rastogi, A. and Surya, D., 2020. Spring framework vs Django framework: a comparative study. International Research Journal of Engineering and Technology, 7(6), pp.6232-6236. https://www.irjet.net/archives/V7/i6/IRJET-V7I61162.pdf
• Boegershausen, J., Datta, H., Borah, A. and Stephen, A.T., 2022. Fields of gold: scraping web data for marketing insights. Journal of Marketing, 86(5), pp.1-20. https://doi.org/10.1177/00222429221100750
• Chou, S.F., Horng, J.S., Liu, C.H.S. and Lin, J.Y., 2020. Identifying the critical factors of customer behavior: an integration perspective of marketing strategy and components of attitudes. Journal of Retailing and Consumer Services, 55, 102113. https://doi.org/10.1016/j.jretconser.2020.102113
• Django Software Foundation. Django documentation: caching. https://docs.djangoproject.com/en/stable/topics/cache/ [Accessed 19 September 2026]
• Django Software Foundation. Django documentation: security in Django. https://docs.djangoproject.com/en/stable/topics/security/ [Accessed 19 September 2026]
• Farshidi, S., Jansen, S. and Deldar, M., 2021. A decision model for programming language ecosystem selection: seven industry case studies. Information and Software Technology, 139, 106640. https://doi.org/10.1016/j.infsof.2021.106640
• Gupta, S., Leszkiewicz, A., Kumar, V., Bijmolt, T. and Potapov, D., 2020. Digital analytics: modeling for insights and new methods. Journal of Interactive Marketing, 51(1), pp.26-43. https://doi.org/10.1016/j.intmar.2020.04.003
• Khder, M.A., 2021. Web scraping or web crawling: state of art, techniques, approaches and application. International Journal of Advances in Soft Computing and Its Applications, 13(3), pp.144-168.
• OWASP Foundation, 2025. OWASP Top 10:2025. The ten most critical web application security risks. https://owasp.org/Top10/2025/
• Schmuck, R., 2021. The use of online business models. Procedia Manufacturing, 54, pp.45-51. https://doi.org/10.1016/j.promfg.2021.07.008
• Shahid, N.U. and Sheikh, N.J., 2021. Impact of big data on innovation, competitive advantage, productivity and decision making: literature review. Open Journal of Business and Management, 9(2), pp.586-617. https://doi.org/10.4236/ojbm.2021.92032
• Statista, 2026. Share of web traffic from mobile devices worldwide from 1st quarter 2015 to 2nd quarter 2026 (StatCounter data, released 29 July 2026). https://www.statista.com/statistics/277125/share-of-website-traffic-coming-from-mobile-devices/ [Accessed 24 September 2026]
• Stocchi, L., Pourazad, N., Michaelidou, N., Tanusondjaja, A. and Harrigan, P., 2022. Marketing research on mobile apps: past, present and future. Journal of the Academy of Marketing Science, 50, pp.195-225. https://doi.org/10.1007/s11747-021-00815-w
• Tolstoy, D., Nordman, E.R. and Vu, U., 2022. The indirect effect of online marketing capabilities on the international performance of e-commerce SMEs. International Business Review, 31(3), 101946. https://doi.org/10.1016/j.ibusrev.2021.101946
• Zhang, Q., Lu, J. and Jin, Y., 2021. Artificial intelligence in recommender systems. Complex and Intelligent Systems, 7(1), pp.439-457. https://doi.org/10.1007/s40747-020-00212-w

Related samples: how data mining improves e-commerce personalisation, report on mobile cloud computing, final project ideas for computer science students, Boolean algebra and logic circuits, and how to select a dissertation topic.