I. Introduction

Software development transactions in the Philippines often involve large payments, tight timelines, technical deliverables, source code ownership, hosting arrangements, user data, intellectual property, confidentiality, maintenance obligations, and business-critical systems. When a software development firm fails to deliver, delivers defective work, abandons the project, misrepresents its capabilities, withholds source code, refuses turnover, or collects payments through deceit, the client may have remedies for breach of contract, fraud, damages, rescission, specific performance, refund, estafa, cybercrime-related offenses, intellectual property violations, data privacy violations, or unfair business practices, depending on the facts.

In Philippine law, not every failed software project is automatically fraud. Some disputes are purely civil: the developer may have been negligent, late, technically weak, or unable to complete the work. But when the firm knowingly made false representations, accepted money without intent or capacity to perform, used fake credentials, misappropriated funds, concealed material facts, or induced the client to pay through deception, the case may involve fraud and possibly criminal liability.

The key legal issue is to distinguish:

Was this merely poor performance under a contract, or was the client deceived into entering or continuing the transaction?

That distinction affects remedies, venue, evidence, damages, and strategy.

II. Nature of Software Development Contracts

A software development agreement is generally a contract for services, technology development, licensing, customization, integration, implementation, maintenance, or a mixture of these.

It may involve:

custom software development;
website or mobile app development;
enterprise system development;
e-commerce platform creation;
cloud or SaaS implementation;
system integration;
API integration;
database development;
software customization;
UI/UX design;
cybersecurity services;
payment gateway integration;
hosting and maintenance;
source code escrow or turnover;
software licensing;
technical support;
project management;
data migration;
quality assurance and testing;
post-launch maintenance.

The legal classification matters because a software project may include obligations to deliver a work product, render services, license intellectual property, process personal data, host systems, and maintain confidentiality.

III. Sources of Legal Obligations

The rights and liabilities of a software development firm may arise from:

the written contract;
service proposal;
statement of work;
purchase order;
quotation;
project plan;
email correspondence;
chat messages;
invoices and official receipts;
terms and conditions;
nondisclosure agreement;
data processing agreement;
intellectual property assignment;
maintenance agreement;
oral representations, if provable;
law;
equity and good faith;
industry standards, where relevant;
consumer or business protection rules, depending on the parties.

Even if there is no formal signed contract, a legal relationship may still arise if there was an offer, acceptance, consideration, and mutual agreement shown through emails, invoices, payments, messages, or performance.

IV. Essential Elements of a Contract

Under Philippine civil law, a contract generally requires:

consent of the parties;
object certain which is the subject matter of the contract;
cause or consideration of the obligation.

In software projects:

consent may be shown by signing the proposal, paying the down payment, approving a quotation, or exchanging written confirmations;
the object may be the software, platform, app, system, code, support, license, or technical service;
the cause is usually the price paid by the client and the developer’s undertaking to deliver the project.

A contract may be valid even if the details are incomplete, but vague software contracts often create disputes because parties disagree on scope, acceptance criteria, ownership, or support obligations.

V. Common Contractual Obligations of a Software Development Firm

A software development firm may be obligated to:

deliver the software described in the contract;
comply with specifications;
meet milestones;
complete the project by agreed deadlines;
assign qualified personnel;
provide project documentation;
produce working source code;
conduct testing;
fix bugs during warranty period;
integrate with third-party systems;
migrate data;
provide admin access;
turn over credentials;
maintain confidentiality;
comply with data privacy rules;
assign or license intellectual property rights;
provide maintenance and support;
issue official receipts or invoices;
preserve client data;
refrain from using the client’s information or business model without permission.

The exact obligations depend on the contract.

VI. Common Breaches by Software Development Firms

Software development disputes often involve one or more of the following breaches:

A. Non-Delivery

The firm receives payment but fails to deliver any usable software.

Examples:

no working prototype;
no code repository;
no deployed system;
no access credentials;
no deliverables despite repeated follow-up;
project abandoned after down payment.

B. Delayed Delivery

The firm delivers late or misses milestones.

Delay may be actionable if time was essential, if delay caused loss, or if the contract specified deadlines, penalties, or termination rights.

C. Defective or Non-Conforming Software

The software is delivered but does not meet agreed specifications.

Examples:

core features missing;
app crashes frequently;
system cannot handle expected users;
payment gateway does not work;
database is insecure;
UI differs materially from approved design;
admin panel incomplete;
reports are inaccurate;
mobile app rejected by app stores due to developer errors.

D. Abandonment

The firm stops communicating, pulls out developers, ignores tickets, or refuses to continue unless paid additional amounts not agreed upon.

E. Unauthorized Scope Reduction

The firm delivers a smaller or inferior system than promised.

F. Unauthorized Additional Charges

The firm demands extra payment for features that were already included in the original agreement.

G. Failure to Turn Over Source Code

If the client paid for custom development and the contract requires turnover, refusal to provide source code may be a serious breach.

However, if the contract only grants a license or uses proprietary framework, the firm may argue that source code turnover was not included. This is why IP clauses are critical.

H. Withholding Credentials or Access

A firm may wrongfully withhold:

domain access;
hosting account access;
cloud dashboard credentials;
database credentials;
app store accounts;
repository access;
admin accounts;
API keys;
email accounts;
payment gateway credentials.

This may disrupt business operations and expose the firm to damages.

I. Unauthorized Use of Client Data

The firm may misuse customer lists, business data, trade secrets, personal information, or proprietary workflows.

J. Poor Security

The firm may deliver a system with severe security vulnerabilities, exposing users to data breach, fraud, or system compromise.

K. Failure to Provide Maintenance

If the contract includes support, warranty, bug fixes, or service level commitments, failure to perform may be a breach.

L. Subcontracting Without Consent

The firm may secretly outsource the work to unqualified third parties, freelancers, or offshore developers contrary to contract or confidentiality obligations.

VII. Breach of Contract Under Philippine Law

Breach of contract occurs when a party fails to perform a contractual obligation without lawful excuse.

In software development, breach may consist of:

failure to deliver;
delay;
defective performance;
partial performance;
refusal to perform;
violation of warranties;
breach of confidentiality;
unauthorized use of intellectual property;
failure to comply with data protection obligations;
failure to return property or access.

A client suing for breach generally must prove:

a valid contract existed;
the software firm had obligations under the contract;
the firm failed to perform those obligations;
the client suffered damage;
the damage was caused by the breach.

VIII. Remedies for Breach of Contract

A client may seek several remedies.

A. Specific Performance

Specific performance asks the court to compel the firm to perform its obligation.

In software cases, this may include:

