I. Introduction

A common dispute in thesis-related software development arises when a student or group of students hires a programmer, developer, capstone consultant, or software service provider to build a thesis system, mobile application, website, database, machine learning prototype, or similar academic project, but the work is left unfinished despite payment. In the Philippines, this situation is generally governed by contract law, particularly the Civil Code provisions on obligations and contracts, damages, unjust enrichment, and, depending on the facts, possible criminal liability for deceit or fraud.

The legal question is usually straightforward: Was there a valid agreement, was payment made, did the developer fail to deliver what was promised, and what remedies are available to recover the money or compel performance?

The answer depends heavily on proof. Philippine law does not require every service agreement to be notarized or even written to be enforceable, but written evidence greatly strengthens the claim.

II. Nature of the Agreement

A thesis software project arrangement is usually a contract for services or a contract for a piece of work. The student-client agrees to pay, while the developer agrees to produce a defined output, such as:

a working thesis software system;
source code;
database files;
documentation;
deployment files;
revisions required by the thesis adviser or panel;
defense-ready software;
user manuals or technical documentation;
post-defense fixes or support.

Even when the parties casually discuss the project through Messenger, email, Telegram, Viber, SMS, or verbal conversations, a contract may still exist if the essential elements are present.

Under Philippine contract law, a valid contract generally requires:

Consent — both parties agreed;
Object — the project or service to be delivered;
Cause or consideration — payment in exchange for the work.

Thus, even a chat conversation can show a binding agreement if it identifies the work, price, deadline, and parties’ commitments.

III. When There Is Breach of Contract

A breach occurs when one party fails to comply with what was agreed upon. In an unfinished thesis software project, breach may occur when the developer:

fails to complete the system;
abandons the project;
misses agreed deadlines;
delivers unusable, defective, or incomplete software;
refuses to make agreed revisions;
fails to provide source code or project files;
stops communicating after receiving payment;
demands additional payment without basis;
delivers something substantially different from what was promised;
represents the project as nearly complete when it is not.

Not every delay automatically amounts to breach. The facts matter. A court or barangay authority may ask whether the delay was justified, whether the client also caused delays, whether requirements changed, or whether the parties agreed to extend the deadline.

However, where the developer received payment and failed to deliver the promised output within a reasonable or agreed period, the paying party may have a valid claim.

IV. Importance of the Agreement’s Terms

The strongest claims are those supported by clear terms. Relevant terms include:

1. Scope of Work

The parties should identify what exactly must be delivered. For thesis software, this may include:

modules and features;
login system;
admin panel;
reporting function;
database design;
mobile or web interface;
testing;
source code;
documentation;
hosting or deployment;
revisions after adviser feedback.

If the agreement only says “make my thesis system,” disputes become harder because the scope is vague.

2. Price and Payment Schedule

The client should prove how much was agreed and how much was paid. Payments may be shown through:

GCash receipts;
Maya receipts;
bank transfers;
remittance slips;
screenshots;
acknowledgment messages;
invoices;
receipts;
emails confirming payment.

3. Deadline

Deadlines matter greatly in thesis projects because academic submissions are time-sensitive. A missed deadline can cause serious consequences, such as failed defense, delayed graduation, or additional school expenses. If the developer knew the academic deadline, this supports a claim for damages.

4. Deliverables

The agreement should state what constitutes completion. A system may be incomplete if it lacks core features, cannot run, has no database, has no source code, or cannot be demonstrated during defense.

5. Revisions

Thesis systems usually require revisions after adviser or panel review. The agreement should specify whether revisions are included and how many rounds are covered.

V. Legal Remedies Available

A paying student or client may seek several remedies.

A. Specific Performance

The client may demand that the developer finish the project. This is called specific performance, where the debtor is compelled to perform the obligation.

However, in software development disputes, specific performance may be impractical if trust has broken down, the deadline has passed, or the developer is no longer capable or willing to complete the work. In such cases, recovery of payment and damages may be more realistic.

B. Rescission or Cancellation of the Contract

If the developer substantially failed to perform, the client may seek cancellation or rescission of the agreement. The idea is to undo the contract because one party failed to comply.

In practical terms, the client asks for:

return of the amount paid;
cancellation of any remaining balance;
possibly damages.

