PT. TIRTA BYTE TECHNOLOGYSmart Partner For Bright Future.
WEBSITE & PROJECT DISCUSSION TERMS

Understand the Terms.Plan Your Project Clearly.

Understand how to use the website information, start a discussion, and agree on work with TirtaByte. This explanation highlights what to discuss before a project begins.

Updated

01

What is this website for?

This website presents development information and the portfolio of PT. Tirta Byte Technology. You can explore solutions, read development examples, and submit your needs for discussion.

This page explains website use and the start of a collaboration discussion. Specific work should refer to the written proposal or agreement for that project.

02

How should I read portfolio and application examples?

Project details describe status, features, and boundaries. Portfolio information grants no source code access, customer identity rights, or resale licence.

Check the description on each page to understand the type of example shown:

Portfolio

Understand the context
  • Presents development work and scope that can be reviewed.
  • Read internal examples and customer projects according to their individual descriptions.

Illustration or preview

Understand the image's purpose
  • Images help explain activities or application interfaces.
  • An illustration does not replace checking which features and workflows are actually available.

Prototype or pilot

Review before use
  • An exploratory stage for learning about requirements and possible solutions.
  • Readiness for operational use needs validation in the relevant context.

A solution for your needs

Scope is discussed together
  • Features in an example do not automatically define all features in your project.
  • Users, workflows, data, and integration needs must be mapped for your situation.
03

What happens after I submit my needs?

The form receives your requirements for review. A successful submission confirms delivery of your message, rather than approval of a price or development start date.

  1. Describe your needs

    Explain your work, challenges, intended users, and the outcomes you are seeking.

  2. Discuss the design and scope

    Discuss priorities, features, data requirements, stages, costs, and project boundaries.

  3. Agree on implementation

    Document project details, acceptance checks, and each party's responsibilities in a written agreement.

Start a Requirements Discussion
04

What needs to be agreed before development?

Submitting a form does not confirm a price or schedule. Scope, milestones, acceptance criteria, costs, revisions, ownership, and support require a written agreement.

In practical terms, these discussions cover:

Features and deliverables

What will be built
  • Modules, workflows, reports, documents, or integrations included in the work.
  • Project boundaries and items outside the agreed scope.

Stages and schedule

When work is reviewed
  • Delivery stages and opportunities for joint review.
  • Data, access, or decisions from either party that affect timing.

Costs and payment

How costs are structured
  • Project value, payment stages, and applicable taxes.
  • Hosting, domain, external service, or licence costs where needed.

Acceptance and handover

How results are accepted
  • Test scenarios and criteria for checking the agreed requirements.
  • Documentation, guides, access, or training to be handed over.

This page does not set a universal price, deposit percentage, delivery deadline, or number of revisions. These details are discussed for each project's scope.

05

What happens if revisions or new requirements arise?

Distinguish revisions from additional features during discussion. Bringing a result into line with the agreed design differs from requesting a new workflow or module.

For example, adjusting an agreed report format differs from adding an inventory module that was previously outside the project scope.

If requirements change, the additional scope, effects on costs or timing, and delivery order need discussion and written agreement before implementation.

  • Explain the requested change and why it is needed.
  • Compare it with the design and scope already agreed.
  • Make sure both parties understand the change and its effects.
06

What about source code and usage rights?

Source code is the code developers use to build and modify an application. Source access, usage rights, ownership of deliverables, and resale permission need to be described in the project agreement.

Viewing a portfolio, trying a demo, or submitting a form does not grant source code access or permission to use logos, customer names, or third-party materials.

Computer programs are covered by copyright. Usage permission or licensing and rights to specific deliverables need to account for rights holders and applicable requirements. Third-party components or services follow their own licences.

Read the Indonesian intellectual property office's copyright introduction

07

What support is included after development?

Maintenance, fixes, further development, training, hosting, and backups should be listed if included in the engagement. Support duration, service hours, communication channels, and issue reporting follow the agreed scope.

When integrating other systems, review service availability, access permissions, costs, and provider terms. Changes from those providers can require integration adjustments.

  • Clarify the services included in and excluded from support.
  • Discuss who provides hosting, access, and the required service accounts.
  • Agree how to report issues and review further needs.
08

How should I understand demos, prototypes, and AI use?

Prototypes and pilots require validation before operational use. AI output requires human review appropriate to the context. No clinical decisions, financial profits, or automatic outcomes are guaranteed.

For example, AI can be explored for document summaries or information retrieval. Results still need review by someone who understands the content and work context.

Before use, discuss which data may be processed, how outputs are reviewed, usage boundaries, and the user's responsibilities in the relevant work.

09

How should I share information and handle confidentiality?

Provide accurate information relevant to your requirements. For an initial discussion, describe the work and challenges in general terms.

Do not send passwords, patient data, or confidential documents through the requirements form. If a project needs sensitive information, first discuss sharing methods, access rights, and confidentiality arrangements.

The Privacy page explains form data, newsletters, cookies, and how to make a request about your information.

Read the Privacy Explanation
10

What if something is unclear?

Ask about unclear points before agreeing to work. Use the general discussion form or the company email in the contact section below.

Website explanations can be updated as services develop. The update date appears at the top. Updating this page does not automatically change an existing project agreement.

Does submitting the form start a project immediately?

No. The form submits your needs for review. Work, price, and schedule require discussion and a written agreement.

Are all features in an example included in an offer?

Included features need to be listed in your project's scope. Website examples support discussion, while each team's requirements can differ.

Are source code and maintenance automatically included?

Source code access, licences, maintenance duration, and support need to be described in the proposal or agreement. Ask before agreeing to the work.

Where can I ask about costs and timing?

Use the general discussion form to describe your needs. Costs and timing are discussed based on scope, stages, and project data or access requirements.

Ask About Working Together
Back to top

Want to Clarify Your Project Plans?

Describe your needs or ask about scope, costs, timing, usage rights, and support before taking the next step.

Discuss Your Project Plans
Company emailinfo@tirtabyte.com

Use the general discussion form or contact this company email.