completion of deliverables;
turnover of source code;
turnover of credentials;
delivery of documentation;
correction of defects;
deployment of the system;
migration of data;
compliance with warranty obligations.

However, courts may be reluctant to supervise highly technical ongoing development work. Specific performance is more practical for definite acts, such as turning over code, documents, or access credentials.

B. Rescission

Rescission seeks to undo the contract due to substantial breach.

The client may ask for:

cancellation of the contract;
refund of payments;
return of property;
damages.

Rescission may be appropriate where the breach is fundamental, such as total non-delivery, abandonment, or delivery of a completely unusable system.

C. Damages

The client may claim damages for losses caused by breach.

Possible damages include:

refund of amounts paid;
cost of hiring another developer;
lost business opportunities;
lost profits, if proven with reasonable certainty;
wasted marketing expenses;
penalties paid to customers;
cost of remediation;
cybersecurity incident response costs;
data recovery expenses;
additional hosting costs;
reputational harm, where legally supported;
attorney’s fees, if proper;
interest.

D. Contractual Penalties

If the contract contains a penalty clause or liquidated damages clause, the client may invoke it.

Examples:

penalty per day of delay;
refund upon missed milestone;
service credit for downtime;
fixed damages for breach of confidentiality;
termination fee;
warranty retention.

Courts may reduce penalties if they are unconscionable or contrary to law, but reasonable liquidated damages clauses can be useful.

E. Termination

The client may terminate according to the contract. If the firm materially breaches, termination may be justified.

The termination notice should identify:

breached obligations;
deadlines missed;
defects;
prior notices;
opportunity to cure, if required;
demand for turnover and refund;
reservation of rights.

F. Injunction

In urgent cases, a client may seek injunctive relief to prevent:

deletion of source code;
misuse of confidential information;
transfer of domains;
unauthorized publication;
system shutdown;
use of client data;
sale or reuse of proprietary software;
destruction of evidence.

Injunction requires proof of legal right, urgent necessity, and irreparable harm.

IX. Fraud in Software Development Transactions

Fraud may occur before, during, or after the contract.

Fraud in civil law may involve deception that induces a party to enter into a contract or continue paying. Fraud may also support damages, annulment, rescission, or criminal prosecution depending on circumstances.

Examples of fraud by a software development firm include:

falsely claiming to have completed similar projects;
using fake portfolio items;
pretending to have in-house developers when none exist;
claiming ownership of code or technology it does not own;
presenting fake certifications;
misrepresenting technical capability;
promising delivery despite knowing it cannot perform;
collecting milestone payments based on false progress reports;
showing fake demos;
using templates while claiming custom development;
falsely claiming licenses were purchased;
using pirated software;
concealing that the project was abandoned;
misusing client funds;
creating fake invoices for third-party services;
pretending to pay for servers or APIs;
claiming code is complete when it does not exist;
refusing turnover after payment;
selling the same custom system to competitors despite exclusivity;
using client confidential data for another client.

Fraud is more serious than poor performance. It involves deceit, bad faith, or intentional misrepresentation.

X. Civil Fraud vs. Criminal Fraud

A software dispute may be civil, criminal, or both.

A. Civil Fraud

Civil fraud may support:

annulment of contract;
rescission;
damages;
refund;
attorney’s fees;
injunction.

The burden of proof in civil cases is generally lower than in criminal cases.

B. Criminal Fraud

Criminal fraud may involve estafa or other offenses if the developer obtained money or property through deceit, abuse of confidence, or misappropriation.

Criminal prosecution requires proof beyond reasonable doubt.

The mere fact that a developer failed to finish the project does not automatically mean estafa. There must be evidence of criminal deceit or misappropriation.

XI. Estafa in Software Development Cases

Estafa may be considered where the software firm or its officers defrauded the client by deceit or abuse of confidence.

Possible estafa scenarios include:

the firm represented that it had developers, licenses, infrastructure, or capability when it did not;
the firm induced payment through false promises and fake progress reports;
the firm received money for a specific purpose, such as buying licenses or paying vendors, and diverted it;
the firm accepted payment without intent to perform;
the firm used false documents or false pretenses;
the firm misappropriated funds, equipment, or data entrusted to it;
the firm issued receipts for services never intended to be rendered;
the firm disappeared after collecting payment.

The complainant should prove that deceit existed before or at the time payment was made, or that funds entrusted for a specific purpose were misappropriated.

A later inability to finish is usually not enough by itself. The evidence must show fraudulent intent.

XII. Cybercrime Issues

The Cybercrime Prevention Act may become relevant if the firm used computers, systems, networks, or digital means to commit fraud or related offenses.

Possible cybercrime-related issues include:

computer-related fraud;
computer-related forgery;
computer-related identity theft;
illegal access;
data interference;
system interference;
misuse of devices;
unauthorized use of accounts;
deletion or alteration of client data;
fraudulent online representations;
phishing-style impersonation;
unauthorized access to production servers.

If the software firm hacks, locks out, alters, deletes, sabotages, or refuses access to digital assets in a way that violates cybercrime laws, criminal liability may arise beyond ordinary breach of contract.

XIII. Intellectual Property Issues

Software projects often involve intellectual property rights. Disputes may arise over:

source code ownership;
copyright in software;
UI/UX designs;
databases;
documentation;
logos and branding;
third-party libraries;
open-source software;
APIs;
trade secrets;
confidential algorithms;
derivative works;
licensing rights.

A. Copyright in Software

Software code may be protected by copyright. Ownership depends on law, contract, employment, commissioning terms, and assignment clauses.

A client should not assume that paying for software automatically transfers all copyright unless the contract clearly says so.

B. Assignment vs. License

A contract may provide either:

assignment, meaning ownership is transferred to the client; or
license, meaning the client is allowed to use the software under defined terms.

If the client needs full control, the contract should expressly require assignment of source code, object code, documentation, and related rights upon full payment.

C. Use of Third-Party Code

A developer may use third-party libraries, frameworks, templates, plugins, or open-source components. This is common, but the firm must ensure the client receives lawful rights and no license terms are violated.

Use of unlicensed or pirated software may create legal risk for the client.

D. Reuse of Client-Specific Code

If the firm reuses software developed for the client in another project, liability depends on the IP clause. If the contract grants exclusivity or assigns ownership, reuse may breach the contract and infringe rights.

XIV. Data Privacy Issues

If the software development firm handles personal information, it may be a personal information processor or otherwise subject to data privacy obligations.

Software firms may process:

customer names;
email addresses;
phone numbers;
addresses;
financial data;
health data;
employee data;
login credentials;
transaction history;
government IDs;
biometric data;
children’s data;
sensitive personal information.