Rescission is especially appropriate where the unfinished project is no longer useful because the thesis deadline has passed.

C. Refund or Recovery of Payment

The most common remedy is to demand a refund. The amount recoverable depends on the circumstances.

The client may claim a full refund if:

no meaningful work was delivered;
the delivered work is unusable;
the developer abandoned the project;
the developer failed to deliver by the required deadline;
the partial output has no practical value.

A partial refund may be appropriate if:

some usable work was completed;
the client accepted part of the output;
the developer can prove substantial work already done;
the unfinished portion can be valued separately.

The developer cannot simply say “no refund” if the work was not completed. A “no refund” term may not protect a party who failed to perform the basic obligation.

D. Damages

Damages may be claimed if the client suffered losses because of the breach. Possible damages include:

1. Actual or Compensatory Damages

These are proven losses, such as:

amount paid to the original developer;
additional amount paid to another developer to redo or complete the system;
additional school fees caused by delay;
re-enrollment expenses;
printing, documentation, or defense-related costs wasted due to non-delivery;
hosting or software expenses wasted.

Actual damages require proof, such as receipts, payment records, school billing statements, or invoices.

2. Moral Damages

Moral damages may be claimed in certain cases involving bad faith, fraud, harassment, or serious emotional suffering. However, moral damages are not automatically awarded in ordinary breach of contract cases. The claimant must show a legal basis and convincing facts.

Examples that may support a claim include:

intentional deception;
repeated false promises;
humiliating or abusive conduct;
bad faith refusal to return money;
conduct causing serious distress beyond ordinary inconvenience.

3. Exemplary Damages

Exemplary damages may be awarded to set an example or deter similar wrongdoing, usually where the defendant acted in a wanton, fraudulent, reckless, oppressive, or malevolent manner.

4. Attorney’s Fees and Litigation Expenses

Attorney’s fees may be claimed when justified, such as when the claimant was compelled to litigate due to the other party’s unjustified refusal to satisfy a valid demand. They are not automatically awarded.

5. Nominal Damages

Nominal damages may be awarded when a legal right was violated but no substantial actual damages were proven.

VI. Unjust Enrichment

Even aside from breach of contract, the doctrine against unjust enrichment may apply. No person should unjustly benefit at another’s expense.

If the developer received money but did not deliver the agreed project, keeping the payment may constitute unjust enrichment. The law generally allows recovery where one party has been enriched and the other has suffered a corresponding loss without valid legal justification.

This is useful where the contract terms are incomplete but payment and non-delivery are clear.

VII. Possible Criminal Aspect: Estafa

Most unfinished service contracts are civil disputes, not criminal cases. However, criminal liability may arise if there was fraud or deceit from the beginning.

The possible offense is usually estafa, particularly if the developer obtained money through false pretenses or fraudulent representations.

A case may be more than a simple breach of contract if evidence shows that the developer:

never intended to complete the project;
used a fake identity;
falsely claimed expertise, progress, or credentials;
pretended the system was almost done to obtain more money;
accepted multiple payments while avoiding delivery;
disappeared after receiving payment;
used fabricated screenshots, fake demos, or copied work;
induced payment through deliberate lies.

The key distinction is this:

Civil breach means the developer failed to perform a promise. Estafa requires deceit or fraudulent intent, usually present before or at the time money was obtained.

Failure to finish alone does not automatically mean estafa. Courts generally require proof of deceit and criminal intent.

VIII. Barangay Conciliation

Before filing a court case, barangay conciliation may be required under the Katarungang Pambarangay system if the parties are individuals residing in the same city or municipality, or in nearby barangays covered by the rules.

The client may file a complaint before the barangay and seek mediation. The barangay may issue notices for confrontation and settlement.

Possible outcomes include:

refund agreement;
installment payment arrangement;
deadline to finish the project;
turnover of source code and files;
written settlement;
certificate to file action if settlement fails.

A barangay settlement is important because it can become enforceable. If no settlement is reached, the barangay may issue a Certificate to File Action, which may be needed before going to court.

Barangay conciliation may not apply in every case, such as when the parties live in different cities or municipalities not covered by the rules, when one party is a juridical entity, or when the dispute falls under exceptions.

IX. Small Claims Court

