1. Provider identity and legal information
These Terms are intended for use by:
Brand / trading name: MT Digital Studio
Provider / legal operator: [FULL LEGAL NAME REQUIRED]
Legal form: [LEGAL FORM]
Business address: [FULL ADDRESS]
Email: contact@mihai-teleuca.com
Telephone: not published
VAT identification / tax details, if legally required: [DETAILS / NOT APPLICABLE]
A commercial website in Germany may require additional provider information to remain easily recognisable, directly accessible and permanently available. These Terms do not replace a separate legally required provider notice / Impressum where one is required.
2. Scope and acceptance of these Terms
These Terms govern use of the public website and may govern project services where they are expressly incorporated into a proposal, order confirmation, statement of work, service agreement or other binding agreement between the Provider and the client.
Merely visiting the public website does not create an obligation to purchase services. Where a separate signed or otherwise accepted project agreement conflicts with these Terms, the specifically negotiated project agreement should generally take priority for the conflicting subject matter, subject to mandatory law.
Different rules may apply depending on whether the client acts as a consumer or in the course of a trade, business or profession. Mandatory consumer rights cannot be excluded by these Terms.
3. Permitted use of the website
Visitors may use the website for ordinary informational purposes, to review services and portfolio information, and to initiate legitimate project communications. Visitors must not intentionally interfere with the website, attempt to compromise accounts, bypass access controls, introduce malware, scrape protected information at abusive scale, impersonate another person or use the service in a manner that violates applicable law or third-party rights.
The Provider may modify, suspend or discontinue non-contractual website features at any time, particularly for maintenance, security, redesign, legal compliance or technical reasons. This does not affect contractual rights already agreed in a separate binding project agreement.
4. Contact form and project inquiries do not automatically create a contract
Submitting the website contact form, requesting a quote, sending an email or discussing an idea does not by itself constitute acceptance of a project, a binding offer by the Provider or an obligation for either party to proceed.
The contact form is intended as an invitation to begin discussions. The Provider may decline an inquiry, request additional information, identify technical or legal concerns, revise a preliminary estimate or decide that a proposed project is outside the available scope.
Unless the parties clearly agree otherwise, prices, time estimates and technical suggestions given during early discussions are non-binding preliminary information.
5. Formation of a project contract
A project contract is formed only when the parties have reached agreement on the essential commercial terms and the relevant offer, proposal, statement of work or order confirmation is accepted in a legally effective manner.
A project agreement should normally identify, as applicable:
- the parties;
- the service or deliverables;
- the project scope and exclusions;
- the price or pricing method;
- payment schedule;
- expected milestones or delivery target;
- client dependencies and required materials;
- revision/change-request rules;
- hosting, deployment or third-party costs;
- intellectual-property terms;
- maintenance/support arrangements;
- consumer withdrawal information where required.
6. Types of services
Depending on the individual agreement, services may include web development, responsive interface development, Python programming, automation, desktop application concepts, dashboards, internal tools, UI/UX design, Discord/BDFD systems, technical consulting, programming support, maintenance or related project work.
Descriptions on the public Services page are illustrative categories rather than promises that every listed feature is available for every project. The binding scope is the scope accepted for the individual project.
7. Project scope, assumptions and exclusions
The Provider is responsible for delivering only the work included in the agreed scope. Features, integrations, content, migrations, languages, devices, browsers, accessibility targets, data imports, third-party APIs, hosting work or administrative tooling not expressly included should not be assumed to be included merely because they might be technically related to the project.
Where the client’s requirements are incomplete, the parties may use assumptions to define the initial scope. Material changes to those assumptions may affect the price, delivery schedule or technical architecture.
8. Client cooperation and responsibilities
Successful delivery may depend on timely cooperation by the client. The client may be responsible for:
- providing accurate requirements and timely decisions;
- supplying text, images, logos, credentials, data or technical information that the client has the right to provide;
- reviewing milestones and reporting material issues within agreed review periods;
- obtaining internal approvals;
- maintaining backups of client-controlled systems where appropriate;
- paying third-party fees not included in the Provider’s price;
- ensuring that the intended use of the project complies with applicable law and third-party terms;
- not supplying unlawful, infringing, malicious or deceptive material.
Delays caused by missing client materials, approvals, access or decisions may reasonably extend the project schedule.
9. Timelines, milestones and delivery dates
Unless expressly agreed as a binding fixed deadline, delivery dates and milestone dates should be treated as good-faith estimates based on the information available at the time. Timelines may change due to scope changes, delayed client feedback, third-party outages, API changes, technical discoveries, illness, force majeure or other dependencies outside reasonable control.
If a date is business-critical, that requirement must be communicated before contract formation so that the parties can expressly agree how it affects scope, price, priority and consequences of delay.
10. Fees, estimates, taxes and payment
Fees may be fixed-price, milestone-based, hourly, daily, subscription-based or otherwise agreed in writing. The individual proposal should state whether prices include or exclude VAT and other taxes, depending on the Provider’s actual tax status and applicable law.
The Provider’s tax/business position must be stated accurately and should not be inferred from this template: [INSERT REAL VAT / KLEINUNTERNEHMER / TAX WORDING AFTER REVIEW].
Payment schedule
The parties may agree a deposit, milestone payments or payment after delivery. Payment dates and consequences of late payment should be stated in the proposal or invoice. Statutory rules on default remain unaffected.
Third-party costs
Domain registrations, hosting, premium software, API usage, cloud infrastructure, paid fonts, stock media, licenses, external services, marketplace fees and similar costs are not included unless expressly stated.
11. Change requests and additional work
A change request is a request to modify the agreed scope, functionality, content, design direction, integration, platform or assumptions. Small clarifications may sometimes be handled within the existing scope, but material changes may require a revised estimate, additional fee or schedule adjustment.
The Provider should not be required to begin material additional work until the commercial impact has been clarified and, where appropriate, approved by the client.
12. Delivery, review and acceptance
Deliverables may be provided as files, repository access, hosted output, deployment, documentation, credentials or another agreed format. The client should review delivered work within the agreed review period and identify reproducible issues with reasonable detail.
Acceptance procedures should not remove mandatory statutory rights, particularly for consumers. For business clients, the parties may define a practical review and acceptance process in the project agreement.
13. Intellectual property and usage rights
Ownership and usage rights should be addressed expressly for each project. Unless otherwise agreed, pre-existing tools, reusable components, know-how, generic libraries, development methods and materials created independently of the specific client project may remain with their original owner.
Client-specific usage rights, source-code rights, exclusivity, transferability, sublicensing, territory and duration should be defined in the accepted proposal where relevant. If rights are intended to transfer only after full payment, that condition should be stated clearly in the binding agreement.
The client represents that materials supplied by the client may lawfully be used for the project and do not knowingly infringe copyright, trademark, privacy, publicity or other third-party rights.
14. Open-source software, APIs and third-party components
Projects may depend on open-source software, frameworks, APIs, operating systems, browsers, hosting services, app stores, platforms or other third-party technology. Such components may be subject to separate licenses and terms.
The Provider cannot guarantee that a third party will continue offering an API, feature, pricing model, compatibility level or service indefinitely. Where a third party changes or discontinues a dependency after delivery, additional work required to adapt the project is generally outside the original scope unless maintenance coverage expressly includes it.
15. Portfolio references, case studies and confidentiality
Whether the Provider may identify a completed client project publicly should be agreed with the client. A project containing confidential internal information, personal data, unreleased products or security-sensitive systems should not be published merely because the Provider worked on it.
Where the client grants permission, the Provider may display screenshots, a project description, technologies used and a link to the public result, subject to the agreed scope of that permission.
16. Website accounts and administrator access
If account functionality is activated, users must provide accurate information, protect their credentials and notify the Provider of suspected unauthorized access. Accounts may be restricted or suspended where reasonably necessary for security, abuse prevention or legal compliance.
Administrator functions are strictly reserved for accounts explicitly assigned an administrator role by the authorized system owner. Hiding an interface element in HTML or JavaScript is not sufficient security. Production create/update/delete operations must be authorised server-side on every request.
The current “Add project” interface is a front-end development feature and must not be treated as production-grade administrative security until the real authentication backend is implemented.
17. Security-related limitations
Development services may include reasonable security-conscious implementation, but no software can be guaranteed to be immune from every vulnerability, future exploit, misconfiguration, third-party compromise or malicious attack.
Security audits, penetration testing, regulated compliance certifications, continuous monitoring, incident response and high-availability architecture are separate specialist services unless expressly included.
18. Hosting, deployment, domains and infrastructure
Responsibility for hosting and deployment depends on the project agreement. If the client controls the hosting account, domain, DNS, cloud provider or server, the client remains responsible for fees, account ownership and provider-specific terms unless agreed otherwise.
Deployment may require credentials or temporary access. The client should use appropriate access controls and rotate credentials where reasonable after access is no longer required.
The Provider does not control uptime, outages, network incidents or policy decisions of independent hosting, DNS or cloud providers.
19. Maintenance, support and future modifications
Unless maintenance is included in the binding project scope, delivery does not create an indefinite obligation to provide free updates, compatibility changes, content changes, new features, server administration or third-party API migrations.
Maintenance may be offered under a separate retainer, subscription, support package or new project agreement.
20. Special provisions for consumers
A “consumer” generally means a natural person acting for purposes predominantly outside their trade, business or profession. If the client is a consumer, mandatory consumer-protection law applies and prevails over any contractual clause that would unlawfully reduce those rights.
The Provider must provide legally required pre-contractual information before a consumer becomes bound by a distance or off-premises contract, including information about the service, identity, total price or calculation method, contract duration where relevant, complaints handling and withdrawal rights where applicable.
21. Consumer right of withdrawal for distance contracts
Consumers may have a statutory 14-day right of withdrawal for qualifying distance service contracts. The exact start, procedure, consequences and exceptions depend on the type of contract and applicable law.
Services begun during the withdrawal period
If a consumer expressly requests that paid services begin before the withdrawal period expires, statutory rules may require the consumer to pay an appropriate amount for services actually provided before a valid withdrawal, provided the legal information and request requirements are satisfied.
Loss of the withdrawal right after full performance
For qualifying paid service contracts, the statutory withdrawal right may expire after the service has been fully performed only where the legal conditions are satisfied, including the consumer’s required prior express consent/request and acknowledgement regarding loss of the right. The wording and workflow must be implemented correctly for the actual contract.
Electronic withdrawal function from 19 June 2026
Where German law requires an electronic withdrawal function for a distance contract concluded through an online user interface, the business must provide the required clearly accessible withdrawal functionality during the withdrawal period and send the required confirmation on a durable medium.
The current portfolio contact form does not conclude a contract automatically. If future functionality allows consumers to conclude binding contracts directly through this website, the site’s checkout/contract flow and withdrawal functionality must be reviewed and updated before launch.
Model withdrawal information
Where a statutory right exists, the Provider should supply the legally required withdrawal instructions and, where required, the statutory model withdrawal form. A generic paragraph in these Terms is not a substitute for the legally required consumer information.
22. Defects, conformity and statutory remedies
Mandatory statutory rights concerning defective services, digital content or digital services remain unaffected. The Provider should be given a reasonable opportunity to investigate reproducible problems and, where required by law or contract, correct non-conforming work.
A request for a new feature, changed preference, changed scope or adaptation to a third-party change is not necessarily a defect in the original deliverable. Whether an issue is a defect depends on the agreed characteristics, intended use, statutory requirements and other relevant circumstances.
23. Liability
Nothing in these Terms is intended to exclude or limit liability where such exclusion or limitation is prohibited by mandatory law. In particular, liability for intent, gross negligence, injury to life, body or health, and liability under mandatory product-liability or other non-excludable statutory provisions remains governed by applicable law.
For ordinary negligence, any limitation must be drafted consistently with German law and the type of customer relationship. A professionally reviewed clause may distinguish liability for breach of essential contractual obligations and limit recoverable damages to typical foreseeable loss where legally permissible.
This template intentionally does not insert an aggressive blanket liability exclusion. A blanket clause could be ineffective, particularly in consumer terms. Obtain legal review if a specific liability cap is commercially important.
24. Confidential information
Where either party receives non-public technical, business or commercial information that is reasonably understood to be confidential, the parties should use that information only for the relevant project and protect it with reasonable care, subject to agreed exceptions.
Confidentiality obligations should not prevent disclosure required by law, court order or competent authority, nor information that is already lawfully public or independently developed without use of the confidential material.
Highly sensitive projects may require a separate non-disclosure agreement.
25. Personal data and data-processing roles
Personal data handled through the public website is described in the Privacy Policy. If the Provider processes personal data on behalf of a business client as part of a project, the parties must assess whether a processor relationship exists and whether an Article 28 GDPR data-processing agreement is required.
Clients should avoid providing production personal data during development unless it is necessary and appropriate safeguards have been agreed. Synthetic or minimized test data should be preferred where practical.
26. Cancellation and termination of project agreements
Contract termination rights depend on the individual agreement and mandatory law. The project agreement should state whether either party may terminate for convenience, what notice is required, how completed work is invoiced and how deliverables or client materials are handled on termination.
Rights to terminate for material breach or other statutory reasons remain governed by applicable law.
Consumer statutory withdrawal rights are separate from ordinary contractual termination and are addressed above.
27. Events outside reasonable control
Neither party should be treated as responsible for a delay to the extent it is caused by an event genuinely outside reasonable control, subject to mandatory law. Examples may include major infrastructure outages, natural disasters, widespread telecommunications failures, government action, war, severe cyber incidents affecting essential providers or other comparable events.
The affected party should communicate material delays where reasonably possible and take reasonable steps to limit their impact.
28. Projects and uses that may be refused
The Provider may refuse work that appears unlawful, fraudulent, abusive, infringing, malicious or incompatible with professional or safety obligations. This may include requests to build malware, credential theft, unauthorized surveillance, deceptive impersonation, unlawful access systems, discriminatory services or tools intended to violate third-party rights.
Refusal of a proposed project before contract formation does not require the Provider to disclose sensitive security or risk-assessment reasoning.
29. Governing law
The parties may agree that German law applies, subject to mandatory conflict-of-law rules and consumer protections that cannot lawfully be excluded.
Suggested placeholder: [GERMAN LAW CLAUSE TO BE REVIEWED FOR YOUR CUSTOMER MODEL].
If a consumer has their habitual residence in another country, mandatory consumer protections applicable under relevant private international law may continue to apply notwithstanding a choice-of-law clause.
30. Complaints, dispute resolution and jurisdiction
Clients are encouraged to contact the Provider first with a clear description of a concern so that the issue can be investigated and, where possible, resolved directly.
Any jurisdiction clause must respect mandatory consumer jurisdiction rules and should be professionally reviewed before use. Do not insert a clause claiming that consumers may sue only at the Provider’s location if applicable law does not permit that restriction.
If statutory information about consumer dispute resolution applies to the Provider, the legally required statement should be added here: [CONSUMER DISPUTE RESOLUTION STATUS / INFORMATION].
31. Severability and interpretation
If a provision of a binding agreement is invalid or unenforceable, the consequences are determined by applicable law. These Terms should not be interpreted as automatically replacing an invalid provision with whichever term is most favorable to the Provider.
Headings are provided for readability. The actual meaning of a clause depends on its wording, context, negotiated project terms and applicable law.
32. Changes to website Terms
The Provider may update the public website Terms for future website use or future agreements. Changes should not retroactively alter an existing contract unless the parties have a lawful contractual basis for modification and applicable requirements are satisfied.
The version incorporated into an accepted project agreement should remain identifiable. The “Last updated” date at the top should be changed when substantive revisions are published.
33. Contact regarding these Terms
Questions about these Terms may be directed to:
Provider: [LEGAL NAME]
Email: contact@mihai-teleuca.com
Postal address: [BUSINESS ADDRESS]