The client and developer should have a data processing agreement or data privacy clauses.

A firm may be liable if it:

misuses personal data;
fails to secure databases;
gives unauthorized access to subcontractors;
keeps data after termination;
refuses to return or delete data;
causes a data breach through negligence;
uses production data for testing without safeguards;
exposes credentials;
stores personal data in unsecured servers;
transfers data abroad without proper basis.

Data privacy violations may result in civil, criminal, administrative, and reputational consequences.

XV. Confidentiality and Trade Secrets

A software development firm may gain access to:

business plans;
customer lists;
pricing models;
proprietary processes;
financial information;
product roadmap;
source code;
algorithms;
credentials;
marketing strategy;
vendor contracts.

Misuse or disclosure may violate:

nondisclosure agreement;
contract;
intellectual property rights;
unfair competition principles;
data privacy rules;
fiduciary or good faith obligations.

The client may seek damages and injunction if confidential information is misused.

XVI. Consumer Protection and Business-to-Business Transactions

Software development contracts are often business-to-business transactions. Consumer protection laws may be relevant where the client is an individual consumer or micro/small business receiving services under conditions covered by law.

However, many software disputes are governed primarily by contract, civil law, commercial law, IP law, and data privacy law.

If the firm advertised false claims to the public, regulatory complaints may be considered depending on the nature of the misrepresentation.

XVII. Corporate Liability and Personal Liability of Officers

A software development firm may be a corporation, partnership, sole proprietorship, or unregistered business.

A. Corporation as Defendant

If the contract is with a corporation, the corporation is generally liable for contractual breach.

B. Personal Liability of Officers

Corporate officers may become personally liable if they:

personally committed fraud;
signed false representations;
used the corporation to commit wrongdoing;
diverted client funds;
acted in bad faith;
commingled corporate and personal funds;
used the corporation as a shield for fraud;
personally guaranteed performance;
violated criminal laws;
personally participated in intellectual property or data privacy violations.

A corporate officer is not automatically liable for every corporate breach. Personal participation, bad faith, fraud, or statutory basis must be shown.

C. Sole Proprietorship

If the “firm” is a sole proprietorship, the owner may be personally liable because a sole proprietorship has no separate juridical personality distinct from the owner.

D. Partnership

Partners may have liability depending on the type of partnership, participation, and applicable law.

XVIII. Liability of Freelancers and Subcontractors

Many software firms outsource work to freelancers or subcontractors.

The client’s contract may prohibit or regulate subcontracting. If the firm uses subcontractors, the firm remains responsible to the client unless the contract says otherwise.

Subcontractors may also be liable if they:

misuse confidential information;
infringe IP rights;
access systems without authority;
steal data;
sabotage code;
participate in fraud;
violate data privacy laws.

A client may need to identify all persons who had access to code, servers, and credentials.

XIX. Evidence in Software Breach and Fraud Cases

Evidence is critical. The client should preserve:

A. Contract Documents

signed contract;
proposal;
statement of work;
quotations;
project plan;
purchase orders;
service level agreement;
IP assignment;
NDA;
data processing agreement;
maintenance agreement;
change orders.

B. Payment Evidence

deposit slips;
bank transfers;
e-wallet transfers;
official receipts;
invoices;
billing statements;
milestone payment records;
tax documents;
acknowledgment receipts.

C. Communication Evidence

emails;
chat messages;
text messages;
meeting minutes;
call recordings, if lawfully obtained;
project management platform records;
ticketing system logs;
screenshots of promises;
progress reports;
notices of delay;
demand letters.

D. Technical Evidence

code repositories;
commit history;
branch logs;
deployment logs;
bug reports;
test results;
system audit logs;
database logs;
server access logs;
API logs;
app store rejection notices;
security assessment reports;
screenshots and screen recordings;
expert evaluation;
backup copies.

E. Fraud Evidence

fake portfolio screenshots;
false certifications;
false claims about personnel;
fake demos;
copied templates;
misrepresented third-party expenses;
altered invoices;
proof of no work done;
proof of diversion of funds;
complaints from other clients;
disappearing accounts;
inconsistent statements.

F. Damage Evidence

lost sales;
business interruption;
cost of replacement developer;
refund demands;
penalties from customers;
security incident costs;
data breach response costs;
reputational harm;
staff time wasted;
additional hosting or subscription costs.

XX. Importance of Technical Expert Assessment

Software disputes are often technical. A lawyer may need assistance from an independent software expert to determine:

whether deliverables meet specifications;
whether code exists and is usable;
whether code quality is acceptable;
whether defects are minor or material;
whether the project can be completed;
whether source code was copied;
whether security vulnerabilities exist;
whether logs show unauthorized access;
whether the firm’s progress reports were truthful;
whether paid third-party services were actually purchased.

A technical report can strengthen civil and criminal complaints.

XXI. Demand Letter

Before filing a case, the client often sends a demand letter.

A demand letter may request:

completion of deliverables;
turnover of source code;
turnover of credentials;
correction of defects;
refund;
damages;
accounting of funds;
return or deletion of data;
preservation of evidence;
cessation of unauthorized use;
confirmation of IP assignment;
settlement meeting.

The demand letter should be specific and supported by documents. It should avoid exaggerated accusations unless the evidence supports them.

XXII. Sample Demand Letter Structure

A software dispute demand letter may include:

contract date and parties;
project description;
payments made;
agreed deliverables;
milestones and deadlines;
breaches;
evidence of non-delivery or defects;
prior follow-ups;
legal basis for demand;
requested remedy;
deadline to comply;
reservation of civil, criminal, administrative, and injunctive remedies.

For fraud cases, the letter may also demand an explanation of misrepresentations and accounting of funds.

XXIII. Rescission and Refund

A client may seek rescission and refund when the software firm’s breach defeats the purpose of the contract.

Examples:

firm delivered nothing usable;
project is abandoned;
core functions are missing;
firm cannot complete the system;
firm repeatedly misrepresented progress;
delay made the project commercially useless;
firm refused to turn over source code or access;
firm committed fraud.

The client should be ready to return whatever benefit it received, if any, or account for partial deliverables, depending on the court’s determination.

XXIV. Specific Performance and Turnover

Specific performance is especially useful where the client needs:

source code;
database dump;
admin credentials;
domain access;
hosting access;
cloud account access;
documentation;
build files;
design files;
app signing keys;
deployment scripts;
environment variables;
API credentials;
backup files.

These assets may be critical to business continuity. If the firm refuses turnover, urgent legal action may be needed.