For recovery of money, the client may consider filing a small claims case if the claim falls within the allowed monetary threshold under current rules. Small claims proceedings are designed to be faster and simpler than ordinary civil actions.

In small claims:

lawyers are generally not allowed to appear for the parties during the hearing;
the process is simplified;
the claim is usually based on money owed;
evidence is submitted through forms and attachments;
the court may order payment if the claim is proven.

A small claims case may be suitable when the client seeks:

refund of payment;
reimbursement of additional costs;
recovery of a liquidated or definite amount.

It may be less suitable if the client primarily wants complex injunctive relief, detailed technical findings, or enforcement of intellectual property rights.

X. Ordinary Civil Action

If the amount, complexity, or remedy is beyond small claims, the client may file an ordinary civil case for breach of contract, damages, rescission, or specific performance.

An ordinary civil action may be appropriate where:

the amount involved is substantial;
there are complicated factual disputes;
expert testimony may be needed;
the client seeks damages beyond simple refund;
there are issues of fraud, intellectual property, or ownership of source code;
the defendant contests the scope or completion of work.

Ordinary civil litigation is usually slower, more technical, and more expensive than small claims.

XI. Demand Letter

Before filing a case, it is usually advisable to send a formal demand letter. A demand letter serves several purposes:

gives the developer a final chance to settle;
documents the client’s claim;
establishes that payment was demanded;
may support a later claim for attorney’s fees or damages;
may interrupt delay-related arguments;
may clarify whether the developer admits or denies liability.

A good demand letter should include:

names of the parties;
date and nature of the agreement;
amount paid;
promised deliverables;
agreed deadline;
summary of breach;
demand for refund, completion, or turnover of files;
deadline to comply;
warning that legal action may follow.

The tone should be firm, factual, and professional. Threats, insults, or defamatory statements should be avoided.

XII. Evidence Needed

The success of a claim depends on evidence. The claimant should preserve:

Contract Evidence

written agreement;
proposal;
quotation;
invoice;
chat messages;
emails;
screenshots of agreed scope;
messages confirming price and deadline.

Payment Evidence

GCash or Maya receipts;
bank transfer slips;
remittance receipts;
acknowledgment messages;
screenshots of payment confirmation;
proof of partial payments.

Breach Evidence

missed deadlines;
messages showing excuses or admissions;
incomplete files;
non-working software;
adviser or panel comments;
screenshots of bugs or missing modules;
proof of abandonment;
unanswered follow-ups.

Damage Evidence

school deadlines;
thesis calendar;
defense schedule;
proof of delayed graduation;
additional developer payments;
additional school fees;
receipts and invoices.

Identity Evidence

full name of developer;
phone number;
email address;
social media profile;
address if known;
payment account name;
business name, if any.

Screenshots should show dates, names, profile identifiers, and full conversation context. Edited or cropped screenshots may be challenged.

XIII. Issues Commonly Raised by Developers

A developer accused of breach may raise defenses such as:

1. The Client Changed the Requirements

The developer may argue that the client kept adding features not covered by the original price. This is common in software projects.

The client should distinguish between:

original agreed features;
reasonable corrections;
thesis panel revisions;
entirely new features.

2. The Client Failed to Provide Materials

The developer may claim delay was caused by the student’s failure to provide documents, datasets, flowcharts, credentials, hosting access, adviser feedback, or content.

3. Partial Completion

The developer may argue that work was partially completed and therefore no full refund is due. The court may consider the value of the partial work.

4. No Fixed Deadline

If no deadline was agreed, the developer may claim there was no breach yet. However, the law may still require performance within a reasonable time, especially where the developer knew the project was for a thesis defense.

5. The Work Was Accepted

If the client accepted the output, used it, or presented it during defense, the developer may argue substantial performance.

6. Academic Dishonesty

The developer may argue that the arrangement itself involved improper academic outsourcing. This does not automatically erase civil liability, but it may affect how the dispute is viewed, especially if the agreement involved doing work that the student was required to personally accomplish under school rules.

XIV. Academic and Ethical Considerations

A thesis software project has an academic dimension. Philippine schools often prohibit students from submitting outsourced work as their own. This may create risks separate from the legal dispute.

There is a difference between:

hiring someone to provide technical assistance, tutoring, debugging, UI improvement, deployment help, or consultation; and
paying someone to create the entire thesis project while the student falsely represents it as personal work.

