ScaleDux Project Transaction Terms
ScaleDux Software Innovations Private Limited
Effective date: 03/08/2026 | Last updated: 03/08/2026
These Project Transaction Terms explain how Projects work on ScaleDux, from posting a requirement and receiving Proposals to sending an Offer, making payment, starting the Project, reviewing Deliverables, handling Revisions, completing Handover, and closing or resolving a Project.
They apply to Founders, Experts and Agencies using ScaleDux for Project-based work. Together with the ScaleDux Terms of Service and the other policies referred to in these Terms, they form part of the legally binding rules that govern every Project carried out through the Platform.
ScaleDux provides the technology, payment-linked workflow, Project records, review process and administrative support that help both sides work with greater clarity and accountability. The actual Project Contract is between the Founder and the Expert or Agency. Each party remains responsible for the commitments, information, work, decisions and obligations they take on through that Project.
We have written these Terms to make the Project journey clear before either side commits. Important actions such as Offer acceptance, payment, Project activation, Deliverable approval, Revisions, changes, Handover and disputes are recorded through the Platform so that both sides have a clear and reliable record of what was agreed and what happened.
Part A – Common Project Terms
1. Purpose, Application and Contractual Status
1.1 Purpose
These Project Transaction Terms establish the common legal and operational framework governing Founder, Expert and Agency Projects conducted through ScaleDux. They regulate public Project discovery, Invitations, Proposals, confidentiality, Offers, acceptance, payment-linked Hire and activation, performance, Deliverable review, Revisions, Supplier Invoices, Milestone closure, payout eligibility, Settlement Hold release, intellectual property, Handover, completion, termination, evidence and the relationship between the Users and ScaleDux.
1.2 Application
These Project Transaction Terms apply when a Founder creates, publishes, invites, discusses, offers, funds, manages, reviews, changes, completes, cancels or disputes a Project through ScaleDux and when an Expert or Agency views, responds to, accepts, performs, submits, revises, hands over, completes, cancels or disputes that Project.
Part A applies to every Project participant. Part B applies to the Founder. Part C applies to the Expert or Agency. Part D governs the Project lifecycle, transaction states, evidence and administrative rules applicable to all participants.
1.3 Electronic Acceptance
A User accepts the provisions applicable to that User by taking the Platform action identified as acceptance, including publishing a Project, sending or responding to an Invitation, submitting or revising a Proposal, sending or accepting an Offer, signing an NDA, completing payment, accepting a Change Order or additional Milestone, submitting or accepting a Deliverable, accepting an Invoice, restoring or completing a Project, raising or responding to a dispute, or continuing an activated Project after the applicable terms have been clearly displayed or linked.
Electronic proposals, revision requests, acceptances, declines, withdrawals, reasons, notices, acknowledgements, approvals, rejections, submissions, invoices, dispute statements and Transaction Records may be created and communicated through the Platform. ScaleDux may retain the document version, User, Account, role, represented entity, Project, Offer, Milestone, timestamp, session and other reasonable audit information associated with the action.
1.4 Relationship With Other Documents
The ScaleDux Terms of Service is the umbrella agreement. These Project Transaction Terms are binding supplementary Transaction Terms incorporated under the Terms of Service. The Community Guidelines govern conduct, safety, confidentiality and Circumvention. The Privacy Policy governs ScaleDux processing of personal data. The ScaleDux Payment and Payout Terms govern Payment Orders, payment verification and capture, Razorpay Route Transfers, Settlement Holds, payout eligibility, Release Instructions, Transfer and settlement status, Refund execution, reversals, Chargebacks, tax records, payment evidence and reconciliation. The Project Cancellation and Refund Policy governs Project cancellation, termination and Refund eligibility. The Project Dispute Resolution Policy governs ScaleDux contractual dispute procedures. The Fees and Commission Schedule states applicable ScaleDux Charges.
The final accepted Offer, accepted Change Orders and other Project-specific Transaction Records govern commercial particulars that these Project Transaction Terms permit the Users to customise, including scope, Deliverables, Milestones, price, Delivery Deadlines, Acceptance Criteria, Founder Inputs, Dependencies and approved Revisions. A Transaction Record shall not override Applicable Law, the Terms of Service, a ScaleDux Charge, Payment Provider requirement, non-circumvention obligation, Community Guideline, Platform enforcement right or another mandatory Platform rule.
1.5 Version Governing an Active Project
The versions of the applicable legal documents recorded when ScaleDux issues the Activation Confirmation ordinarily govern the activated Project. A later version applies prospectively to a new Project or to an existing Project only where Applicable Law requires the change, the existing terms permit the change for the relevant subject, or the affected Users expressly accept the new version through a recorded Platform process.
1.6 Current and Future Project Features
These Project Transaction Terms govern the current fixed-price and milestone Project workflows and any materially similar Project feature that ScaleDux expressly makes subject to them. A future hourly, retainer, subscription, recurring, contest, consultation or other Project model shall not be treated as launched or governed by these Terms unless ScaleDux identifies the applicable formation, payment, timekeeping, acceptance, cancellation and dispute rules before the User is required to use that model.
2. Definitions and Interpretation
2.1 Terms Defined in the Terms of Service
Capitalised words not separately defined in these Project Transaction Terms have the meaning given to them in the current Terms of Service, including Account, Agency, Applicable Law, Approved Conversion, Circumvention, Community Guidelines, Confidential Information, Covered Commercial Relationship, Covered Services, Expert, Founder, Invitation, Offer, Payment Provider, Platform, Platform Introduction, Project, Proposal, Public Project Posting, Public Website Information, Refund, Related Account, Settlement Hold, Transaction Record, Transaction Terms, User and User-to-User Service Amount.
Payment-specific capitalised words not separately defined in these Project Transaction Terms have the meaning given to them in the ScaleDux Payment and Payout Terms, including Captured Payment, Payment Order, Payment Evidence, Payout Eligibility Event, Receiver Amount, Release Instruction, Service Supplier, Transfer and Transfer Status.
2.2 Project-Specific Definitions
Acceptance Criteria means the objective, measurable, functional, technical, quality, format, documentation or other requirements recorded in the Offer or an accepted Change Order against which a Deliverable is reviewed.
Accepted Deliverable means a Deliverable that the Founder expressly accepts or that the Platform records as automatically accepted after the Review Period expires without a valid Founder action or recorded pause.
Activation Confirmation means the Platform record issued after the applicable Hire Confirmation, stating that the required payment condition has been satisfied and that the Project or identified Milestone is active and may commence. The Hire Confirmation and Activation Confirmation may be issued through the same recorded Platform event or through immediately connected Platform events, but neither arises merely because the Offer or NDA has been accepted or signed.
Activation Date means the calendar date recorded in the Activation Confirmation for commencement of the relevant Project or Milestone.
Agency Personnel means the Agency Team Members, employees, contractors, subcontractors or other authorised persons used by an Agency to perform a Project.
Background Intellectual Property or Background IP means intellectual property owned, controlled or lawfully used by a User before the Project or developed independently of the Project without use of the other User’s Confidential Information.
Change Order means a Platform Transaction Record accepted by the relevant Users that changes an activated Project, including scope, Deliverables, Milestones, price, schedule, Acceptance Criteria, dependencies or another material term.
Cure Period means the reasonable period displayed by the Platform after a termination notice during which the notified party may remedy the stated curable ground or the parties may restore the Project, subject to clause 43.
Day 0 means the Activation Date recorded after successful payment, Hire Confirmation and Activation Confirmation.
Day 1 means the calendar day immediately following Day 0 in the Project Time Zone.
Deliverable means the identifiable work product, output, file, code, design, document, service result, configuration, report, material or other item required under the Offer or an accepted Change Order.
Delivery Deadline means the date and time by which a Deliverable or Milestone must be submitted, as recorded in the applicable Transaction Record.
Dependency means an input, approval, access, decision, third-party service, external event or other condition on which performance materially depends.
Dispute Module means the in-Platform workflow, when available, through which an eligible User may select a dispute category, provide a statement, upload supporting evidence, receive notices and respond to requests concerning a Project dispute.
Founder Input means information, Content, decision, approval, access, data, credential, reference, asset, feedback or cooperation the Founder must provide for performance.
Handover means the controlled transfer of Deliverables, source materials, documentation, credentials, access, licence information and other Handover Materials required to enable the Founder to use and control the accepted work.
Handover Materials means the source files, repositories, documentation, credentials, configuration details, inventories, third-party and open-source notices, deployment instructions, access records and other materials specified in the Offer or reasonably necessary for the agreed use of an Accepted Deliverable.
Hire Confirmation means the Platform record issued after the required Project amount or applicable Milestone amount has become a Captured Payment in accordance with the ScaleDux Payment and Payout Terms, notifying the Founder that the Expert or Agency has been hired and notifying the Expert or Agency that it has been hired for the identified Project. A Hire Confirmation does not arise from Project publication, an Invitation, Proposal, shortlist, Offer, NDA signature, Offer acceptance, payment initiation or bank debit alone.
Invoice means the Supplier Invoice generated or made available through the authorised Project workflow on behalf of the Expert or Agency after the applicable Milestone Deliverables have been accepted or otherwise closed. The Expert or Agency remains the supplier of the underlying Project service and is responsible for the accuracy of its supplier, tax and service information, subject to the ScaleDux Payment and Payout Terms and Applicable Law.
Invoice Review Period means the Platform-set period displayed after an Invoice is issued or submitted within which the Founder may accept the Invoice or raise a supported Invoice-specific issue. The current standard Invoice Review Period is forty-eight continuous hours. ScaleDux may set and display a longer Platform-level period before the period begins. Neither User may privately shorten, extend or waive the period outside the supported workflow.
Manage Project Workspace means the common Platform workspace through which the Founder and the Expert or Agency administer an activated Project, including Deliverables, files, comments, Submissions, Revisions, decisions, Invoices, Milestones, notices and activity history.
Milestone means a separately described stage of a Project with identified Deliverables, Acceptance Criteria, amount and Delivery Deadline.
Milestone Closure Confirmation means the Platform record stating that the Deliverables required for a Milestone have been accepted or otherwise closed, the applicable Invoice has been accepted or deemed accepted, and the Milestone is closed for Project administration.
Positive Partial Project Completion means a mutual, non-fault closure in which the parties agree that completed or accepted work shall be concluded and remaining unstarted or discontinued work shall be closed under clause 42.
Project Brief means the Founder’s description of the Project requirement, objectives, scope, users, constraints, Deliverables, timeline, budget position, dependencies and other information made available for evaluation.
Project Completion Confirmation means the Platform record stating that all required Milestones have been closed, or that the Project has otherwise been positively completed under clause 42, and that no further Milestone may be added unless the Platform expressly permits the Project to be reopened through a new authorised process.
Project Contract means the user-to-user contract formed under clause 7.11 between the Founder and the accepted Expert or Agency.
Project Materials means Content, information, systems, data, credentials, documents, designs, code, brands, specifications and other materials supplied or made accessible by the Founder for the Project.
Project Time Zone means the time zone displayed in the Transaction Record, or India Standard Time where no different time zone is displayed.
Proposal Change Request means the Founder’s Platform-recorded request that an Expert or Agency revise, clarify or reconsider one or more terms of an unaccepted Proposal, including scope, Deliverables, Project structure, price, schedule, assumptions, dependencies or exclusions.
Replacement Submission means a new Submission expressly identified as replacing an earlier Submission for the same Deliverable or Milestone.
Review Period means the Platform-set period displayed after a valid Submission or Replacement Submission within which the Founder may accept the Deliverable, request a permitted Revision, reject where the workflow permits, raise a supported dispute or take another action expressly provided by the Platform. The current standard Review Period is forty-eight continuous hours. ScaleDux may set and display a longer Platform-level period before the period begins. Neither User may privately shorten, extend or waive the period outside the supported workflow.
Revision means a correction or modification reasonably required to bring a Deliverable into conformity with the recorded scope and Acceptance Criteria, excluding new or changed scope.
Submission means the Platform-recorded delivery of a Deliverable or Milestone for Founder review.
Work Product means the copyrightable or otherwise protectable material created specifically by the Expert or Agency in performing the Project, excluding Background IP, third-party material and open-source components.
2.3 Interpretation
A reference to acceptance includes an express acceptance and an automatic or deemed acceptance recorded under these Project Transaction Terms. A reference to successful payment means a Captured Payment confirmed under the ScaleDux Payment and Payout Terms. A reference to payout eligibility or release does not mean that a Transfer has been processed, settlement has been processed or the recipient bank has credited the amount.
A reference to a reason, comment, statement or evidence means information provided honestly, in good faith and with sufficient detail for the applicable decision. Headings assist navigation and do not limit a provision. Words such as including, includes, for example and such as introduce non-exhaustive examples. A reference to a law includes its amendments, replacements, subordinate legislation and binding directions.
3. ScaleDux’s Role and the User-to-User Project Contract
3.1 Technology and Administrative Role
ScaleDux provides technology for public and logged-in Project discovery, Invitations, Proposals, communication, Offers, payment-linked administration, Manage Project Workspaces, records, reviews and dispute processing. ScaleDux may administer Project states, receive evidence and apply the applicable Platform rules, but does not become the provider of the underlying Expert or Agency services merely because the Project is discovered, formed, performed or paid through ScaleDux.
3.2 User-to-User Project Contract
The Project Contract is between the Founder and the Expert or Agency identified in the accepted Offer. ScaleDux is not a party to that underlying contract unless ScaleDux expressly signs a separate written agreement stating otherwise.
3.3 No Employment, Agency or Partnership
The Project does not create employment, partnership, joint venture, fiduciary duty or authority for one User to bind another or ScaleDux. Each Expert and Agency operates as an independent business and remains responsible for its personnel, taxes, registrations, insurance, statutory duties and manner of performance, subject to the agreed Deliverables, Acceptance Criteria, security and access restrictions.
3.4 No Guarantee of Outcome
ScaleDux does not guarantee that a Project will receive Proposals, that a Founder will select a provider, that an Expert or Agency will be hired, that the Project will be completed, that a Deliverable will be commercially successful or that a dispute will be resolved in a User’s favour.
3.5 Administrative Decisions
ScaleDux may facilitate communication, seek clarification, request evidence, mediate in good faith and make administrative decisions concerning Project eligibility, Platform states, evidence, access, reviews, Account restrictions and Platform-controlled transaction processing under the applicable documents.
ScaleDux may implement only an action within its contractual authority, operational capacity and control, including a supported Project-state change, request for Revision, Milestone closure, payment recommendation, Refund or payout instruction where the applicable financial terms permit, termination, access restriction or other Platform action. ScaleDux does not make a binding legal judgment concerning civil liability, criminal guilt, fraud damages, professional negligence, intellectual-property ownership, employment status or the enforceability of an external agreement.
3.6 Rights Preserved
Nothing in these Project Transaction Terms excludes a right, remedy or liability that cannot lawfully be excluded. A User may pursue an external remedy available under Applicable Law, subject to the dispute provisions governing claims against ScaleDux and any valid agreement between the Users.
4. Supported Project Structures and Lifecycle
4.1 Fixed-Price and Milestone Projects
ScaleDux currently supports fixed-price Projects and Milestone Projects. A fixed-price Project may contain one or more Deliverables under one stated Project amount and is treated as one funded financial unit. A Milestone Project contains separately described Milestones, each with identified Deliverables, Acceptance Criteria, amount and Delivery Deadline, and is ordinarily funded one Milestone at a time. Each Additional Milestone must be separately accepted, paid, captured and activated before performance begins.
4.2 Lifecycle Stages
The Project lifecycle may include Project creation, public or logged-in discovery, individual Invitations, Invitation responses, Proposals, Proposal Change Requests, revised Proposals, Proposal withdrawal, Proposal decline, shortlisting, Offer preparation, Offer transmission, NDA review, NDA revision, final NDA signature where required, Offer acceptance, payment pending, Payment Order creation, payment capture, creation of a Razorpay Route Transfer subject to Settlement Hold, Hire Confirmation, Activation Confirmation, performance through the Manage Project Workspace, Deliverable Submission, review, Revision, Replacement Submission, acceptance, automatic acceptance, Invoice request or submission, Invoice review, Milestone Closure Confirmation, Payout Eligibility Event, Settlement Hold release, Change Order, extension, Additional Milestone request, Project Completion Confirmation, Positive Partial Project Completion, termination notice, Cure Period, restoration, final termination, Refund, dispute, internal review and review or feedback.
Each stage has the legal and administrative effect stated in these Project Transaction Terms and the corresponding Platform record. Offer acceptance records the Expert or Agency agreement to the final Offer but does not constitute Hire, successful payment or Project activation. Hire and activation occur only after the required payment becomes a Captured Payment and ScaleDux issues the corresponding confirmations. Payment capture and Transfer creation do not mean that the Expert or Agency is payout eligible or that settlement has occurred.
4.3 Project States
A displayed state such as draft, published, invited, Invitation declined, Proposal received, Proposal change requested, Proposal revised, Proposal withdrawn, Proposal declined, shortlisted, Offer sent, NDA review pending, NDA revision requested, Offer re-sent, Offer declined, Offer withdrawn, Offer accepted, payment pending, payment failed, payment successful, hired, active, Deliverable submitted, Revision requested, Deliverable accepted, Deliverable auto-approved, Invoice requested, Invoice submitted, Invoice accepted, Invoice auto-accepted, Milestone closed, payout eligible, release submitted, Transfer delayed, completed, termination notice issued, Cure Period active, restored, terminated, disputed or closed describes the Platform administration of the Project.
A User shall not represent a state as having occurred before the corresponding Platform event. An NDA signature does not by itself mean that the Offer has been accepted, payment has succeeded or the Expert or Agency has been hired. An Offer accepted state means that the final Offer and, where applicable, the final NDA have been accepted, but the Project remains payment pending. A hired state may be recorded only after the applicable payment becomes a Captured Payment. An active state may be recorded only after ScaleDux issues the Activation Confirmation.
Project states and financial states are separate. Payment successful does not mean Deliverables have been accepted, payout is eligible, the Settlement Hold has been released, the Transfer has been processed, settlement has been processed or the recipient bank has credited the amount.
4.4 Transaction Record
The Transaction Record may include the Project Brief, public Project fields and attachments, skills, Invitations, Invitation messages and responses, Proposal versions, Proposal Change Requests, decline or withdrawal reasons, shortlist records, Offer versions, NDA versions and signatures, Payment Order, Payment ID, Transfer ID, Settlement Hold and Release Instruction records where retained, Hire Confirmation, Activation Confirmation, Manage Project Workspace activity, Deliverables, Acceptance Criteria, Submissions, Revisions, comments, decisions, Invoices, Milestone closure, Change Orders, extension requests, Additional Milestone requests, completion and termination records, dispute submissions, notices, reviews and other Platform records incorporated into the Project.
A mandatory reason, comment or response becomes part of the Transaction Record and shall be accurate, relevant, professional and made in good faith. ScaleDux may preserve earlier versions and event history for administration, evidence, security, payment, dispute, tax and legal purposes in accordance with the Privacy Policy and Applicable Law.
4.5 No Retroactive Platform Coverage
Work, scope, payment, Invoice, Milestone or commercial activity conducted outside the required Platform workflow does not become part of the Project merely because the parties later mention it in the Manage Project Workspace or upload a related record. Clause 45 governs off-Platform activity and mixed transactions.
5. Project Creation, Invitations, Proposals and Shortlisting
5.1 Lawful and Genuine Purpose
A Project must concern a genuine and lawful business requirement. A User shall not create, publish, invite, respond to or submit a Proposal for fraud, lead harvesting, competitive intelligence, unpaid idea extraction, academic misconduct, illegal activity, prohibited regulated services or another purpose inconsistent with the Terms of Service or Community Guidelines.
5.2 Skills-Based Discovery and Project Visibility
ScaleDux may make a Public Project Posting available without login through a public webpage, unauthenticated Platform interface, content-delivery link or search-engine result. The Public Project Posting may include selected Project fields and any image, document or other attachment uploaded to a field identified as public. Public Project Postings and public attachments may be viewed, downloaded, copied, cached, indexed or shared outside ScaleDux.
Public visibility does not permit a Visitor to submit a Proposal, send a Project message, receive restricted files or take another Project action that requires an eligible Account. Full contact details, Proposals, Offers, NDAs, private messages, Manage Project Workspace files, Deliverables, Invoices, payment records, support records and dispute records remain Restricted Platform Information unless ScaleDux expressly identifies a particular item as public.
ScaleDux may display a Project to Experts or Agencies whose recorded skills, categories, experience, preferences or other matching signals appear relevant. Project visibility, ranking or matching does not certify suitability, availability, authority or capability and does not guarantee that a User will receive an Invitation, Proposal, shortlist or Offer. An eligible Expert or Agency that lawfully discovers a Project may review the information available to that Account and submit a Proposal through the supported workflow.
5.3 Founder Invitations
A Founder may use the authorised Project workflow to view relevant Experts or Agencies and send individual Invitations to one or more recipients. Each Invitation shall relate to the identified Project and may include a Project-specific message explaining why the Founder is inviting that recipient or what the Founder wishes the recipient to review.
An Invitation is a request to evaluate the opportunity. It is not an Offer, shortlist, Hire, exclusivity commitment, guarantee of selection or promise of payment.
5.4 Invitation Privacy and Recipient Action
Each Invitation is an individual Platform communication. A recipient shall not be shown the identity, response or confidential Invitation information of another invited Expert or Agency except where the Platform expressly discloses aggregated information that does not identify another User.
A recipient may review, decline, ignore or respond to an Invitation and may submit a Proposal through the Project workflow. Where the Platform requires a decline reason or comment, the recipient shall provide a genuine, relevant and professional response.
5.5 Proposal Submission
An Expert or Agency may submit a Proposal after discovering the Project or receiving an Invitation. The Proposal may recommend a fixed-price structure or Milestone structure and shall identify the proposed scope, Deliverables, Project structure, personnel, assumptions, exclusions, dependencies, price, delivery position, Revisions and material limitations.
A Proposal is not the final Project Contract and does not create a payment entitlement, exclusivity or obligation to send or accept an Offer unless and until the relevant terms are incorporated into a final accepted Offer and the Project is activated.
5.6 Founder Proposal Review and Change Request
The Founder may review each Proposal through the applicable proposal review workflow. Before declining or shortlisting a Proposal, the Founder may issue a Proposal Change Request identifying the term or information that requires clarification, correction or revision.
The parties may discuss the request through Platform messaging and may use a permitted External Channel for clarification in accordance with clause 8. The Founder shall not use a Proposal Change Request to require material unpaid work, to obtain confidential methods or to introduce undisclosed work that should be separately scoped.
5.7 Revised Proposal and Version Control
After receiving a Proposal Change Request, the Expert or Agency may revise and re-submit the Proposal, decline the requested change, or withdraw the Proposal. A revised Proposal shall identify the updated scope, Deliverables, price, schedule, assumptions, dependencies or other changed terms and shall replace the earlier Proposal only for future evaluation.
ScaleDux may preserve each Proposal version, request, response, timestamp and comment. A discussion or requested change is not accepted merely because it was mentioned in chat; the revised Proposal controls only when it is submitted through the authorised workflow.
5.8 Proposal Withdrawal
An Expert or Agency may withdraw an unaccepted Proposal through the applicable workflow. Where the Platform requires a reason and comment, the Expert or Agency shall select the most accurate reason and provide a concise and genuine explanation. Withdrawal closes that Proposal for further selection unless the Platform permits a new Proposal to be submitted.
A withdrawal shall not be used to conceal Circumvention, pressure the Founder, avoid an existing confidentiality obligation or remove evidence of a prior representation.
5.9 Founder Proposal Decline
The Founder may decline one, several or all Proposals. A decline shall be made individually through the applicable workflow and shall include the required reason and any mandatory comment. The reason and comment shall be truthful, relevant, professional and sufficiently clear to explain the decision.
The declined Expert or Agency may be notified of the reason and comment, subject to redaction or withholding where reasonably necessary for safety, privacy, confidentiality, security or prevention of abuse. A Proposal decline does not constitute a finding of incompetence or misconduct and does not create a payment entitlement.
5.10 Shortlisting
The Founder may shortlist one or more Proposals for further consideration. Shortlisting indicates continued evaluation only. It does not create exclusivity, commitment, payment entitlement or an obligation to send or accept an Offer. The Founder may later remove or decline a shortlisted Proposal through the displayed workflow and shall provide a required reason where the Platform requests one.
5.11 Offer From a Shortlisted Proposal
The Founder may prepare an Offer for a shortlisted Expert or Agency after completing the necessary clarification and verifying the final commercial particulars. The Offer may adopt, modify or replace terms proposed earlier, but every material difference shall be clearly recorded for review before acceptance.
A Founder shall not send an Offer without a genuine intention and practical ability to proceed if the Offer is accepted and the required payment is made.
5.12 No Pre-Offer Commitment
A Project description, Invitation, Proposal, Proposal Change Request, revised Proposal, shortlist, external call, statement of intention or verbal understanding is not the active Project Contract. Users proceed at their own risk if they perform or request material work before the formation, payment, Hire and activation conditions in clause 7 are satisfied.
6. Confidentiality, NDAs and Progressive Disclosure
6.1 Baseline Confidentiality
The Terms of Service and Community Guidelines impose baseline confidentiality and permitted-purpose duties for non-public Project information. A User shall use non-public Project information only to evaluate, form, perform, administer or review the Project and shall not use it for unrelated competition, solicitation, publication, model training, recruitment or commercial exploitation.
A Public Project Posting or public Project attachment is not Confidential Information merely because it is hosted by ScaleDux or relates to a Project. Public availability does not authorise scraping, bulk extraction, harassment, unlawful profiling or another use prohibited by the Terms of Service, Community Guidelines or Applicable Law.
6.2 Founder Responsibility for Disclosure
The Founder controls the Project Materials and remains responsible for deciding what to disclose, to whom, at what stage and under what protection. Information uploaded to a public Project field is treated as public and may remain available in downloaded, cached, indexed or independently retained copies even after ScaleDux removes or restricts the original.
The Founder shall disclose progressively and shall not place trade secrets, credentials, source code, raw customer information, sensitive personal data, unreleased intellectual property, restricted documents or information subject to an NDA in a Public Project Posting or public attachment area. The Founder represents that it has the rights, authority, notices and permissions required to make the submitted public information available.
6.3 NDA-Required Projects
Where the Founder marks a Project as NDA Required, the Public Project Posting shall contain enough non-confidential information for an Expert or Agency to assess relevance and shall state that additional information will be shared only after the applicable NDA becomes effective.
An NDA requirement does not make information already placed in a Public Project Posting or public attachment confidential and does not operate retroactively. Confidential Project Materials must be withheld until the applicable NDA is effective and a restricted disclosure channel is available.
6.4 Early NDA Through Messaging
A Founder may send an additional NDA through Platform messaging and obtain the recipient’s signature before sharing sensitive information required for clarification or Proposal preparation. The parties are responsible for ensuring that the correct document is signed by persons with authority.
6.5 Offer-Stage NDA and Offer Acceptance Gate
Where an NDA is required and the final NDA has not already been signed through an earlier authorised Platform workflow, the Founder shall attach or include the proposed NDA when sending the Offer. The Expert or Agency shall review the Offer and the attached NDA before taking any acceptance action.
Where the Expert or Agency requires a change to the NDA or another material Offer term, it shall not accept the Offer or represent that the final NDA has been agreed. It shall return or submit the requested change through the applicable workflow. The Offer shall remain pending or shall move to the applicable revision-requested state.
The Founder may accept, reject or discuss the requested change and, where a revision is agreed, shall upload or attach the revised final NDA and re-send the Offer through the authorised workflow. Any material amendment to the Offer or NDA after the earlier transmission requires the Expert or Agency to review the revised version and provide a fresh acceptance.
Where the workflow requires an Offer-stage NDA, the Expert or Agency shall sign the final NDA and accept the final Offer through the same authorised workflow or through connected recorded actions identified by the Platform. The Offer shall not be recorded as accepted until the required final NDA signature has been completed and recorded.
Where the final NDA was already signed through an earlier authorised Platform workflow, the Offer shall identify or reference the governing signed version. A duplicate signature is not required unless the NDA has been amended, replaced or the Platform expressly requires re-execution.
NDA signature and Offer acceptance may form part of one recorded workflow, but neither event constitutes successful payment, Hire or Project activation.
6.6 NDA Version Control, Revision and Governing Version
The parties shall identify the final NDA version, its date, signatories, signature status and effective date. A draft, negotiation copy, unsigned copy, marked-up copy or earlier signed version shall not silently replace the final governing version.
Where an NDA is revised after an Offer has been sent, the revised NDA shall be uploaded or attached through the same Offer workflow and the revised Offer shall be re-sent to the Expert or Agency. The Expert or Agency shall review and sign the revised final NDA before the Offer may be recorded as accepted.
Unless the final NDA expressly states otherwise, a revised NDA does not automatically supersede an earlier signed NDA merely because the revised document was uploaded or discussed. Supersession must arise from the language of the final NDA, the recorded agreement of the parties or Applicable Law.
ScaleDux may retain the Offer identifier, NDA version, upload record, signatory, represented entity, signature timestamp, acceptance timestamp and related audit information. Such records assist Platform administration but do not make ScaleDux a party, drafter, approver, witness, guarantor or legal adviser concerning the NDA.
6.7 Pre-NDA Communication
An NDA requirement does not prohibit all pre-NDA communication. Each User shall exercise judgment, limit disclosure and avoid relying on the existence of a future NDA as protection for information disclosed before that NDA becomes effective.
6.8 External Tools and Confidential Information
A User shall not place Confidential Information, personal data, code, credentials or Project Materials in an external collaboration or AI service unless authorised and reasonably satisfied that the service’s security, retention, access, training and contractual conditions are compatible with the Project obligations.
7. Offer, Acceptance, Hire, Payment and Activation
7.1 Offer Preparation and Transmission
The Founder shall prepare and send the Offer through the authorised Platform workflow after completing the clarification reasonably necessary to identify the intended scope, Deliverables, Milestones, price, timing, Acceptance Criteria, Founder Inputs, dependencies, intellectual-property position, security requirements, Handover obligations and other material commercial particulars.
Where an NDA is required and has not already been finally executed through an authorised Platform workflow, the Founder shall attach or include the proposed NDA with the Offer. Where an earlier signed NDA is intended to govern, the Founder shall identify or reference that governing version in the Offer.
The Offer shall not be used to introduce a material term that was deliberately concealed during evaluation, to change an agreed commercial understanding without disclosure or to pressure the Expert or Agency through false urgency.
Where the Expert or Agency requests a material correction to the Offer or NDA, the Founder may revise and re-send the Offer. A materially revised Offer shall be treated as a new Offer version and shall require fresh review and acceptance by the Expert or Agency.
7.2 Minimum Offer Contents
The Offer shall identify the parties, Project structure, scope, Deliverables, Milestones, amounts, Delivery Deadlines, Acceptance Criteria, included Revisions, Founder Inputs, Dependencies, third-party costs, Handover requirements, confidentiality position, intellectual-property position, security requirements, Invoice position, applicable legal documents and Offer Validity Period. A missing matter shall be interpreted under these Project Transaction Terms and the applicable Platform defaults, not through an undisclosed private expectation.
Before the Expert or Agency accepts the final Offer, ScaleDux shall display the applicable Project commission rate, processing-charge allocation and other ScaleDux Charges required by the ScaleDux Payment and Payout Terms and Fees and Commission Schedule. Those Platform charges are not editable by the Founder and become part of the Transaction Record when the Offer is accepted.
7.3 Offer and NDA Review, Clarification and Revision
The Expert or Agency shall review the complete Offer, each attached or referenced NDA, the scope, Deliverables, Milestones, amounts, Delivery Deadlines, Acceptance Criteria, included Revisions, Founder Inputs, dependencies, security obligations, intellectual-property provisions, third-party costs and Handover requirements before accepting the Offer.
Where the Expert or Agency identifies a material error, ambiguity, inconsistency, unacceptable NDA provision or other matter requiring amendment, it shall request the necessary correction through the applicable workflow before acceptance. Submission of a revision request does not constitute Offer acceptance, NDA acceptance, Hire or Project activation.
Where the Founder issues a revised Offer or revised NDA, the earlier acceptance process shall not carry forward automatically. The Expert or Agency shall review the complete revised version and provide a fresh acceptance through the authorised workflow.
The Expert or Agency may decline the Offer through the displayed workflow. A decline shall include the required reason and any mandatory comment, which shall be truthful, relevant and professional. The Founder may be notified of the reason and comment, subject to lawful redaction or withholding for safety, privacy, confidentiality or security.
7.4 Expert or Agency Acceptance of the Final Offer
The Expert or Agency accepts the Offer only by completing the electronic acceptance action provided through the authorised Platform workflow. Where an Offer-stage NDA is required, acceptance shall be completed only after the Expert or Agency has signed the final governing NDA through the same workflow or through the connected signature process identified by the Platform.
The Platform shall record the Offer as accepted only after all mandatory acceptance conditions displayed for the Offer have been completed. Upon acceptance, the Founder may receive a notification confirming that the Expert or Agency has accepted the Offer, and the Expert or Agency may receive a corresponding confirmation that its acceptance has been recorded.
Offer acceptance creates a conditional commitment between the Founder and the Expert or Agency to proceed on the terms of the final accepted Offer, subject to timely Founder payment, Hire Confirmation and Activation Confirmation.
Offer acceptance does not constitute successful payment, funding, Hire, commencement, Activation Confirmation or an instruction to begin performance. Until the required payment is successfully captured and the applicable confirmations are issued, the Offer shall remain in an accepted and payment-pending state.
7.5 Offer Accepted and Payment-Pending Status
After Offer acceptance and before successful payment, the Platform shall record the relevant state as Offer accepted, payment pending or another substantially equivalent state that clearly communicates that the Offer has been accepted but the Hire has not occurred.
The Platform shall not display or communicate a Hire, hired, successfully hired, selected provider or equivalent status merely because the Project was published, the Founder sent an Invitation, the Expert or Agency submitted a Proposal, the Founder shortlisted the Expert or Agency, the Founder sent an Offer, an NDA was signed or the Expert or Agency accepted the Offer.
During the payment-pending state, the Founder has not yet hired the Expert or Agency; the Expert or Agency has not yet been hired; the Project or applicable Milestone is not funded or active for Platform purposes; the Expert or Agency is not required to begin material performance; no Delivery Deadline or performance period begins unless the accepted Offer expressly provides for a separately activated paid preliminary service; and no User shall represent that a Hire or active Project exists.
7.6 Founder Payment After Offer Acceptance
After the Offer has been accepted, the Founder shall complete the payment required for Hire and activation within the payment period displayed by the Platform.
For a fixed-price Project, the required payment is the complete Project amount identified by the Platform as payable before activation. For a Milestone Project, the required payment is the amount allocated to the applicable Milestone. Each Additional Milestone requires a separate payment before that Milestone activates.
Payment shall be made only through the enabled ScaleDux and Payment Provider workflow. Under the current Razorpay Route model, ScaleDux includes a Transfer instruction in the Payment Order and the Transfer is created when the payment is captured with a Settlement Hold enabled. Payment initiation, authentication, authorisation, bank debit, capture, Transfer creation, payout eligibility, Settlement Hold release, Transfer processing, settlement processing and bank credit are separate events.
The applicable payment is successful for Hire and activation only when ScaleDux verifies the Payment Provider signature and confirms that the correct Order, INR amount and payment have reached the captured state in accordance with the ScaleDux Payment and Payout Terms. A bank debit, pending authorisation, payment screenshot, external payment, personal UPI payment or verbal assurance does not satisfy that condition.
7.7 Successful Payment, Hire Confirmation and Activation Confirmation
After the required Project amount or applicable Milestone amount becomes a Captured Payment under the ScaleDux Payment and Payout Terms, ScaleDux shall issue the Hire Confirmation to:
(a) the Founder, confirming that the Founder has hired the identified Expert or Agency for the Project; and
(b) the Expert or Agency, confirming that it has been hired by the identified Founder for the Project.
ScaleDux shall also issue the Activation Confirmation stating that the Project or identified Milestone is active and may commence. The Hire Confirmation and Activation Confirmation may be issued through the same recorded Platform event or through immediately connected Platform events.
The active Project Contract arises only upon the Activation Confirmation. The Activation Confirmation shall identify the Activation Date, Day 0 and the Project or Milestone to which the activation applies. The Expert or Agency may commence performance after the Activation Confirmation, subject to the accepted Offer, required Founder Inputs and applicable Dependencies.
Creation of a Transfer subject to Settlement Hold at payment capture is a Payment Provider processing step. It does not mean that the Deliverables have been accepted, that the Expert or Agency is payout eligible, that the Settlement Hold has been released or that settlement has occurred.
7.8 Failed, Pending, Reversed or Uncertain Payment
A failed, pending, incomplete, reversed, disputed, unauthorised or otherwise uncertain payment does not result in Hire Confirmation or Activation Confirmation and does not activate the Project or applicable Milestone.
The Founder and Expert or Agency shall follow the Platform status and any support instructions issued by ScaleDux. They shall not treat a bank debit, pending authorisation, screenshot, receipt generated outside the Platform, verbal assurance, direct transfer, personal UPI payment, QR-code payment or other external evidence as Hire Confirmation or Activation Confirmation.
Where the payment or capture result is uncertain, the Offer shall remain in the accepted and payment-pending state until ScaleDux verifies the provider state, completes reasonable administrative reconciliation, the payment period expires or the Offer is otherwise closed. ScaleDux may delay Hire or activation where the associated Transfer, Linked Account or Settlement Hold state requires review.
Where a payment previously recorded as successful is reversed, invalidated or disputed before activation, ScaleDux may withhold or withdraw the Hire Confirmation or Activation Confirmation and may return the Offer to an appropriate payment-pending, failed or closed state. The ScaleDux Payment and Payout Terms govern the financial consequences.
7.9 No Work Requirement Before Hire and Activation
An Expert or Agency shall not be required to commence or perform material Project work before ScaleDux issues the Hire Confirmation and Activation Confirmation.
The Founder shall not require performance merely because the Offer has been sent, the NDA has been signed, the Offer has been accepted, the Founder has initiated payment or the Founder believes that payment will shortly succeed.
A User who voluntarily performs, requests, supplies, accepts or relies upon material work before Activation Confirmation assumes the risk that such work falls outside the activated Project and its payment, review, Refund, Handover and dispute protections, except where ScaleDux expressly records and activates a separate paid preliminary service.
Pre-activation clarification, reasonable planning, access preparation and administrative communication do not constitute material Project performance unless the substance of the activity amounts to performance of a Deliverable or other paid scope.
7.10 Offer Withdrawal, Revision, Payment Expiry and Closure
The Founder may withdraw an Offer before the Expert or Agency accepts it, subject to the displayed workflow. The withdrawal shall include the required reason and any mandatory comment. An Offer may also expire automatically at the validity time displayed by the Platform.
Where the Expert or Agency requests a material Offer or NDA revision, the pending Offer may be returned to the Founder, replaced or closed in accordance with the workflow. A revised Offer must be re-sent and freshly accepted.
After Offer acceptance and before successful payment, the Offer remains accepted and payment pending. Where the Founder does not complete the required payment within the period displayed by the Platform, the Offer shall lapse or automatically close and shall no longer be available for acceptance, payment or activation.
An expired or closed Offer cannot be revived. If the parties wish to proceed, they must recommence through a new Offer workflow, complete any required NDA action, provide a fresh acceptance and satisfy the applicable payment and activation conditions. ScaleDux may retain the expired Offer, reasons, notices and timestamps in the audit history.
No Hire or active Project exists where the accepted Offer expires or is closed before successful payment and Activation Confirmation. Expiry, withdrawal or closure of the Offer does not automatically cancel, revoke or invalidate an NDA that has already become effective. The continuing effect, termination, replacement and survival of the NDA are governed by its terms and Applicable Law.
7.11 Conditional Offer Acceptance and Active Project Contract
Offer acceptance creates a binding conditional commitment to proceed through the authorised payment and activation workflow, subject to the accepted Offer, these Project Transaction Terms and the incorporated documents. It does not by itself create an active Project Contract or require material performance.
Upon Activation Confirmation, the active Project Contract consists of the Terms of Service, these Project Transaction Terms, the ScaleDux Payment and Payout Terms, the Project Cancellation and Refund Policy, the Project Dispute Resolution Policy, the applicable Fees and Commission Schedule, the final accepted Offer, each accepted Change Order, the applicable governing NDA and the other records properly incorporated into the Project.
8. Common Project Administration
8.1 Good Faith and Cooperation
Each party shall act honestly, reasonably and in good faith; communicate material risks; provide required information; avoid obstruction; and take reasonable steps to mitigate delay, loss and security risk. Good faith does not require a party to accept new scope, waive a right or disclose information prohibited by law.
8.2 Professional Communication
Project communication shall remain relevant, clear and professional. A User shall not use threats, harassment, review leverage, payment control, access control, confidential information or false urgency to obtain an unfair concession, suppress a report, force acceptance or discourage the other User from using the dispute process.
8.3 Manage Project Workspace
After Activation Confirmation, the Founder and the Expert or Agency shall use the Manage Project Workspace as the common Project administration area. The workspace may display substantially the same Project state and core records to both parties while presenting role-specific actions according to the User’s authority.
Deliverables, files, comments, Submissions, Revisions, decisions, Invoices, Milestones, Change Orders, extension requests, additional Milestone requests, completion actions, termination notices and dispute records shall be created or recorded through the applicable workspace function where the Platform provides one.
8.4 Notifications, Decisions and Required Reasons
ScaleDux may issue Platform, dashboard, email or other recorded notifications concerning a material Project event, including an Invitation, Proposal, change request, decline, withdrawal, shortlist, Offer, NDA action, payment state, Hire, activation, Submission, Revision, acceptance, Invoice, Milestone closure, extension, additional Milestone, termination, cure, restoration, dispute, completion or review.
A User is responsible for monitoring Project notices and keeping its registered contact details current. Failure to read a properly delivered notice does not by itself invalidate the underlying Platform event, subject to correction of a demonstrated delivery or system error.
Where the Platform requires a reason, category, comment or statement for a decline, withdrawal, rejection, termination, dispute response or other decision, the User shall select the most accurate option and provide a genuine, relevant, professional and sufficiently detailed explanation. A User shall not use a false, abusive, retaliatory, evasive or misleading reason.
The reason or comment may be made visible to the affected User unless ScaleDux reasonably limits disclosure for safety, privacy, confidentiality, legal privilege, security, fraud prevention or another lawful purpose.
8.5 Platform Records and Activity History
Material Project decisions shall be recorded through the Platform. ScaleDux may preserve timestamped event history, prior versions, reasons, notices, files, comments and status changes for Project administration, payment, evidence, dispute, security, audit and legal purposes.
Users shall not delete, alter, fabricate or conceal Platform or external records for the purpose of misleading the other party, ScaleDux, a Payment Provider or an authority.
8.6 Permitted External Collaboration
The parties may use authorised External Channels for calls, meetings, repositories, design tools and delivery support. ScaleDux does not presently provide its own audio or video calling service and the parties may use suitable third-party meeting tools in accordance with the Community Guidelines.
The Project Contract, required payment, material changes, Deliverable Submissions, Revision requests, acceptance actions, Invoices, Milestone closure, termination and dispute states remain governed by the Platform workflow. A Material Decision reached externally shall be summarised in Platform messaging and, where it changes the Project Contract, formalised through the applicable Platform process.
8.7 Formal Changes Only
A change to scope, price, Milestones, Delivery Deadline, Acceptance Criteria, Founder Inputs, dependencies, Handover or another material term is effective for Platform administration only through an accepted Change Order or other formal process expressly provided by ScaleDux. A chat statement, call, meeting note or informal approval does not by itself amend the Project Contract.
8.8 Legal and Regulatory Compliance
Each User shall comply with Applicable Law, professional duties, licences, permits, sanctions, export controls, employment requirements, data-protection obligations and third-party rights relevant to that User and the Project. ScaleDux does not assume the User’s regulatory or professional responsibility.
8.9 No ScaleDux Supervision
ScaleDux may provide workflow, notices, records, support, moderation, mediation and administrative decisions under the applicable documents. ScaleDux does not supervise day-to-day performance, direct the manner of work, certify technical quality, become the employer or agent of either User, or guarantee that the parties will reach agreement.
9. Related Financial and Dispute Documents
9.1 ScaleDux Payment and Payout Terms
The ScaleDux Payment and Payout Terms govern Payment Order creation, payment verification and capture, Razorpay Route Transfer creation, Settlement Holds, payout eligibility, Release Instructions, Transfer and settlement status, failed Transfers, manual retry, Refund execution, reversals, Chargebacks, recovery, tax information, payment evidence and reconciliation.
For the current Project model, payment capture creates the associated Transfer subject to Settlement Hold. Project performance and Invoice acceptance determine the Project Payout Eligibility Event. The ScaleDux Payment and Payout Terms govern the later Release Instruction and provider processing. These Project Transaction Terms do not promise immediate payout or bank credit.
9.2 Project Cancellation and Refund Policy
The Project Cancellation and Refund Policy governs pre-activation cancellation, post-activation cancellation, mutual termination, positive partial completion, completed and unstarted Milestones, Refund eligibility, partial Refund calculations and related financial treatment.
9.3 Project Dispute Resolution Policy
The Project Dispute Resolution Policy governs dispute eligibility, initiation by the standing support email or the Dispute Module when available, response, evidence, notifications, interim controls, facilitation, administrative decisions, internal review and closure. These Project Transaction Terms establish the lifecycle and substantive obligations but do not independently award a Refund or payout.
9.4 Fees and Commission Schedule
The Fees and Commission Schedule and the fee displayed before the relevant action state the applicable ScaleDux Charges. A Project change shall not alter a fee already accepted for an active Project unless the applicable fee rule expressly permits the change.
9.5 No Escrow
ScaleDux does not operate a regulated escrow service, trust account, User deposit, stored-value wallet or lending arrangement. A Razorpay Route Transfer subject to Settlement Hold is a Payment Provider-supported processing control and shall not be described as escrow, trust custody or money held by ScaleDux for a User.
9.6 No Automatic Financial Outcome
Acceptance, rejection, Revision, Project completion, Positive Partial Project Completion, cancellation, termination, Account restriction, Community Guidelines enforcement or a conduct finding does not independently determine Refund, payout, forfeiture, set-off or damages. The applicable financial document, Transaction Record and supported dispute outcome govern the result, subject to Applicable Law.
Part B – Founder Project Hiring Terms
10. Founder Authority and Project Responsibility
10.1 Authority
The Founder represents that the Founder has authority to create the Project, disclose the Project Materials, enter the Project Contract, make payment and grant the access and rights promised in the Offer. A Founder acting for an entity shall ensure that the Account and Authorised Representative information remain accurate.
10.2 Accuracy and Genuine Intent
The Founder shall describe the requirement, startup or business context, budget position, timeline, decision authority and intended use truthfully and shall create the Project with genuine intent to evaluate and, where appropriate, hire a suitable Expert or Agency.
10.3 Responsibility for Founder Team Members
The Founder is responsible for Founder team members and Authorised Representatives who use the Project workspace, provide instructions, approve work, access Deliverables or communicate on behalf of the Founder. The Founder shall grant least-necessary permissions and remove access when authority ends.
11. Project Requirements and Documentation
11.1 Sufficient Project Brief
The Founder shall provide enough information for a reasonably qualified Expert or Agency to assess the objective, expected outcome, material Deliverables, constraints, dependencies, intended users, relevant technology or context, indicative timeline and budget position.
11.2 BRD, PRD and Supporting Material
For a complex Project, the Founder should provide a business requirements document, product requirements document, statement of requirements, process map, acceptance matrix, reference material or equivalent structured brief proportionate to the work. A simple Project does not require unnecessary documentation, but complexity shall not be used to withhold a material requirement until after activation.
11.3 Acceptance Criteria and Constraints
The Founder shall identify material functional, technical, format, quality, compatibility, security, regulatory, accessibility and delivery constraints that the Deliverable must satisfy. Subjective preference shall not replace missing Acceptance Criteria after the Project is activated.
11.4 Confidentiality Classification
The Founder shall determine which information may appear in the Public Project Posting, which may be shared during logged-in clarification and which requires an effective NDA or restricted access. An image or attachment placed in a public Project field is public and must not contain Confidential Information, credentials, raw customer data, sensitive personal data or material that the Founder is not authorised to publish.
The Founder shall avoid unnecessary personal data and shall use the restricted transaction workflow for information requiring confidentiality. Selecting NDA Required for a later stage does not make a public posting or public attachment confidential.
11.5 No Hidden Material Requirement
The Founder shall not intentionally omit a material requirement, integration, dependency, licence, environment, data condition, approval or delivery format and later treat the omitted matter as included without an accepted Change Order.
12. Budget, Schedule and Project Structure
12.1 Budget Position
The Founder shall state or select a budget position honestly and shall not use a knowingly unrealistic budget to collect unpaid strategy, manipulate Proposals or pressure a provider after selection. The final amount is the amount recorded in the accepted Offer.
12.2 Delivery Schedule
The Founder shall disclose genuine deadlines, internal approval windows, launch dependencies and dates outside the Founder’s control. A deadline shall not be represented as mandatory where it is only preferred.
12.3 Fixed-Price or Milestone Structure
The Founder may consider the structure proposed by the Expert or Agency, but the final fixed-price or Milestone structure must be recorded in the Offer. A fixed-price Project is one funded financial unit. A Milestone Project is ordinarily funded one Milestone at a time, and each Additional Milestone requires separate acceptance, payment capture and activation.
A complex or long Project should use Milestones where staged delivery, review and payment reduce ambiguity and risk. The Users shall not divide or label work in a manner intended to avoid ScaleDux Charges, payment controls, review rules or Circumvention obligations.
12.4 Dependencies and Third-Party Costs
The Founder shall disclose known dependencies and shall identify third-party licences, subscriptions, infrastructure, travel, data, hardware or other costs expected to be borne by either party. An undisclosed third-party cost is not automatically payable by the other party.
13. Invitations, Evaluation and Selection
13.1 Relevant Expert Suggestions and Individual Invitations
The Founder may review Experts or Agencies suggested by the Platform based on recorded skills or other matching information and may send individual Project Invitations to one or more relevant recipients. The Founder shall review available information and shall not treat matching or visibility as certification by ScaleDux.
Each Invitation should contain a genuine Project-specific message and shall not disclose another invited User’s identity, response, Proposal or confidential information.
13.2 Proposal Review
The Founder shall review each Proposal on its stated scope, Project structure, Deliverables, price, schedule, assumptions, dependencies, delivery team, security position and other relevant terms. The Founder shall not reject or shortlist a Proposal on an unlawful or discriminatory ground.
13.3 Proposal Change Requests and Clarification
The Founder may issue a Proposal Change Request where a Proposal requires clarification, correction or revision. The request shall identify the matter to be changed and shall not be used to obtain disproportionate unpaid work or new scope without fair commercial consideration.
The Founder may discuss the request through Platform messaging and a permitted External Channel, but shall rely on the revised Proposal submitted through the authorised workflow.
13.4 Decline and Shortlist Decisions
The Founder may decline one, several or all Proposals or shortlist one or more Proposals. A required decline or removal reason and comment shall be accurate, relevant, professional and sufficiently clear. A shortlist is not a promise of selection or payment.
13.5 Timely and Genuine Action
The Founder should review Invitation responses, Proposals, Proposal Change Requests, revised Proposals, Offers, Invoices, additional Milestone requests, termination notices and dispute communications within the applicable displayed period. The Founder shall not deliberately leave a pending action unresolved to pressure another User or avoid a required reason.
13.6 No False Competition
The Founder shall not fabricate competing Proposals, misstate the number or quality of other bidders, falsely claim that another User accepted a lower price, or use false competition to pressure an Expert or Agency.
14. Founder Offer and Commitments
14.1 Complete Offer
The Founder shall send a complete Offer containing the material terms required by clause 7.2 and shall cross-check the scope, Deliverables, Milestones, price, schedule, Acceptance Criteria, Founder Inputs, dependencies, Handover, NDA and intellectual-property position before transmission.
14.2 Scope and Commercial Accuracy
The Founder shall not knowingly understate scope, omit a material Dependency, misdescribe the expected output, reserve undisclosed work for later or present a price as final while expecting unpaid additions.
14.3 Acceptance Criteria
The Founder shall state reasonably objective and usable Acceptance Criteria. Acceptance Criteria shall not be drafted so broadly or subjectively that the Founder can refuse conforming work without a fair contractual basis.
14.4 NDA and IP Position
Where an NDA is required, the Founder shall attach or reference the governing document and complete the version-control workflow in clause 6. The Founder shall state the intended Work Product ownership, Background IP and third-party rights position with sufficient clarity for the Expert or Agency to evaluate the Offer.
14.5 Offer Validity, Withdrawal and Revision
The Founder shall set or accept the Offer validity period displayed by the Platform. Before acceptance, the Founder may withdraw or revise the Offer through the authorised workflow and shall provide the required reason and comment. A material revision requires re-transmission and fresh acceptance.
After acceptance, the Founder shall pay within the displayed payment period. An accepted but unpaid Offer lapses or closes under clause 7.10 and cannot be revived.
14.6 Genuine Intention to Proceed
The Founder shall not send an Offer merely to reserve an Expert or Agency, obtain a signed NDA, block availability, create false marketplace activity or gain negotiating leverage. Where the Platform permits more than one outstanding Offer, each Offer shall be genuine and the Founder shall not misrepresent its status or likelihood of payment.
15. Founder Inputs and Dependencies
15.1 Timely Inputs
The Founder shall provide agreed Founder Inputs in a complete, accurate and usable form by the date or event recorded in the Offer. The Founder shall identify the person authorised to provide binding instructions or approvals.
15.2 Input Request and Delay Record
Where an expected Founder Input is missing, the Expert or Agency should raise an input request through the Platform, identify the affected task and explain the likely impact. The Founder shall respond within the stated or reasonable period.
15.3 Consequences of Missing Inputs
A delay caused by missing, inaccurate, conflicting or late Founder Inputs may support an extension, Change Order, pause, cancellation or dispute outcome under the applicable policy. The Expert or Agency remains responsible for mitigating avoidable delay and shall not claim an impact unrelated to the missing input.
15.4 Founder Decisions and Approvals
The Founder shall provide decisions and approvals within the Review Period or other recorded deadline and shall not issue materially conflicting instructions through different team members without promptly resolving the conflict.
16. Founder Access, Systems and Data Responsibilities
16.1 Minimum Necessary Access
The Founder shall provide only the systems, environments, repositories, files and permissions reasonably necessary for the agreed work and shall consider a test or staging environment before production access.
16.2 Secure Credential Provision
The Founder shall use a secure method to provide credentials, shall avoid sending unnecessary passwords in ordinary messages and shall use role-based accounts, temporary access, multi-factor authentication and revocable tokens where reasonably available.
16.3 Personal and Customer Data
The Founder shall not provide personal, customer, employee or sensitive data unless the disclosure is lawful, necessary and authorised. Where realistic testing can be completed with masked, synthetic or minimised data, the Founder should use the lower-risk alternative.
16.4 Access Changes and Revocation
The Founder shall update permissions when scope or personnel changes and shall revoke or rotate access promptly after Handover, cancellation, termination or a security concern. The Founder remains responsible for its own systems and for independently verifying that access has been removed.
17. Founder Review, Acceptance and Revision Duties
17.1 Good-Faith Review
The Founder shall review each Submission honestly and against the recorded scope, Acceptance Criteria and accepted Change Orders. The Founder shall not reject conforming work because of an undisclosed preference, changed business objective, personal disagreement or desire to obtain new work without payment.
17.2 Manage Project Review and Timely Action
The Founder shall use the Manage Project Workspace to review the identified Deliverable, access the submitted files, read the Expert or Agency comments and take the applicable action within the Review Period.
The Founder may request reasonable clarification through Platform messaging or a permitted external call. A call, chat, ordinary clarification request or private agreement does not pause or extend the Review Period unless the Platform records the applicable pause or extension.
17.3 Deliverable-Level Acceptance
The Founder shall act separately on each Deliverable where the Platform provides Deliverable-level review. The current Project workflow does not support partial acceptance or partial financial release for a Deliverable. The Founder shall either accept the Deliverable, request a permitted Revision, reject where the workflow permits, raise a supported dispute or take another action expressly provided by the Platform.
Where only part of a Deliverable conforms, the Founder shall identify the non-conforming portion through the Revision or dispute workflow. New or changed scope requires a Change Order. A Milestone remains active until every required Deliverable has been accepted, automatically accepted, validly removed through an accepted Change Order or otherwise closed under an applicable decision.
17.4 Revision Request
A Revision request shall identify the affected Deliverable, the recorded Acceptance Criterion or scope requirement not met, the required correction and any supporting comment or evidence reasonably necessary to understand the request.
The Founder shall not use a Revision request for new scope, a new feature, a material redesign, a different business direction or work beyond the included Revision count.
17.5 Rejection and Required Reason
Where the workflow permits rejection, the Founder shall select the most accurate reason and provide a genuine and sufficiently detailed comment. The Founder shall not submit a false, abusive, retaliatory or evasive reason and shall not reject merely to delay an Invoice, Milestone closure or payout.
17.6 Automatic Acceptance
If the Founder does not take a valid review action within the Review Period and no recorded pause or extension applies, the Platform may record the Deliverable as automatically accepted in accordance with clause 33. The Founder is responsible for monitoring the Review Period and Project notices.
A supported dispute or material issue affects the Review Period only when submitted through the supported route in time and recorded by the Platform as a hold, pause or other applicable state. ScaleDux may use available administrative or Payment Provider controls where automated pausing is unavailable, subject to the ScaleDux Payment and Payout Terms.
17.7 Invoice and Milestone Closure Action
After every Deliverable required for a Milestone has been accepted or otherwise closed, the Expert or Agency may cause the Supplier Invoice to be generated or submitted through the authorised Project workflow. The Founder may also use the supported action to request the Invoice.
The Founder shall review the Invoice within the Invoice Review Period, which is currently forty-eight continuous hours unless ScaleDux displays a longer Platform-set period. The Founder shall accept the Invoice or raise a supported Invoice-specific issue. If the Founder takes no valid action and no recorded hold applies, the Platform may automatically accept the Invoice.
Invoice acceptance or automatic acceptance may create the Project Payout Eligibility Event and authorise ScaleDux to submit a Release Instruction for the existing Transfer subject to Settlement Hold. It does not create a new Transfer and does not guarantee immediate settlement or bank credit.
17.8 No Review or Payment Leverage
The Founder shall not use review delay, repeated unsupported Revision requests, Invoice delay, a threatened negative review, termination or dispute as leverage to obtain unpaid work, a discount, an off-Platform arrangement or another unfair concession.
18. Founder Payment, Cooperation and Handover
18.1 Payment and Invoice Cooperation
The Founder shall provide accurate billing, tax and payment information, complete required authentication, review and act upon Invoices within the Invoice Review Period, cooperate with legitimate payment, tax, Chargeback and reconciliation inquiries, and avoid duplicate recovery. Payment capture, Transfer creation, Settlement Hold, Release Instruction, Refund, reversal, settlement and payout outcomes are governed by the ScaleDux Payment and Payout Terms.
18.2 No Off-Platform Payment
The Founder shall not request or make direct payment, split payment, personal UPI payment, external bank payment, hidden reimbursement or another off-Platform amount for Covered Services in breach of clause 8 of the Terms of Service and clause 45 of these Project Transaction Terms.
18.3 Handover Cooperation
The Founder shall identify the authorised recipient for Handover, provide a secure destination, test access reasonably and acknowledge material Handover items or identify a specific deficiency within the applicable review or Handover period.
18.4 Credential Rotation
After Handover, the Founder shall rotate shared secrets, transfer ownership of relevant accounts and remove obsolete access. The Expert or Agency shall not remain responsible for the Founder’s failure to secure its systems after a complete Handover, except to the extent the Expert or Agency retained unauthorised access or caused a security defect.
19. Prohibited Founder Conduct
The Founder shall not create a fake Project; misrepresent authority, budget, funding or intent; obtain substantial unpaid work; conceal material requirements; request illegal or prohibited services; provide information without authority; demand direct payment arrangements; misuse an Expert’s Proposal, samples or Confidential Information; require undisclosed subcontracting restrictions after activation; manipulate reviews or evidence; delay decisions to avoid automatic obligations; withhold payment leverage for unrelated concessions; or use cancellation, dispute or termination processes in bad faith.
Part C – Expert and Agency Project Service Terms
20. Eligibility, Capacity and Authority
20.1 Capability and Availability
The Expert or Agency shall accept only a Project that it can reasonably perform with the required skill, capacity, personnel, tools, licences and time. It shall disclose a material limitation or dependency before the Founder reasonably relies on a contrary impression.
20.2 Professional Authority
Where the Project involves regulated or licensed activity, the Expert or Agency shall hold and maintain the authority required by Applicable Law and shall accurately describe whether the service is regulated professional advice or general business support.
20.3 Agency Authority
An Agency represents that it is duly authorised to offer the services, assign Agency Personnel, enter the Project Contract, receive payment and grant the rights promised in the Offer.
20.4 Conflicts and Restrictions
The Expert or Agency shall disclose a material conflict, exclusivity restriction, client obligation, employer restriction, sanctions issue or other condition that could affect independence, confidentiality or lawful performance. Where the conflict cannot be managed fairly, the User shall decline or withdraw before activation.
21. Proposal and Pre-Contract Representations
21.1 Project-Specific Proposal
The Expert or Agency shall submit a Project-specific Proposal that accurately addresses the available Project Brief and identifies the proposed approach, scope, Deliverables, Project structure, delivery team, assumptions, exclusions, dependencies, price, schedule, Revisions, security position and material limitations.
21.2 Fixed-Price or Milestone Position
The Proposal shall identify whether the Expert or Agency recommends a fixed-price Project or Milestone Project and shall provide sufficient detail for the Founder to understand the proposed Deliverables, amounts, Delivery Deadlines and dependencies.
21.3 Working Method and Assumptions
The Expert or Agency shall disclose material assumptions, Founder Inputs, third-party services, licences, tools, access requirements and other conditions on which the Proposal depends. It shall not hide a material Dependency for later use as a price or delay lever.
21.4 Pricing and Timeline
The proposed price and timeline shall be genuine and reasonably supportable based on the information available. An estimate shall be identified as an estimate. The Expert or Agency shall not knowingly quote an impossible timeline or artificial price solely to obtain a shortlist or Offer.
21.5 Response to a Proposal Change Request
After receiving a Proposal Change Request, the Expert or Agency shall review the requested change and may revise and re-submit the Proposal, decline the requested change with a genuine explanation, or withdraw the Proposal through the authorised workflow.
A revised Proposal shall clearly state the updated scope, Deliverables, Project structure, price, schedule, assumptions, dependencies, exclusions and other changed terms. The Expert or Agency shall not represent that an informal chat or call modified the Proposal unless the revised terms are submitted through the Platform.
21.6 Proposal Withdrawal
The Expert or Agency may withdraw an unaccepted Proposal and shall provide the required reason and comment. Withdrawal shall not be used to move the Project outside ScaleDux, conceal a misrepresentation, avoid an NDA or delete evidence of the proposal process.
21.7 Portfolio and Credentials
Portfolio items, qualifications, references, ratings, team information and prior experience shall be accurate and lawfully disclosed. The Expert or Agency shall not present another person’s work, credentials or capacity as its own.
21.8 No Deceptive Underquoting
The Expert or Agency shall not deliberately omit necessary work or costs from a Proposal in order to obtain selection and later demand an avoidable price increase. A genuine newly discovered condition may be addressed through clarification or a Change Order.
22. Team Members, Personnel and Subcontracting
22.1 Disclosed Delivery Team
Where personnel identity, capability, location, access or role is material to the Founder’s decision, the Agency shall disclose the principal delivery team before Offer acceptance or as soon as reasonably known.
22.2 Substitution
An Agency shall not replace a material team member with a materially less qualified or unauthorised person without disclosure and, where the Offer makes the person material, Founder approval through the Platform.
22.3 Subcontracting
Subcontracting is permitted only where consistent with the Offer, confidentiality, security, data-protection and professional obligations. A subcontractor shall receive only the access and information reasonably necessary for the authorised task.
22.4 Continuing Responsibility
The Agency remains responsible for the acts, omissions, quality, confidentiality, security, intellectual-property chain of title and Handover obligations of Agency Personnel and subcontractors used for the Project.
23. Performance, Progress and Delay Management
23.1 Standard of Performance
The Expert or Agency shall perform with reasonable care, skill, diligence and professional judgment consistent with the Offer, claimed capability and Applicable Law.
23.2 Capacity and Continuity
The Expert or Agency shall maintain sufficient capacity and continuity for the agreed Project and shall not knowingly accept conflicting commitments that make timely performance materially unlikely.
23.3 Progress Information
The Expert or Agency shall provide truthful progress information through the Manage Project Workspace or other authorised status function and shall not represent planned, placeholder, incomplete or untested work as complete. Material status information should identify completed work, pending work, blockers, Dependencies and any action required from the Founder.
23.4 Delay Notice
The Expert or Agency shall notify the Founder promptly through the Platform after becoming aware of a material delay, blocked Dependency, personnel issue, security concern or inability to meet a Delivery Deadline and shall identify the cause, impact, mitigation, requested action and any extension required. A delay notice does not automatically extend a deadline.
23.5 No Dummy Submission
The Expert or Agency shall not upload a dummy file, irrelevant file, inaccessible link, knowingly incomplete Deliverable or false evidence merely to stop a deadline, trigger a Review Period or create an appearance of delivery.
24. Deliverables and Quality Obligations
24.1 Conformity With Scope
Each Deliverable shall materially conform to the recorded scope and Acceptance Criteria. The Expert or Agency shall not substitute a materially different output without an accepted Change Order.
24.2 Completeness and Usability
A Deliverable shall be reasonably complete, accessible, non-malicious and usable for the agreed purpose when used in the stated environment and subject to the recorded assumptions and dependencies.
24.3 Documentation and Source Materials
Where the Offer requires source files, code, editable files, specifications, documentation, credentials, deployment instructions, test results or other supporting materials, the Expert or Agency shall include them in the Submission or Handover as stated.
24.4 Defects and Remediation
The Expert or Agency shall correct a material defect within scope through the Revision process. A defect caused by a Founder change, unsupported environment, undisclosed dependency or third-party failure is not automatically the Expert or Agency’s responsibility, but the parties shall cooperate to identify the cause.
25. AI-Assisted Work, Third-Party Materials and Open Source
25.1 Responsible AI-Assisted Work
The Expert or Agency may use an AI-assisted or automated tool only in a manner consistent with the Offer, Community Guidelines, confidentiality, security, intellectual-property and professional obligations. The Expert or Agency remains fully responsible for the resulting work.
25.2 Material AI Use Disclosure
Material AI use shall be disclosed where the Offer, Platform field, professional standard or reasonable expectation of the Founder requires disclosure. The Expert or Agency shall conduct meaningful human review and independently verify material factual, legal, financial, regulatory, technical and attribution claims.
25.3 Third-Party Materials
The Expert or Agency shall not include third-party material unless it has authority to do so and shall disclose material licence terms, fees, attribution, usage limits, transfer restrictions and dependencies before the Founder becomes committed to them.
25.4 Open-Source Components
The Expert or Agency shall identify material open-source components and comply with their licences. It shall not include a component that requires disclosure, licensing or distribution of proprietary Founder code or Work Product on terms inconsistent with the Offer without the Founder’s informed written approval.
25.5 Licence and Attribution Records
The Expert or Agency shall maintain and deliver the third-party and open-source inventory, notices, attribution and licence information required by the Offer, Applicable Law or the relevant licences.
26. Expert and Agency Security and Confidentiality
26.1 Purpose-Limited Access
The Expert, Agency and Agency Personnel shall use Project Materials, systems, credentials and personal data only for the agreed Project purpose and shall not inspect unrelated information or use access for personal, competitive or external commercial benefit.
26.2 Secure Devices and Tools
A User performing the Project shall use reasonably secure devices, current software, access controls, malware protection, secure networks and authorised tools appropriate to the Project risk. A personally owned device does not reduce the security obligation.
26.3 No Credential Sharing
Credentials, session tokens, secrets, API keys and administrator access shall not be shared with an unauthorised person. Agency Personnel should use individual accounts where the relevant system permits them.
26.4 Security Incident Notice
The Expert or Agency shall notify the Founder and ScaleDux promptly after discovering or reasonably suspecting unauthorised access, credential compromise, malware, data loss, source-code exposure, personal-data incident or another material security event connected to the Project and shall cooperate with reasonable containment and evidence-preservation measures.
26.5 Return and Deletion
When the authorised purpose ends, the Expert or Agency shall return, delete, restrict or retain Project Materials according to the Offer, NDA, Privacy Policy, Applicable Law and Handover requirements and shall not keep a copy merely because it was downloaded or technically accessible.
27. Submission, Revision and Handover Duties
27.1 Submission Through the Manage Project Workspace
The Expert or Agency shall submit each Deliverable through the Manage Project Workspace and shall identify the applicable Milestone and Deliverable. The Submission may include files, links, source materials and a clear comment describing what has been delivered, any installation or review steps and any known limitation.
27.2 Valid Submission
A Submission is valid only where the required Deliverable is materially available for review, the submitted files or links are accessible, the comment is not misleading and the Submission is not a placeholder, dummy file or attempt to start the Review Period without delivery.
27.3 Replacement Submission
Where a submitted Deliverable is corrected, updated or re-delivered, the Expert or Agency shall use the Replacement Submission workflow and shall identify the version being replaced. A valid Replacement Submission may restart the Review Period for that Deliverable under clause 33.
27.4 Revisions Within Scope
The Expert or Agency shall review a valid Revision request, perform the included within-scope correction and re-submit the Deliverable within the applicable time. Where the request is new scope, exceeds the included Revision count or is inconsistent with the Project Contract, the Expert or Agency shall explain the issue and may request a Change Order or use the dispute process.
27.5 Invoice Submission
After all Deliverables required for a Milestone have been accepted or otherwise closed, the Expert or Agency may cause the Supplier Invoice to be generated or submitted through the authorised workflow, whether or not the Founder first requested it. The Invoice shall correspond to the applicable Milestone, amount, tax position and accepted Project records and shall not include an external, hidden, duplicated or unrecorded amount.
ScaleDux may generate the Invoice on behalf of the Expert or Agency as a technology facility. The Expert or Agency remains the supplier of the Project service and shall maintain accurate legal name, entity, GST, address, service-description and other information required for the Invoice.
27.6 Handover Materials
The Expert or Agency shall provide the Handover Materials required by the Offer, accepted Change Orders and clause 41 and shall not withhold Founder-controlled credentials, source materials or accepted work as leverage for an external payment or unrelated concession.
27.7 Access Removal
At completion, termination or when access is no longer required, the Expert or Agency shall return or delete Project Materials as required, cease access and cooperate with credential rotation and confirmation of access removal.
28. Prohibited Expert and Agency Conduct
The Expert or Agency shall not submit copied or fabricated Proposals; misrepresent skills, portfolio, personnel, capacity or progress; use undisclosed personnel where material; demand off-Platform payment; submit dummy or malicious Deliverables; conceal third-party or open-source restrictions; retain credentials or source files as leverage; reuse Founder Confidential Information; falsify time, delivery or acceptance evidence; manipulate reviews; threaten non-performance for unrelated concessions; or abandon an activated Project without using the applicable cancellation, termination or dispute process.
29. Agency Responsibility and Independent Status
29.1 Agency Responsibility
The Agency is the contracting service provider identified in the Offer and remains responsible for Project performance, Agency Personnel, payment entitlement, intellectual-property rights, security, confidentiality, Handover and compliance, even where a particular individual communicates with the Founder.
29.2 Personnel Compliance
The Agency shall ensure that Agency Personnel receive and comply with obligations at least as protective as the applicable Project Contract, including confidentiality, intellectual-property, security, personal-data and access restrictions.
29.3 Independent Business Status
The Expert or Agency determines its internal method, workplace, equipment and personnel, subject to the agreed outcomes, schedule, communication, security and legal requirements. Nothing in the Platform relationship creates employment by the Founder or ScaleDux.
29.4 Taxes and Statutory Duties
The Expert or Agency is responsible for its own registrations, tax returns, invoices, labour obligations, insurance and other statutory duties, subject to withholding, reporting or documentation required by Applicable Law or the Payment Provider. The separate Payment and Payout Terms govern the Platform administration of such matters.
Join ScaleDux Community
Select Your Role and Get Tailored updates, opportunities, insights, and ecosystem news