The system runs. Login works, the dashboard loads, the reports export, and the demo you gave last week went fine. The manuscript is fourteen pages, most of which is the title page, the approval sheet and a table of contents pointing at chapters that do not exist. The final defence is in three weeks.
This is the standard failure mode of a Philippine IT or computer science capstone, and it is not a discipline problem. It happens because building the system felt like progress — it was measurable, it compiled, it produced something you could show — and documentation had no equivalent feedback loop, so it kept losing to the sprint.
The good news is specific and worth internalising before you panic: you are not starting from zero. Most of your manuscript already exists as artifacts you built months ago. It is in the wrong format, scattered across the wrong tools, and it has never been written down as prose — but it exists.
What you already have, and which section it becomes
Go through your repository, your drive folder and your group chat before you write a word. Almost everything below is already sitting there.
| Artifact you already built | Where it belongs in the manuscript |
|---|---|
| Entity-relationship diagram, database schema | System design, Chapter 3 |
| Use case diagrams, data flow diagrams, context diagram | System design, Chapter 3 |
| The methodology you actually followed — Agile sprints, prototyping, waterfall | Development methodology, Chapter 3 |
| Commit history and sprint board | Evidence for the development timeline |
| Hardware and software specifications of your dev and target machines | Technical requirements, Chapter 3 |
| Test cases and their results | Testing procedure, Chapters 3 and 4 |
| Screenshots of every module | System output, appendix, referenced from Chapter 4 |
| README and setup steps | User manual, appendix |
| The problem you set out to solve, from your title defence | Background and statement of the problem, Chapter 1 |
Two hours with that table and a folder open converts a blank document into an outline with content assigned to every heading. Do that before you write prose, in the same way a quantitative group builds its tables before writing paragraphs.
The one thing you almost certainly do not have
Evaluation data.
A capstone manuscript is not judged on whether the system works. It is judged on whether you can show, with evidence, that it works and that its intended users find it acceptable. That evidence comes from an evaluation survey administered to real respondents, and it is the single most commonly missing component when a system is finished and a manuscript is not.
It is also the component with a hard lead time. You cannot write it on the last weekend, because you need respondents, and respondents need scheduling. If you do nothing else this week, do this one.
Three practical decisions:
- Who evaluates. Your actual intended users — the office staff, the teachers, the barangay clerks the system was built for — plus, where your department requires it, a small number of IT experts evaluating the technical criteria. Your groupmates are not respondents.
- Against what criteria. Take these from your department’s current capstone template, not from a previous group’s manuscript. Many Philippine templates evaluate against ISO/IEC 25010, the software product quality standard, and the standard exists in more than one edition — a 2011 edition and a 2023 revision — so a template copied from an older thesis can send you into criteria your department no longer uses. Check the edition your own template names.
- On what scale. Whatever your manual specifies, usually a four- or five-point Likert scale with a verbal interpretation band per range.
Let them use the system first, then answer. An evaluation collected from people who only watched a demo is a defect a panel finds by asking one question about how the respondent used the system.
Chapter 4 for a capstone is an evaluation chapter
This is where IT groups get surprised. Your results chapter is not a description of your system — the system belongs in Chapter 3. Chapter 4 reports what your evaluation produced, and it is built exactly like any other quantitative results chapter: one table per specific problem, in the order of your statement of the problem, each followed by an interpretation paragraph.
The usual shape is a weighted mean per criterion with its standard deviation and a verbal interpretation, plus an overall mean. The rules for building that table — the APA anatomy, the decimal conventions, and the three-move paragraph that goes underneath — are the same ones every thesis follows, and they are set out in the guide to writing Chapter 4 table by table. Which statistic answers which kind of problem is covered in the statistical treatment of data in a thesis, and if you are computing the means in software rather than by hand, the procedure is in analysing thesis data in SPSS step by step.
One structural point that saves a rewrite: the criteria in your evaluation instrument, the sub-sections of your Chapter 4 and the specific problems in your Chapter 1 must be the same list, in the same order. If Chapter 1 asks about four criteria and your instrument measures six, one of those two documents is wrong, and it is easier to fix now than after the tables are built.
The three-week plan
- Week 1. Build and administer the evaluation instrument. In parallel, do the artifact mapping above and paste every diagram into the right section with a caption and a figure number. Write nothing polished yet.
- Week 2. Write Chapters 1 and 3 from the artifacts. These are the most mechanical chapters in a capstone, because the content is decisions you already made and can now simply record. Assemble the appendices — screenshots, user manual, instrument, test cases.
- Week 3. Tabulate the evaluation, write Chapter 4, then write Chapter 5 from Chapter 4 without adding anything new. Reserve the last two days for reconciliation.
Reconciliation means the boring checks that panels find first: the respondent count identical in Chapter 3, every Chapter 4 table and the abstract; every figure and table numbered and referred to by number in the text; the criteria list matching across Chapter 1, the instrument and Chapter 4. How the five chapters have to agree with one another is summarised in the overview of Chapters 1 to 5, and if you are still unclear how a capstone differs from a thesis in what it must prove, that distinction is in the difference between a thesis and a capstone project.
Expect the chapters to come back with comments, and do not treat that as lost time — it is the normal shape of the last three weeks. Sorting those comments by what they actually cost, before editing anything, is covered in what to do when your adviser wants Chapter 4 rewritten by Monday.
What a capstone writing tool can and cannot do
Be clear-eyed about this, because the failure mode here is specific.
It cannot describe your system. Nobody else knows why you chose a normalised schema over a document store, what your third sprint actually delivered, or why the reports module was descoped. Those are your decisions and the manuscript is the record of them. A generic description of “a web-based management system” is exactly what a panel will pick apart, because it could have been written about any project.
It cannot invent your evaluation results. Numbers come from respondents. This should be obvious and it is worth stating anyway, because the temptation peaks at exactly the point in the calendar you are probably at now, and a fabricated evaluation is the one defect that ends a capstone rather than delaying it.
What it is good at is holding the structure and keeping it consistent — a chapter skeleton in the order your manual specifies, sections that stay in the right place while you fill them from your artifacts, and citations tied to sources you actually opened. For a group whose difficulty is that documentation has no structure rather than that they cannot write, that is most of the problem.
The system is built. Put the manuscript around it.
Tesify holds your chapters in the structure your capstone manual expects, so your diagrams, test cases and evaluation results land in the right sections instead of a growing folder of loose files — and every citation stays attached to the source you actually opened. Over 9,000 students have used it to write more than 15,000 chapters, and every word is still written by you.
Frequently asked questions
How do I write capstone documentation when the system is already finished?
Map your existing artifacts to manuscript sections first — diagrams and schema to Chapter 3, test cases and screenshots to Chapter 4 and the appendices, your title-defence problem to Chapter 1. Then administer the evaluation survey immediately, because it is the only component with a lead time you cannot compress.
What goes in Chapter 4 of a capstone project?
The evaluation results, not a description of the system. Typically a weighted mean and standard deviation per criterion with a verbal interpretation, one table per specific problem, each followed by a paragraph interpreting it. The system itself is described in Chapter 3.
Who should evaluate our system?
The intended users, plus IT experts where your department requires a technical panel. Your own groupmates are not respondents, and an evaluation from people who only watched a demo will not survive a question about how they used the system.
What criteria should the evaluation use?
Whatever your department’s current capstone template specifies. Many Philippine templates use ISO/IEC 25010, which exists in more than one edition, so take the criteria from your own template rather than from a previous group’s manuscript.
How many evaluators do we need?
Your manual usually states a minimum, and it is normally far smaller than a survey thesis requires. Ask your adviser for the number your department expects rather than guessing, because recruiting five more people late is much harder than recruiting them now.
Can we write the documentation before the evaluation?
Yes, and you should. Chapters 1 and 3 depend on decisions you already made, so write them while the evaluation is out with respondents. Only Chapters 4 and 5 need the results.
Do screenshots go in the chapters or the appendix?
Usually the appendix, referenced by figure number from the relevant chapter, with a small number of key interfaces reproduced in the body. Follow your manual, and make sure every figure is numbered and mentioned in the text.
Our system changed after the title defence. Do we document the original or the final?
The final one, with the change and its reason stated. A descoped module explained in one honest sentence is normal engineering; a manuscript describing features the demo does not contain is a discrepancy the panel will find in the first five minutes.
Is a capstone manuscript shorter than a thesis?
Not reliably. It carries appendices a survey thesis does not — user manual, test cases, screenshots, source documentation — which often makes the bound document thicker even when the chapters are tighter.
The panel liked the demo. Does the manuscript still matter?
It is what you are graded and archived on. A working system with a thin manuscript is the most common reason a capstone is deferred rather than failed, and it is entirely avoidable with three weeks of structured work.