The latter may violate school policies on academic integrity.

This matters legally because courts generally do not aid parties in enforcing illegal or immoral agreements. If the agreement is framed as academic fraud, the claimant may face difficulty. However, if the agreement was for legitimate programming assistance, tutoring, consultation, or completion of a paid technical service, the claim is stronger.

The safer framing is factual and neutral: the dispute concerns payment for software development services not completed, not an attempt to enforce academic dishonesty.

XV. Ownership of Source Code and Files

Another issue is whether the client is entitled to the source code and project files. The answer depends on the agreement.

If the developer was hired to produce a custom thesis system, the client may argue that the source code, database, assets, and documentation were part of the deliverables.

However, developers may argue that:

only the compiled or deployed system was included;
source code requires full payment;
libraries, templates, or frameworks remain theirs;
third-party components cannot be transferred freely.

To avoid disputes, contracts should state that upon payment, the client receives:

full source code;
database schema and data files;
admin credentials;
documentation;
deployment instructions;
project assets;
right to modify and present the system;
warranty against hidden disabling code or backdoors.

In a dispute, the client may demand turnover of existing files, especially if partial payment was made and the work was intended for the client.

XVI. Data Privacy and Confidentiality

Thesis systems sometimes involve personal data, such as student records, patient information, employee data, survey responses, or user accounts. If the developer received personal data, both parties should consider obligations under Philippine data privacy principles.

The developer should not misuse, disclose, sell, or retain sensitive data beyond the project purpose. The client should also avoid sending real personal data unless necessary and properly authorized.

In a dispute, the client may demand:

deletion of confidential files;
return of datasets;
turnover of credentials;
non-disclosure of project materials;
removal of hosted copies.

If the developer threatens to leak files, source code, data, or conversations, that may create additional legal issues.

XVII. Software Defects Versus Non-Completion

Not all bugs amount to breach. Software development naturally involves debugging. The distinction is between ordinary defects and substantial non-performance.

Ordinary defects may include:

minor UI issues;
small validation errors;
typos;
layout problems;
minor bugs that can be fixed.

Substantial non-completion may include:

missing core modules;
non-functional login;
absent database;
no working demo;
system cannot be installed;
source code not provided;
app crashes on basic use;
project cannot satisfy thesis requirements;
developer stopped working before delivery.

A claim is stronger when the defect affects the essential purpose of the project.

XVIII. Importance of Deadlines in Thesis Projects

Time is central in thesis software contracts. A system delivered after the defense may be useless. Even if the developer eventually finishes, late delivery may still be a breach if time was of the essence.

Time may be considered essential when:

the deadline was expressly agreed;
the developer knew the defense date;
the project was tied to school submission;
repeated reminders were made;
payment was made specifically for urgent completion.

A client should preserve proof that the developer knew the academic deadline.

XIX. Computing the Claim

The amount recoverable should be calculated clearly. A demand may include:

total amount paid to the developer;
less value of any usable work accepted, if applicable;
additional amount paid to another developer;
school expenses caused by delay;
other proven expenses;
interest, if legally justified;
costs of suit, where applicable.

For example:

Project price: ₱20,000
Amount paid: ₱15,000
Work delivered: unusable
Additional developer paid to redo: ₱12,000
Possible claim: ₱15,000 refund plus ₱12,000 actual damages, subject to proof and court appreciation.

If some work was usable, the court may reduce the refund.

XX. Settlement Options

Settlement is often practical because litigation can take time. Possible settlement terms include:

full refund by a specific date;
partial refund plus turnover of files;
installment refund;
completion of remaining modules by a fixed deadline;
turnover of source code in exchange for waiver of further claims;
mutual release after payment;
confidentiality undertaking;
deletion of personal or project data.

Settlement should be in writing and signed by both parties. Payment schedules should include exact dates and consequences of default.

XXI. Practical Steps for the Client

A client seeking recovery may proceed as follows:

Gather all evidence.
Save full conversations, not just selected screenshots.
Export or back up chats where possible.
Prepare a timeline of events.
Compute the total amount paid and losses incurred.
Send a formal demand letter.
Give a reasonable deadline to comply.
File a barangay complaint if required.
Proceed to small claims or civil action if settlement fails.
Consider criminal complaint only if there is evidence of fraud from the beginning.