XXV. Injunction and Preservation of Digital Assets

A client may need urgent relief where the firm threatens to:

shut down the platform;
delete databases;
transfer the domain;
revoke cloud access;
publish confidential information;
disable app access;
lock the client out;
destroy code repositories;
hold customer data hostage.

Possible legal steps may include demand for preservation, court injunction, law enforcement complaint if criminal acts are involved, and immediate technical mitigation.

XXVI. Contract Review: Key Clauses in Software Development Agreements

A strong contract helps avoid disputes. Important clauses include:

A. Scope of Work

The contract should define exactly what will be built.

Include:

features;
modules;
platforms;
integrations;
design requirements;
technical stack;
performance requirements;
security requirements;
reporting requirements;
admin functions;
mobile compatibility;
browser compatibility;
deliverables.

Vague phrases like “complete system” or “fully functional app” can create disputes unless backed by specifications.

B. Milestones

Define milestones and deliverables for each payment.

Example:

20% upon signing;
20% upon approved UI/UX;
20% upon working prototype;
20% upon beta deployment;
20% upon final acceptance and source code turnover.

Avoid paying too much before meaningful deliverables.

C. Acceptance Criteria

Acceptance criteria should define when a deliverable is accepted.

Include:

testing period;
bug severity levels;
rejection procedure;
deemed acceptance rules;
documentation requirements;
performance benchmarks;
security testing;
user acceptance testing.

D. Change Request Procedure

Software projects often change. The contract should require written change orders for additional scope, cost, and timeline.

E. Timeline

Set deadlines and consequences of delay.

Include:

target dates;
dependencies;
client responsibilities;
grace periods;
delay penalties;
termination rights.

F. Payment Terms

Payment should be linked to verified deliverables. Avoid vague “progress” billing.

G. Source Code Ownership

State who owns source code and when ownership transfers.

H. Third-Party Components

Require disclosure of open-source libraries, paid licenses, templates, and third-party services.

I. Warranty

Define bug-fix period, support coverage, and exclusions.

J. Maintenance

Separate development from post-launch maintenance.

K. Data Privacy

Include data processing, security, breach notification, deletion, and return obligations.

L. Confidentiality

Protect business and technical information.

M. Non-Solicitation and Non-Competition

Where appropriate and lawful, restrict misuse of client information or poaching.

N. Termination

Define termination for cause, convenience, breach, insolvency, or abandonment.

O. Turnover

Specify what must be turned over upon termination or completion.

P. Dispute Resolution

Specify venue, governing law, mediation, arbitration, and attorney’s fees.

XXVII. Source Code Ownership: Common Dispute

One of the most common software disputes is whether the client owns the source code.

The client may say:

“We paid for the system, so we own the code.”

The developer may say:

“You paid for use of the system, not ownership of our code.”

The answer depends on the contract and applicable IP rules.

To avoid dispute, the contract should state:

whether ownership is assigned;
whether assignment occurs upon full payment;
whether pre-existing developer tools are excluded;
whether the client receives source code;
whether the client may modify, sublicense, sell, or transfer the software;
whether the developer may reuse code;
whether third-party components are licensed separately.

Without clear language, litigation may become expensive.

XXVIII. Open-Source Software Risks

Open-source software is not automatically free from obligations. Some licenses require:

attribution;
source code disclosure;
same-license distribution;
restrictions on proprietary use;
license notices;
security obligations.

If the firm uses open-source components improperly, the client may face compliance risks.

The contract should require an open-source software disclosure schedule.

XXIX. Security Obligations

Software firms should follow reasonable security practices. Security obligations may arise from contract, data privacy law, industry standards, or nature of the project.

Important security requirements include:

secure coding;
encryption;
access controls;
password hashing;
input validation;
protection against injection attacks;
audit logs;
vulnerability testing;
backup and recovery;
least privilege access;
secure deployment;
removal of hardcoded credentials;
data breach notification;
secure deletion of production data.

A firm that delivers insecure software may be liable if the insecurity causes damage or data breach.

XXX. Data Breach Caused by Developer Negligence

If a developer’s negligence causes a data breach, the client may face regulatory obligations and damage to customers. The client may then seek indemnity from the developer.

Examples:

exposed database;
public cloud bucket;
weak admin password;
hardcoded credentials leaked in repository;
no authentication;
insecure API;
failure to patch known vulnerability;
unauthorized subcontractor access.

The contract should require indemnity for data privacy and security breaches caused by the developer.

XXXI. Hosting and Control of Infrastructure

Software firms sometimes host the client’s platform under the firm’s own account. This creates risk because the client may be locked out.

Best practice:

client owns the cloud account;
client owns the domain;
client owns app store accounts;
client owns payment gateway accounts;
developer receives limited access;
credentials are documented and transferable;
admin access is not dependent on developer goodwill.

If the developer refuses to transfer hosting or access after payment, this may support breach or urgent relief.

XXXII. Domain Name Disputes

If the developer registered the client’s domain under the developer’s name, the client may have difficulty recovering it.

The contract should state that all domains, hosting, app store accounts, and digital assets acquired for the project belong to the client.

Wrongful retention of a domain may support claims for breach, damages, injunction, and possibly cyber-related remedies depending on conduct.

XXXIII. App Store Accounts and Signing Keys

Mobile app projects require app store accounts, signing keys, certificates, and build credentials. If the firm keeps these, the client may be unable to update the app.

Turnover should include:

source code repository;
build instructions;
signing keys;
certificates;
app store access;
developer account ownership;
push notification credentials;
analytics accounts;
crash reporting accounts.

Failure to turn these over may make the app commercially useless.

XXXIV. Software Acceptance and Bug Disputes

Developers often argue that the project was completed and only minor bugs remain. Clients often argue that defects make the system unusable.

The contract should classify bugs:

critical;
high;
medium;
low;
cosmetic.

Acceptance should not occur until critical and high bugs are resolved.

If there is no contract definition, a technical expert may classify defects and explain whether the system is fit for intended use.

XXXV. Delay and Force Majeure

A developer may defend delay by claiming force majeure or client-caused delay.

Possible legitimate causes:

client failed to provide content;
third-party API changed;
client repeatedly changed scope;
government restrictions;
unavoidable outages;
delayed approvals;
dependency on third-party vendor.

However, ordinary staffing problems, poor project management, or overbooking are usually not force majeure.

The contract should define what events excuse delay and what notice is required.

XXXVI. Client’s Own Breach

The developer may counterclaim that the client breached by:

failing to pay;
changing scope repeatedly;
delaying approvals;
not providing content or credentials;
rejecting deliverables unreasonably;
hiring another developer in breach of exclusivity;
interfering with development;
failing to attend testing;
demanding work outside scope.

