One month is enough time to build, document and defend a final year project — but only a specific kind of project, built in a specific order. The mistake that sinks students at this stage is not working too slowly. It is refusing to cut the idea down to something a month can actually hold. This is the plan that fits.
Read the honest version first: a month buys you one core feature, built properly, documented to match, and understood well enough to explain. It does not buy you a five-module platform, original research, or the polish you imagined in September. Accept that in week one and the plan works. Fight it and you arrive at the viva with three half-finished features and a report that describes none of them.
Week 1 — Lock scope and write the synopsis
Spend the first day deciding what you are not building. Take whatever the idea was and reduce it to the single flow that makes it that project: for an e-commerce site, place an order end to end; for a chat app, two users exchanging messages in real time; for an ML project, one model that classifies one thing. Everything else is future scope.
Before you write a line of application code, finish these:
- A frozen feature list — what it will do, and explicitly what it will not
- The synopsis, submitted and approved by your guide
- The repository, database and empty screens scaffolded
- A rough ER diagram you will keep true to the code as you go
Get the synopsis approved this week without fail. A topic rejected in week two of a four-week plan is not a setback, it is the end of the plan. If you are unsure of the format, the synopsis format guide has the structure most departments expect.
Week 2 — Build the core, and only the core
This is the week you build the one flow from week one, front to back, and nothing else. Resist every instinct to add a second feature, a nicer UI, or a login system you do not strictly need. Get the core working, then stop.
Seed realistic data as you go — real names, real products, real prices. Screenshots full of “asdf” and “test test” are one of the clearest signals to a panel that a project was rushed. The moment the core flow works end to end, you have a submittable project. Everything after this point is documentation and defence, not building.
If you can already tell the build is slipping past this week — the core will not come together, or you are stuck on something you cannot solve — do not spend week three hoping it resolves. Read the honest fix for being stuck and make the call early, while you still have three weeks of options.
Week 3 — Test, capture evidence, and write the report
Two jobs run in parallel this week. First, test the system properly and write it down: a test case table with input, expected output, actual output, and a pass or fail column. Include failure cases — invalid input, an empty form, an unauthorised action — because a table of only passes reads as fabricated, while one that shows bad input being caught reads as engineering.
Second, write the report while the decisions are still fresh. Do not save it for the end — a report written the night before submission always looks like one. Draft it chapter by chapter, and follow the report format guide so you do not lose easy marks on structure. The single rule that matters: the report must describe the code you are actually submitting.
Week 4 — Buffer, diagrams, and viva preparation
The last week is deliberately light on new work, because something always breaks and you need the room. Use it to:
- Reconcile every diagram — ER, DFD, use case — to the code as it now is
- Fix the bugs that testing surfaced in week three
- Rehearse the two-minute project overview out loud, more than once
- Keep the final two or three days as pure buffer, building nothing
Preparing for the viva is not a week-four afterthought — it is half of your marks. Walk through how to explain your project confidently and rehearse against the questions panels actually ask. A project you built but cannot explain scores like a project you did not build.
What a month cannot do — and the honest alternative
Everything above assumes you have four clear weeks and can give them to this. If the real number is smaller — you have ten days, or exams eat two of the four weeks, or the build has already failed once — then the plan does not fit, and pretending it does is how projects arrive at the viva broken.
When the timeline is genuinely gone, the safe route is a project that is already built and documented, then walked through with you in daily live sessions until you can explain every part of it yourself. That is not a shortcut around understanding the work — it is the fastest honest path to understanding it when there is no time left to build from zero. Every tier ships with the full source code, the report, and line-by-line viva preparation, and seats are capped per college so two students never walk in with the same submission.
If a month is what you have, this plan uses it well — start from a project close to your idea so week one is a head start rather than a blank page. If the month is already gone, the honest option is a build to your problem statement with the documentation and viva prep done alongside it. Two projects that fit a crunch well are the MERN e-commerce store and the real-time chat app — both have one clear core flow you can lock in week one.