The client should avoid public shaming, threats, or posting accusations online, because this may expose the client to defamation or cyberlibel issues.

XXII. Practical Steps for the Developer

A developer accused of non-completion should:

Review the original scope.
Preserve proof of work done.
Provide a progress report.
Turn over completed files if appropriate.
Communicate professionally.
Offer a realistic completion date or refund.
Avoid making false promises.
Avoid deleting evidence.
Avoid withholding files merely to pressure the client if payment was already made for them.
Put any settlement in writing.

If the developer honestly completed substantial work, they should document it through repositories, file timestamps, demos, screenshots, commits, and delivered modules.

XXIII. Preventive Contract Clauses

A written agreement for thesis software development should include:

1. Parties

Full legal names, contact details, and addresses.

2. Scope of Work

Detailed list of modules, pages, features, platforms, and documentation.

3. Timeline

Milestones, deadlines, testing dates, and final delivery date.

4. Payment Terms

Down payment, milestone payments, final payment, and refund terms.

5. Deliverables

Source code, database, documentation, credentials, deployment files, user manual, and installation guide.

6. Revision Policy

Number of revisions, scope of revisions, and additional charges for major changes.

7. Acceptance Criteria

How the client determines whether the work is complete.

8. Turnover

When and how files will be transferred.

9. Ownership

Who owns the code, design, database, and intellectual property after payment.

10. Confidentiality

Protection of thesis ideas, documents, datasets, and personal information.

11. Default and Refund

Consequences if either party fails to comply.

12. Dispute Resolution

Barangay conciliation, mediation, venue, and governing law.

XXIV. Sample Legal Theory for the Claim

A claimant may frame the case as follows:

The parties entered into an agreement where the developer undertook to create and deliver a thesis software project in exchange for payment. The client paid the agreed amount or a substantial portion of it. Despite demand and despite the known academic deadline, the developer failed to complete and deliver the required system. The unfinished or defective output was unusable for its intended purpose. The developer’s failure constitutes breach of obligation, entitling the client to rescission, refund, damages, and other appropriate relief.

Where fraud exists, the claimant may add that the developer induced payment through false representations and had no intention to perform, making the conduct potentially criminal.

XXV. Sample Demand Structure

A demand may be structured this way:

First paragraph: Identify the agreement and project. Second paragraph: State payments made. Third paragraph: Explain the breach. Fourth paragraph: State the demand: refund, completion, or turnover. Fifth paragraph: Give a deadline. Sixth paragraph: State that legal remedies will be pursued if no compliance occurs.

The demand should be specific, calm, and supported by attachments.

XXVI. Risks in Filing a Claim

Before filing, the client should consider:

whether the amount justifies the time and cost;
whether the agreement may reveal academic integrity issues;
whether the developer has identifiable contact details;
whether the developer has capacity to pay;
whether evidence is sufficient;
whether the client contributed to delay;
whether settlement is more practical.

The best legal claim is one supported by clean facts: clear agreement, clear payment, clear non-delivery, clear demand, and clear damages.

XXVII. Key Legal Principles

The topic rests on several core principles of Philippine civil law:

Contracts have the force of law between the parties.
Obligations must be performed in good faith.
A party who fails to perform may be liable for damages.
A party injured by breach may seek performance, rescission, refund, and damages.
No one should unjustly enrich themselves at another’s expense.
Fraud may transform a civil dispute into a criminal matter if deceit existed from the beginning.
Damages must be proven, not merely alleged.
Settlement and barangay conciliation may be required or practical before court action.

XXVIII. Conclusion

A developer who accepts payment for a thesis software project but fails to finish or deliver the agreed output may be liable for breach of contract under Philippine law. The client may seek completion, refund, rescission, damages, or, in cases involving fraud, possible criminal remedies. The strongest claims are supported by written terms, payment records, conversations, deadlines, evidence of non-completion, and proof of resulting losses.

The central issue is not merely that the project was unfinished, but whether the developer failed to comply with a definite obligation after receiving payment. In thesis software disputes, time, deliverables, source code, revisions, and academic deadlines are critical. A well-documented claim can support recovery of payment, while poor documentation can reduce the dispute to conflicting verbal accounts.