A client should maintain records showing that it performed its obligations and that the firm’s breach was not client-caused.

XXXVII. Civil Action for Damages

A civil complaint may seek:

rescission;
refund;
damages;
specific performance;
injunction;
accounting;
attorney’s fees;
interest;
costs of suit.

The complaint should attach or describe:

contract;
payments;
breaches;
demands;
damages;
technical report, if available.

XXXVIII. Criminal Complaint for Estafa or Fraud

A criminal complaint should focus on deceit or misappropriation, not merely poor performance.

Important evidence includes:

false statements made before payment;
proof those statements were false when made;
proof client relied on them;
payments made because of deceit;
refusal or failure to perform;
diversion of funds;
fake receipts or invoices;
disappearance or concealment;
multiple victims, if relevant.

The complaint should avoid turning every contractual dispute into a criminal case. Prosecutors will look for criminal intent.

XXXIX. When Breach Becomes Fraud

A breach may suggest fraud if there is evidence that:

the firm never intended to perform;
the firm had no capacity to perform but claimed otherwise;
the firm used fake credentials or fake portfolio;
the firm fabricated progress reports;
the firm demanded payment for milestones not reached;
the firm concealed abandonment;
the firm misappropriated funds for specified expenses;
the firm repeatedly used the same scheme on other clients;
the firm closed or changed identity after payment;
the firm refused to account for funds.

Fraud is about deception, not just failure.

XL. Possible Administrative or Regulatory Complaints

Depending on the facts, complaints may be made to:

Department of Trade and Industry, for consumer-related issues;
National Privacy Commission, for data privacy violations;
Intellectual Property Office, for IP issues;
Securities and Exchange Commission, if corporate misconduct or unauthorized investment claims are involved;
Professional or industry organizations, if relevant;
local business permit office, if the firm is unregistered or misrepresenting its business.

Regulatory complaints may not always result in refund, but they can support pressure, investigation, or sanctions.

XLI. Arbitration and Mediation

Some software contracts contain arbitration clauses. If so, parties may be required to arbitrate rather than file ordinary civil action.

Arbitration may be useful because technical disputes can be resolved by specialists. But urgent injunctions or criminal complaints may still require court or law enforcement action depending on the issue.

Mediation may help resolve disputes involving refunds, turnover, and completion.

Settlement terms should be documented carefully.

XLII. Jurisdiction and Venue

The proper forum depends on:

amount of claim;
nature of action;
arbitration clause;
location of parties;
place of performance;
contract venue clause;
whether injunction is sought;
whether criminal complaint is filed;
whether intellectual property or data privacy issues exist.

A contract may specify venue, but venue clauses must be reviewed for enforceability and scope.

XLIII. Prescriptive Periods

Claims must be filed within applicable prescriptive periods.

Different claims may have different periods:

written contract claims;
oral contract claims;
fraud claims;
injury to rights;
quasi-delict;
criminal offenses;
intellectual property claims;
data privacy claims.

Clients should act promptly because delay can weaken evidence, allow deletion of logs, and affect recovery.

XLIV. Mitigation of Damages

A client should take reasonable steps to reduce losses after breach.

Examples:

back up available data;
secure accounts;
change passwords;
revoke developer access if necessary;
hire replacement developer;
notify customers if service is affected;
preserve evidence;
avoid making unnecessary additional payments;
report data breaches where required;
avoid public accusations that may create defamation exposure.

Failure to mitigate may reduce recoverable damages.

XLV. Settlement

Settlement may involve:

partial refund;
full refund;
turnover of source code;
completion of specific features;
free maintenance period;
mutual release;
confidentiality;
non-disparagement;
data deletion certificate;
IP assignment;
payment schedule;
admission or no-admission clause.

A settlement should not ignore data privacy, access credentials, and IP rights.

If criminal fraud is involved, settlement may affect civil liability but may not automatically extinguish criminal liability depending on the offense and stage of proceedings.

XLVI. Quitclaims and Waivers

A software firm may ask the client to sign a waiver in exchange for partial refund or turnover. The client should review carefully.

A waiver should not unintentionally release:

data breach claims;
IP claims;
confidentiality claims;
fraud claims;
claims against officers;
claims for hidden defects;
claims for future misuse of source code or data.

If the client signs a release, it should be clear, limited, and supported by adequate consideration.

XLVII. Defamation Risk in Public Complaints

Clients sometimes post online accusations against developers. This may create risk of cyber libel or defamation if the post contains false or malicious statements.

A client may warn others or review a service, but statements should be factual, documented, and not exaggerated.

Safer statements include:

“We paid for X deliverables and did not receive them by the agreed date.”
“We have filed a complaint.”
“The dispute is pending.”

Riskier statements include unsupported accusations such as “criminal syndicate,” “scammer,” or “fraudster” without filed or proven basis.

XLVIII. Practical Checklist for Clients Before Hiring a Software Firm

Before signing, clients should:

verify business registration;
check portfolio authenticity;
speak with past clients;
verify developer team;
require written contract;
define scope in detail;
link payments to milestones;
require source code and documentation clauses;
ensure client owns domain, hosting, and app store accounts;
require data privacy and confidentiality clauses;
require open-source disclosure;
require security standards;
include warranty and maintenance terms;
include termination and turnover rights;
avoid paying large upfront amounts;
check litigation or complaint history where possible;
require official receipts;
include dispute resolution terms;
require key person or staffing commitments;
include penalties or remedies for delay.

XLIX. Practical Checklist When a Dispute Arises

When a software firm breaches or commits suspected fraud, the client should:

preserve all contracts and communications;
export project management records;
secure screenshots and recordings of defective system;
back up data;
secure domain and hosting accounts;
change passwords and revoke risky access;
document payments;
request formal status report;
send written notice of breach;
give cure period if required;
obtain technical assessment;
compute damages;
demand turnover;
avoid additional payments without written terms;
consult counsel;
consider civil, criminal, data privacy, and IP remedies;
preserve server logs and repository history;
notify affected customers if necessary;
prepare evidence index;
avoid defamatory public posts.

L. Practical Checklist for Software Firms

A software firm should reduce liability by:

using clear contracts;
defining scope;
documenting assumptions;
using written change orders;
giving realistic timelines;
disclosing third-party dependencies;
avoiding false portfolio claims;
maintaining project records;
issuing receipts;
providing regular progress reports;
preserving code repositories;
maintaining security standards;
protecting client data;
turning over deliverables as agreed;
documenting client-caused delays;
escalating blockers early;
avoiding unauthorized subcontracting;
not withholding credentials unlawfully;
not using client data for other projects;
resolving disputes in good faith.

