Technology & Software Businesses
A Company Can Grow Faster Than Its Ability to Control What It Sells
Overview
Technology risk often comes from success, not product failure: a larger enterprise customer, broader security promises, bespoke development, more vendors, or a product moving closer to regulated finance. Each deal can add revenue and a promise nobody priced or owns internally.
Implementation may be almost complete while the customer delays acceptance because its own data or infrastructure is not ready, and the company may have promised uptime its cloud provider does not give it. We connect the contract to the product, the vendors and practical control, not to wording alone.
From the Commercial Offer to the Investment Round, Stage by Stage
Proposal and Delivery Scope
Risk usually starts in the commercial proposal: a broad promise written by Sales before Product or Delivery defined what the price includes.
Where the problem starts 2
- 01
The Proposal Promises Full Integration Without Naming the Systems
The customer may read it as a duty to connect every current and future system. Interfaces, data, responsibilities and assumptions must be named, with what happens if the customer's systems do not allow integration.
- 02
Sales Promised a Date Delivery Never Reviewed
A contract date must rest on known resources and dependencies. If go-live depends on the customer's data, approvals or infrastructure, those conditions must be written in.
What the file must show
The proposal and statement of work: functionality, integrations, assumptions, exclusions, milestones and price, with an internal owner for every material commitment.
Implementation, Testing and Acceptance
Acceptance should measure delivery, not give the customer an open right to defer payment or add requests once the core work is done.
Where the problem starts 2
- 01
The System Works but the Acceptance Certificate Is Unsigned
We examine the tests run, the defects logged and their materiality, and who had to prepare the environment, data and users. Use or migration to production may be facts the contract cannot ignore.
- 02
Every Comment Blocks Acceptance of the Whole Milestone
A defect that prevents agreed use is different from a small comment that can be fixed under warranty. Withholding the full amount over a short list is out of proportion.
What the file must show
Objective acceptance criteria, a test environment, an objection period, a definition of material defect, the effect of silence or use, and payment tied to milestones that can be proved.
Customer Obligations and Change Management
Delivery is not in the supplier's hands alone. The customer's data, decisions, users and sign-offs drive the programme, yet many contracts give their delay no consequence.
Where the problem starts 2
- 01
Customer Data Arrived Incomplete and Derailed the Migration
We define the data format and quality, who cleans and verifies it, and who signs off the migration. If the work grows because of the data, the change needs a decision before delivery continues.
- 02
Both Teams Agreed a Change That Never Reached Finance
A technical change without a priced change order turns delivered effort into an invoice dispute. The request, estimate, approval and testing must link to the affected payment.
What the file must show
A register of customer dependencies with an owner, date and consequence for each, and a short change procedure that Product, Sales and Finance can all apply.
Vendors and Cloud Services
A company may sell a commitment it does not receive upstream: higher availability, faster response, wider indemnities or a data location the provider does not guarantee.
Where the problem starts 2
- 01
The Customer SLA Is Stronger Than the Cloud Contract
We compare availability, exclusions, downtime measurement, notice and service credits. What cannot be passed through needs a cap, a price or a contingency plan.
- 02
The Vendor Can Change the Service or Price Unilaterally
Reliance on a core platform needs notice, transition, data export and a reasonable alternative, or the vendor's decision becomes a risk to the whole product.
What the file must show
A register of vendors and critical services, matching obligations, data location, audit and notice rights, and plans for outage, exit and data migration.
Product and Bespoke Development
Each major customer adds features and exceptions until the team supports several versions while pricing still assumes one product.
Where the problem starts 2
- 01
The Customer Paid for Development and Claims Ownership of Everything
Payment alone does not settle ownership. We separate the existing product and tools, the bespoke work, reusable improvements, and the customer's data and outputs.
- 02
Support Has Become Unpaid Continuous Development
Fixing a defect differs from changing a requirement or supporting a legacy version. Defining maintenance, warranty and development protects margin.
What the file must show
Boundaries between core product and bespoke work, ownership of each layer, rights of reuse, customisation and support fees, and a legacy-version policy.
Code Ownership and Practical Control
Code in a repository under the company's name does not prove ownership, and a paper transfer is not enough if deployment keys, accounts and domains stay with one person.
Where the problem starts 2
- 01
A Freelancer or Founder Wrote Code Without an Assignment
Payment or a capital contribution does not always transfer every right. We review what was created and under what agreement, then close the gap before it surfaces in an investment or sale.
- 02
Admin Accounts and Deployment Keys Sit with a Former Employee
Repositories, domains, cloud accounts, keys and certificates are inventoried and moved under company control, with permissions, logging and recovery.
What the file must show
A chain of title from founders, employees, freelancers and third parties; an open-source register; and an inventory of accounts, keys, domains and admin rights.
Data, Security and AI
Data moves between the app, the cloud, analytics, support and AI tools. A privacy policy does not show what leaves, who sees it or what happens in a breach.
Where the problem starts 2
- 01
A Developer Sent Customer Data to an AI Tool
We establish what left, whether it was personal or confidential, what the tool's terms allow on retention and training, and whether the customer contract permits it.
- 02
A Breach Occurred and Fixes Began Before Evidence Was Preserved
Containment is essential, but logs, timings and changes must be kept, the affected data and parties identified, and notices sent to vendors, customers and authorities.
What the file must show
A map of data, vendors and transfers; controller and processor roles; legal basis, retention and deletion; rules for AI tools; and an incident plan linking the technical team with legal.
Regulated Activity and Investment Readiness
A software tool may add fund collection, payments, financing or financial decisions. In an investment round, gaps in ownership, contracts and data surface when fixing them costs the most.
Where the problem starts 2
- 01
The Product Routes Payments and Calls Itself a Technical Intermediary
The label does not decide. We map the flow of funds, accounts and instructions, then test whether the function falls within the Central Bank's perimeter for payment systems and services.
- 02
The Investor Found Incomplete Code Rights or Key Contracts
We decide whether each gap is cured by a signature, a transfer of control or a contract amendment, or goes to the product's value, and close it before it becomes a valuation discount.
What the file must show
A map of the function, regulator and licences needed before launch, and an investment file covering chain of title, material contracts, vendors, data and disputes.
From the First Major Deal to Investment: Where Obligations Escape Control
- 01
Proposal & Delivery Scope
RiskA broad commercial promise becomes open-ended technical work or unpriced bespoke development.
ControlSeparate core product from custom work, assumptions, dependencies and out-of-scope items at proposal stage.
- 02
Implementation & Acceptance
RiskWork is substantially complete but payment remains tied to acceptance with no objective test, period or consequence of silence.
ControlMeasurable acceptance criteria, staged delivery, objection windows and consequences for customer delay.
- 03
Customer Dependencies
RiskCustomer data, infrastructure or approvals are late but the supplier still carries the delivery delay.
ControlA dependencies register, reciprocal responsibilities and programme/acceptance consequences for items under customer control.
- 04
Vendors & Cloud Services
RiskThe company promises service, security or remedies beyond what it receives from the upstream provider.
ControlRead both contracts together, pass through what can be passed through, and price or limit what the company cannot control.
- 05
Product & Bespoke Development
RiskCustomer-specific features turn one scalable product into multiple versions with continuing support and weaker margin.
ControlDefine core product, ownership of new code, custom-development fees and what can be reused across the market.
- 06
IP & Practical Control
RiskCode sits on company systems but was created pre-incorporation or by freelancers, while keys/accounts remain with one individual.
ControlA clear chain of title, team/freelancer agreements and an access register for repositories, deployment keys, domains and admin accounts.
- 07
Data, Security & AI
RiskCustomer data moves through cloud, analytics and external AI tools without a clear legal basis or incident responsibility.
ControlData/vendor mapping, appropriate processing/transfer terms and an incident-response workflow linking containment, evidence, notices and communications.
- 08
Regulated Expansion & Investment
RiskProduct functionality moves into payments, finance or another regulated activity, or diligence exposes ownership/contract gaps at a sensitive moment.
ControlEarly regulatory-perimeter review plus chain-of-title, material contract and data remediation before launch or fundraising.
Where Problems Surface
- 01
Acceptance Can Become a Lever over Cash
Acceptance should measure delivery, not create an open-ended right to delay payment. Objective criteria, testing, objection periods and the effect of customer delay all matter.
- 02
Customer and Vendor Contracts Must Match
If the company promises availability, security or response times its cloud provider does not support, it carries a gap it cannot control. Reviewing only the customer contract misses the real exposure.
- 03
IP Ownership Needs Chain of Title and Practical Control
An investor asks who created the code, under what assignment, which open-source components apply and who controls the repositories, keys and accounts.
- 04
Product Function Matters More Than Its Label
If the product starts executing payments or financing, calling the business a software company does not decide its regulatory status. The perimeter is tested before launch.
Legal Framework
One file can combine IP, electronic contracting, data, cyber and financial regulation. Scope depends on what the product does, not the company's label.
Civil Code No. 131 of 1948 and Trade Law No. 17 of 1999
The general framework for contracts, obligations, performance, termination and damages in development, licensing and support agreements.
Intellectual Property Law No. 82 of 2002
Software/copyright rights, assignments, licences and the chain of title from founders, employees, freelancers and third parties.
Electronic Signature Law No. 15 of 2004 and its Executive Regulations
The framework relevant to electronic signatures, electronic writings/records and related trust services, as applicable.
Personal Data Protection Law No. 151 of 2020 and Executive Regulations No. 816 of 2025
Processing, controller/processor roles, direct marketing, transfers and licensing/permit obligations depending on the processing model.
Law No. 175 of 2018 on Combating Information Technology Crimes
Unauthorised access, systems/data offences and digital identity risks, making access governance and evidence preservation legally relevant.
Central Bank and Banking Sector Law No. 194 of 2020, together with the licensing and registration rules applicable to Payment System Operators and Payment Service Providers issued by the Central Bank of Egypt, depending on the nature and function of the product.
Where the product operates a payment system or provides payment services within the CBE licensing or registration perimeter.
Law No. 5 of 2022 on the Use of Financial Technology in Non-Banking Financial Activities and FRA Rules
Where technology is used to conduct a regulated non-banking financial activity; it does not apply merely because a company uses modern technology.
Consumer Protection Law No. 181 of 2018, where applicable
For consumer-facing products/services and the information, claims and guarantees presented to users.
Does This Look Like Your Current Operating Model?
More than one of these usually means growth has moved ahead of legal and operational control.
00 / 07
Tick what applies to your business today.
How MASAR Works
We start with what the business actually sells: scope, acceptance, customer dependencies, vendors, service levels, code and rights, accounts, data flows and any regulated function. Each material commitment gets an internal owner and an evidence trail.
Before an investment or sale, we review chain of title, material contracts, vendors, data and regulatory exposure early, so a fixable point does not become a valuation adjustment.
- For customer/implementation agreements, acceptance, bespoke development, vendors/resellers, IP, data, security, AI and investment readiness.
- Where product functionality approaches payments, financing or another regulated activity, we identify the actual function, regulator and required permissions before technical build gets ahead of the legal perimeter.
MASAR TechShield™
Protect what the company builds. Structure what it sells. Prepare it for what comes next.
MASAR Recovery™
For businesses that sell on credit: we build credit relationships that stay collectable from the first invoice, and recover what is overdue by the route that protects both the money and the relationship.
Practical Situations
Illustrative situations showing how MASAR approaches a file. They are not disclosed client engagements or guaranteed outcomes.
- 01
Implementation Is Substantially Complete but Customer Acceptance and Payment Are Delayed
We test the acceptance criteria, delivered functionality and customer dependencies, separating genuine defects from data/infrastructure or decisions under customer control. Acceptance should not become an undefined payment hold after substantial delivery.
- 02
Investor Diligence Finds the Company Does Not Own or Control All Code and Accounts
We map chain of title across founders, employees, freelancers and open-source components, then move practical control of repositories, keys and domains into an institutional structure before the gap becomes valuation leverage.
- 03
A New AI Feature Sends Customer Data to an External Model
We start with the data flow, vendor terms and customer promise: what leaves, why, whether the contract permits it, what the model provider may retain or use and who bears output risk. Drafting follows the real use case.
- 04
A Collections or Payments Product Is Expanding into a Possibly Regulated Function
We map the flow of instructions, funds and accounts, and decide whether the company supplies software to a licensed institution or itself provides a payment service or financial activity. Only then is the required licence, approval or partnership clear.
What We Need to See
We start with the file, not the opinion. These documents show the strength of a position and its gaps fastest.
Customer agreements, statements of work and change orders.
Acceptance criteria, testing records and customer dependencies.
Cloud, platform and vendor agreements and service levels.
Founder, employee and freelancer agreements and IP assignments.
Open-source register and an inventory of repositories, domains, keys and admin access.
Data-flow map, processor agreements, AI vendor terms and incident records.
Licences or regulatory correspondence for any payment or financing function.
Common Questions
Start with the Document
Send the customer agreement or statement of work, acceptance terms and the vendor/data-flow document driving the issue. We read the commercial promise, delivery capability and control chain first, then identify what needs contractual, operational or regulatory change.
Talk to MASAR before a growth deal becomes an obligation the company does not control.