Getting help with your capstone system: what is fair, what to ask, and what to avoid

Plenty of students get outside help with their capstone system, and schools expect some of it. Advisers, senior students, online tutorials, and professional developers all play a part. The line that matters is simple: on defense day you must be able to explain and operate the system yourself.

What is normally acceptable

• Consultation on scope, architecture, stack, and database design.
• Help building the system, as long as you take part and can explain every module.
• Code review and debugging of code you wrote.
• Setting up hosting, deployment, and test data.
• Support for the technical sections of the manuscript, such as diagrams and test plans, that describe the real system.
• A mock defense and a walkthrough of the code before the real one.

What is not acceptable anywhere is submitting a system or a manuscript you did not take part in and cannot explain. Your capstone manual will have its own rules on authorship and academic honesty, so read it and follow it.

Questions to ask before you pay anyone

• Will you walk me through the code, module by module, until I can explain it to a panel?
• Can we use the stack my school requires?
• Who owns the source code at the end? The answer should be you, with the full repository handed over.
• How are revisions after the proposal or final defense handled, and for how long?
• What is the milestone plan, and what do I see at each milestone?
• What are the payment terms? Expect a deposit, milestone payments, and a final payment on handover.
• What happens if the panel asks for a change you did not plan for?

A developer who cannot answer these clearly is not the right one.

Red flags

• A finished system offered in days for a tiny amount. It is usually a renamed copy of a free project, and plagiarism checks and panel questions will expose it.
• No walkthrough offered, or an extra fee just to explain the code.
• Refusal to hand over the full source code and database schema.
• No written scope. Verbal agreements fall apart at the first revision request.
• Promises about grades or panel outcomes. Nobody can promise those.

How to stay in control

• Keep the repository under your own account and give the developer access, not the other way around.
• Join the build sessions. Even watching the database schema take shape teaches you what the panel will ask.
• Write the objectives and scope yourself, then hand them to the developer as the brief.
• Test every feature yourself against the objectives before you accept a milestone.
• Explain the top five functions out loud to a teammate before the defense.

How Karakoa works with students

We build capstone and thesis systems with consultation included. You get a scope that fits your calendar, milestone demos, the full source code and documentation support, a module-by-module walkthrough, and revisions after panel feedback. We do not write or submit manuscripts on a student’s behalf, and we only take projects where the student is involved enough to defend the work. Pricing is quoted after a short call, based on scope. See the capstone and thesis service page for what is included.