LI. Common Defenses of Software Development Firms

A software firm may raise defenses such as:

no final contract was formed;
scope did not include disputed feature;
client failed to pay;
client caused delay;
client changed requirements;
project was substantially completed;
client accepted deliverables;
defects are minor and curable;
source code was not part of the deal;
client terminated prematurely;
third-party service caused failure;
force majeure;
damages are speculative;
fraud allegations are unsupported;
client misused the software;
client refused to cooperate in testing;
IP belongs to developer under contract;
dispute must go to arbitration.

The outcome depends heavily on documentation.

LII. Common Mistakes by Clients

1. No Written Contract

Relying only on calls and informal messages makes enforcement harder.

2. Vague Scope

A vague contract invites disputes about what was included.

3. Large Upfront Payment

Paying most of the price before deliverables reduces leverage.

4. Developer Controls All Accounts

The client should own domain, hosting, repository, and app store accounts.

5. No IP Clause

Without an IP clause, ownership disputes are likely.

6. No Data Privacy Clause

This is risky where personal information is processed.

7. No Acceptance Testing

Without acceptance criteria, parties may disagree whether the project is complete.

8. No Turnover Clause

The client may be left without source code or credentials.

9. Ignoring Security

A cheap system may become expensive after a breach.

10. Delaying Legal Action

Digital evidence can disappear quickly.

LIII. Common Mistakes by Software Firms

1. Overpromising

Unrealistic promises may later support fraud allegations.

2. No Change Orders

Continuing work despite scope changes without written change orders creates billing disputes.

3. Poor Documentation

Lack of progress records makes it difficult to defend performance.

4. Holding Client Data Hostage

This can escalate a civil dispute into serious legal exposure.

5. Using Unlicensed Code

This creates IP and compliance risk.

6. Misrepresenting Progress

False progress reports may support fraud claims.

7. Ignoring Demand Letters

Silence can worsen litigation risk.

8. Subcontracting Secretly

This may violate confidentiality and data privacy obligations.

9. Failing to Issue Receipts

This creates tax and credibility issues.

10. Deleting Evidence

Deletion of code, logs, or communications may be used against the firm.

LIV. Software Project Documentation Best Practices

Good documentation includes:

signed contract;
statement of work;
product requirements document;
technical specifications;
UI/UX approvals;
sprint reports;
issue tracker;
test plans;
user acceptance test results;
deployment checklist;
access inventory;
code repository;
open-source disclosure;
security checklist;
data processing records;
turnover checklist;
acceptance certificate.

These documents help determine whether breach occurred.

LV. Turnover Checklist

Upon completion or termination, the developer should turn over:

source code;
repository access;
database schema;
database dump;
documentation;
deployment guide;
admin credentials;
cloud credentials;
domain credentials;
app store credentials;
API keys;
environment variables;
SSL certificates;
design files;
test accounts;
user manuals;
third-party license information;
open-source notices;
backup files;
data deletion confirmation for developer-held copies.

LVI. Remedies for Withheld Source Code or Credentials

If the firm withholds critical assets, the client may:

send urgent demand letter;
invoke contract turnover clause;
request injunction;
file civil action for specific performance and damages;
file criminal complaint if there is misappropriation, extortion, illegal access, or data interference;
notify hosting providers or registrars if account ownership can be proven;
engage replacement technical team;
preserve evidence of lockout and business loss.

LVII. Software Firm’s Right to Withhold Work for Nonpayment

A developer may have some right to suspend work if the client fails to pay under the contract. However, the firm must act lawfully and in good faith.

The firm should not:

delete client data;
sabotage production systems;
access systems unlawfully;
publish confidential information;
hold personal data hostage;
disable critical services without notice if it endangers users;
extort additional payments.

If the client owes payment, the firm should use contractual and legal remedies.

LVIII. Milestone Payment Disputes

A milestone payment should be due only when the milestone is actually completed according to contract.

If the firm claims a milestone is complete, ask:

What deliverable was submitted?
Was it tested?
Was it accepted?
Were critical bugs resolved?
Is documentation included?
Was source code committed?
Does it meet specifications?
Was the client given access?

Milestones should be objective, not merely based on claimed percentage progress.

LIX. Software as a Service Disputes

If the firm provides SaaS instead of custom software, the client may not own the code. The client may only have subscription rights.

Disputes may involve:

uptime;
data export;
service termination;
subscription fees;
access rights;
data portability;
confidentiality;
vendor lock-in;
service levels;
data breach;
termination assistance.

The remedies depend on the SaaS terms.

LX. White-Label and Template Software

Some firms sell “custom systems” that are actually templates or white-label products.

This is not necessarily illegal if disclosed. It becomes problematic if the firm falsely represented that the system would be custom-built, exclusive, or owned by the client.

Evidence may include:

identical systems sold to others;
template marketplace records;
copied code comments;
third-party license terms;
lack of custom development history;
reused branding or assets.

LXI. Misrepresentation of Portfolio

A firm may show projects it did not build. This may support fraud if the client relied on the portfolio in hiring the firm.

Evidence may include:

confirmation from actual project owners;
screenshots of false claims;
archived website;
sales deck;
proposal;
chat messages;
marketing materials.

LXII. Fake Personnel or Expertise

A firm may claim to have senior developers, security experts, or certified engineers but actually uses inexperienced freelancers.

This may be fraud if the representation was material and induced the client to pay.

The contract may require named key personnel or minimum qualifications.

LXIII. Misuse of Client Business Idea

A client may fear that the developer copied the business idea and built a competing platform.

Legal protection depends on:

confidentiality agreement;
trade secret measures;
IP ownership;
non-compete or non-solicitation clauses;
unfair competition principles;
evidence of copying;
originality of idea;
whether the idea was public;
whether code or data was reused.

Ideas alone are difficult to protect unless expressed in confidential materials, code, designs, business plans, or trade secrets.

LXIV. Non-Compete Clauses

A contract may restrict the developer from building competing software for a period or using client confidential information.

However, non-compete clauses must be reasonable as to time, place, and scope. Overbroad restraints may be challenged.

A more enforceable approach is often a strong confidentiality, non-use, and non-solicitation clause.

LXV. Software Escrow

For critical systems, parties may use source code escrow. The developer deposits source code with an escrow agent, to be released if:

developer fails to maintain system;
developer becomes insolvent;
developer breaches support obligations;
developer refuses turnover;
subscription ends under specified conditions.

Software escrow is useful where the developer wants to protect proprietary code but the client needs continuity.

LXVI. Service Level Agreements

For hosted systems, service level agreements should specify:

uptime percentage;
response time;
resolution time;
maintenance windows;
backup frequency;
disaster recovery;
service credits;
escalation contacts;
security obligations;
breach notification.

Without service levels, proving breach may be harder.

LXVII. Data Migration and Exit Rights

A client should have the right to export its data in usable format upon termination.

The contract should specify:

export format;
deadline;
assistance fees;
deletion after transfer;
backup retention;
data dictionary;
database schema;
transition support.

A firm that refuses data export may expose itself to breach and data privacy claims.

LXVIII. Official Receipts and Tax Issues

A legitimate software firm should issue proper invoices or receipts. Failure to issue receipts may indicate tax noncompliance and may support credibility concerns, though it does not by itself prove fraud.

Clients should keep payment records regardless of receipts.

LXIX. Evidence Preservation Letter

A client may send a preservation notice requiring the firm to preserve:

source code;
repositories;
commits;
project files;
messages;
invoices;
subcontractor records;
server logs;
access logs;
databases;
backups;
security reports;
billing records.

Destruction after notice may affect litigation.

LXX. Role of Forensic Preservation

Where data or cybercrime is involved, technical evidence should be preserved carefully.

Steps include:

forensic imaging where possible;
exporting logs;
hashing files;
preserving timestamps;
documenting chain of custody;
keeping original devices;
avoiding alteration of evidence;
engaging qualified experts.

Screenshots are helpful but technical logs are stronger.

LXXI. Liquidated Damages and Penalty Clauses

A contract may provide fixed damages for delay or breach. This helps avoid disputes over computation.

Example:

“For each day of delay after the agreed launch date, developer shall pay ₱___ as liquidated damages.”
“For breach of confidentiality, developer shall pay ₱___ without prejudice to actual damages and injunctive relief.”

Penalty clauses must be reasonable. Excessive penalties may be reduced.

LXXII. Attorney’s Fees

Attorney’s fees may be recoverable if provided by contract or allowed by law, such as where the client was compelled to litigate due to the developer’s unjustified acts. Courts do not automatically award attorney’s fees simply because a party wins.

Include an attorney’s fees clause in the contract.

LXXIII. Interest

Refunds, unpaid amounts, or damages may earn legal interest depending on the nature of the obligation and court ruling.

Demand letters help establish when the obligation became due and when interest may begin, depending on the claim.

LXXIV. Replacement Developer Costs

If the original firm breaches, the client may hire another developer and claim the reasonable additional cost as damages.

The client should document:

original contract price;
work delivered;
deficiencies;
replacement contract;
cost to complete;
expert opinion;
invoices and payments;
necessity of replacement.

LXXV. Lost Profits

Lost profits are difficult but possible if proven with reasonable certainty.

Evidence may include:

existing customer contracts;
sales history;
pre-launch orders;
revenue projections based on actual data;
marketing campaigns;
investor agreements;
expert financial analysis.

Speculative startup projections may be rejected.

LXXVI. Moral and Exemplary Damages

Moral damages may be claimed in proper cases involving fraud, bad faith, or injury recognized by law. Corporations generally have limited ability to claim moral damages except in particular situations involving reputation.

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

These damages require proper pleading and proof.

LXXVII. Criminal Liability Does Not Guarantee Refund

Even if a criminal complaint is filed, recovery of money depends on restitution, civil liability, settlement, or enforcement against assets.

A practical recovery strategy should include:

identifying assets;
freezing or preserving funds where legally possible;
civil action;
settlement;
corporate and officer liability analysis;
tracing payments.

LXXVIII. Multi-Victim Software Fraud

If a firm defrauded multiple clients using the same scheme, evidence of pattern may strengthen fraud claims.

Victims may coordinate by:

sharing evidence;
filing separate affidavits;
identifying common misrepresentations;
tracing payment accounts;
identifying officers;
documenting repeated abandonment;
showing lack of real operations.

However, each complainant must still prove their own transaction and reliance.

LXXIX. Cross-Border Software Firms

Some firms operate abroad or use foreign developers. Cross-border disputes raise issues such as:

service of summons;
foreign jurisdiction;
enforcement of judgments;
international arbitration;
foreign payment platforms;
data transfer;
offshore hosting;
foreign subcontractors.

Contracts should identify governing law, venue, arbitration, and service addresses.

LXXX. Foreign Client vs Philippine Software Firm

If a foreign client hires a Philippine software firm, Philippine law may apply if the contract says so or if the firm and performance are in the Philippines. The foreign client may sue in the Philippines, arbitrate, or pursue remedies under the contract.

Issues include:

authentication of foreign documents;
remote testimony;
foreign currency payments;
tax treatment;
cross-border data transfer;
enforcement of awards or judgments.

LXXXI. Philippine Client vs Foreign Software Firm

If a Philippine client hires a foreign software firm, recovery may be harder. The client should consider:

contract jurisdiction;
foreign entity details;
payment method;
escrow;
milestone control;
source code access;
arbitration;
enforcement abroad;
platform dispute mechanisms.

If the foreign firm has Philippine agents, assets, or bank accounts, local remedies may be more practical.

LXXXII. Employee Developers vs Contracted Firm

Sometimes the dispute arises because the software was built by employees of the client but managed by an outside firm. Ownership of employee-created code may differ from contractor-created code.

The contract should clarify:

who owns code written by the client’s employees;
who owns code written by the firm;
who owns joint work;
who may access repositories;
who controls deployment.

LXXXIII. Work Made for Hire Misconception

Foreign concepts like “work made for hire” should not be assumed to apply automatically in the Philippines. Philippine copyright and contract rules should be expressly addressed.

If the client wants ownership, the contract should contain a clear assignment clause.

LXXXIV. Maintenance After Acceptance

Acceptance of the system does not necessarily end all obligations. The firm may still have:

warranty obligations;
maintenance obligations;
bug fix obligations;
support obligations;
data protection obligations;
confidentiality obligations;
IP indemnity obligations.

Survival clauses should state which obligations continue after termination.

LXXXV. Acceptance Certificate

A developer may ask the client to sign an acceptance certificate. The client should not sign unless the deliverables meet requirements.

If signing with reservations, state them clearly:

list pending bugs;
identify missing features;
state acceptance is conditional;
preserve warranty claims;
preserve rights to source code and turnover.

An unconditional acceptance may weaken later claims.

LXXXVI. Project Cancellation by Client

If the client cancels without developer breach, the developer may be entitled to payment for work done or termination fees, depending on the contract.

If cancellation is due to developer breach, the client may demand refund and damages.

The termination notice should clearly state the basis.

LXXXVII. Insolvency or Closure of Developer

If the firm becomes insolvent or closes, recovery may be difficult.

The client should immediately seek:

source code turnover;
data export;
repository access;
credentials;
proof of work;
claim filing in insolvency if applicable;
remedies against officers if fraud exists.

This is why source code escrow and client-owned infrastructure are important.

LXXXVIII. Practical Legal Strategy

A strong client strategy usually involves:

immediate evidence preservation;
technical audit;
contract review;
access and data security measures;
demand letter;
settlement attempt if practical;
civil action for refund, damages, turnover, or injunction;
criminal complaint only if fraud evidence is strong;
regulatory complaints for data privacy or IP issues where appropriate;
replacement development plan to mitigate losses.

LXXXIX. Practical Defense Strategy for Software Firms

A firm accused of breach or fraud should:

preserve all project records;
stop informal arguments;
review contract scope;
document completed work;
prepare deliverable inventory;
identify client-caused delays;
offer reasonable turnover where appropriate;
avoid deleting code or data;
avoid threatening the client;
respond to demand letters through counsel;
correct defects if cure is possible;
consider settlement;
prepare technical evidence;
separate civil non-performance from fraud allegations.

XC. Sample Civil Causes of Action

Depending on facts, a complaint may include:

breach of contract;
rescission;
damages;
specific performance;
injunction;
accounting;
unjust enrichment;
breach of warranty;
breach of confidentiality;
intellectual property infringement;
unfair competition;
quasi-delict;
return of property;
replevin-like recovery of equipment, if applicable;
declaratory relief on IP ownership.

XCI. Sample Criminal Theories

Depending on facts, a complaint may consider:

estafa by deceit;
estafa by misappropriation;
falsification, if fake documents were used;
computer-related fraud;
identity theft;
illegal access;
data interference;
system interference;
unauthorized use or disclosure of personal data;
other offenses depending on conduct.

A criminal complaint should be carefully grounded in facts and evidence.

XCII. Sample Evidence Index

Exhibit	Description
A	Signed software development agreement
B	Statement of work and project scope
C	Payment receipts and bank transfer records
D	Developer’s proposal and promised timeline
E	Screenshots of progress representations
F	Email notices of delay
G	Bug reports and failed test results
H	Expert technical assessment
I	Demand letter
J	Developer’s refusal or non-response
K	Proof of replacement developer cost
L	Proof of business losses
M	Repository or server logs
N	Evidence of false portfolio or credentials
O	Data breach or security report, if applicable

XCIII. Sample Contract Clauses to Prevent Future Disputes

A. Source Code Turnover

Upon full payment, Developer shall deliver to Client the complete and current source code, object code, build files, deployment scripts, database schema, documentation, and all credentials necessary to operate, maintain, and modify the software.

B. IP Assignment

Developer assigns to Client all rights, title, and interest in the custom software deliverables created specifically for Client, excluding Developer’s pre-existing tools and third-party components disclosed in writing.

C. Milestone Acceptance

No milestone shall be deemed completed unless the corresponding deliverable has passed user acceptance testing based on the acceptance criteria in Annex A.

D. Data Return

Upon termination or completion, Developer shall return all Client data in a usable format and permanently delete remaining copies, except those required by law, and shall certify deletion in writing.

E. Confidentiality

Developer shall not use or disclose Client confidential information except as necessary to perform the services.

F. Security

Developer shall implement reasonable administrative, technical, and organizational measures to protect Client systems and personal data.

G. Subcontracting

Developer shall not subcontract any work involving Client confidential information or personal data without Client’s prior written consent.

H. Delay Penalty

Developer shall pay liquidated damages of ₱___ for each day of delay beyond the agreed deadline, without prejudice to Client’s right to terminate for material breach.

XCIV. Frequently Asked Questions

1. Is failure to deliver software automatically estafa?

No. Failure to deliver may be breach of contract. It becomes estafa only if there is proof of deceit, fraudulent intent, or misappropriation.

2. Can the client demand a refund?

Yes, if the firm materially breached, abandoned the project, failed to deliver, or if rescission or refund is justified under the contract and law.

3. Does paying for software mean the client owns the source code?

Not always. Source code ownership depends on the contract and applicable IP law. A clear assignment clause is best.

4. Can the developer withhold source code because the client has unpaid balance?

It depends on the contract and circumstances. But the developer should not misuse client data, sabotage systems, or unlawfully withhold assets beyond its rights.

5. Can the client file both civil and criminal cases?

Possibly, if facts support both breach and fraud. But criminal complaints should not be filed merely to pressure payment in a purely civil dispute.

6. Can the client sue company officers personally?

Yes, if they personally participated in fraud, bad faith, misappropriation, or other wrongful acts. Mere corporate position is not enough.

7. What if the contract has an arbitration clause?

Civil disputes may need to go to arbitration. Criminal complaints and some urgent court remedies may still be separately considered.

8. Can the client recover lost profits?

Possibly, but lost profits must be proven with reasonable certainty, not speculation.

9. What if the developer used open-source code?

That may be acceptable if properly disclosed and compliant with license terms. It becomes a problem if it violates licenses or contradicts promises of exclusive custom code.

10. What if the developer caused a data breach?

The client may have data privacy obligations and may seek indemnity or damages from the developer if the breach was caused by the developer’s fault or breach.

XCV. Conclusion

Breach of contract and fraud by a software development firm in the Philippines require careful legal and technical analysis. A failed software project is not automatically a crime, but it may give rise to civil liability for breach, rescission, refund, damages, specific performance, injunction, intellectual property violations, data privacy violations, or criminal liability where deceit or misappropriation is proven.

The most important questions are:

What exactly did the contract require?
What did the developer promise before payment?
What was actually delivered?
Were delays or defects caused by the developer or the client?
Did the firm misrepresent its capacity, progress, personnel, portfolio, or expenses?
Who owns the source code and digital assets?
Was client data or confidential information misused?
What damages can be proven?
Is the case civil, criminal, regulatory, or a combination?

For clients, the safest approach is to document everything, preserve technical evidence, secure access to digital assets, obtain expert assessment, send a precise demand letter, and pursue the remedy that fits the facts. For software firms, the safest approach is to use clear contracts, avoid overpromising, document progress, protect client data, and resolve disputes in good faith.

In Philippine law, a software development firm that merely performs poorly may face civil consequences. But a firm that obtains money through deception, abandons the project in bad faith, misuses data, withholds critical assets, or fabricates progress may face far more serious civil, criminal, and regulatory liability.