Clear engagements.

These Engagement Terms explain TBD's standard commercial and operating model. They are published for clarity, but they are not a standalone offer, do not amend a signed agreement, and cannot be changed unilaterally through this website.

For a client engagement, the signed MSA supplies the standing legal terms and the signed SoW states the binding scope, exclusions, acceptance checks, dates, fees, invoicing trigger, and selected operating route. If there is a conflict, the signed documents control for that engagement.

A prototype, demonstration, proposal, product description, backlog, or email helps the parties understand the work. It does not by itself authorise paid build, production use, source-code handover, access to TBD accounts or secrets, or ongoing support.

Each paid phase requires a signed SoW. The SoW may use short delivery iterations, but unselected or later-priority ideas remain a backlog until they are included in a signed SoW or Change SoW.

• Scope and exclusions: The SoW identifies what TBD will deliver and what is outside the phase.
• Commercial terms: The SoW fixes the actual fee, payment trigger, delivery timing, and any hosted-service charge.
• Changes: A material change to scope, timetable, price, business rules, integration, delivery route, or support requires a signed Change SoW before work begins.

The standard rates shown on this website are a S$5,999 one-time setup fee and a hosted-service fee of S$500 per month or S$5,400 per year, per application. They are published for transparency, not as a universal feature catalogue or a standalone offer.

The relevant SoW states the binding scope, exclusions, actual fee, invoicing arrangement, and whether a hosted service is elected. All amounts are in Singapore dollars unless the SoW says otherwise.

Unless a row says otherwise, an additional charge is cumulative: it is payable in addition to the base application setup fee, the applicable hosted-service fee, and any other approved work.

Multi-instance pricing applies only when the same corporate parent or billing entity deploys the same application pattern across separate operational datasets. Each setup fee is fixed when that instance goes live. The hosted rate re-prices on the next billing cycle according to the number of active instances.

The multi-instance tier does not extend to unrelated organisations, even where they use a similar application pattern.

• Payment: There is no upfront deposit. The setup fee is invoiced in full on acceptance, or on deemed acceptance, and the first month of hosted service begins then. Invoices are payable within 14 calendar days of issue and late-payment interest accrues at 1.5% per month from day 15.
• Non-payment: Where the standard MSA applies, TBD may suspend a hosted service if an invoice is more than 30 days overdue, on 7 days' written notice. Reactivation costs one month of hosted service plus the outstanding balance. Suspension does not waive amounts already due.
• Reactivation: Where a hosted service is suspended for non-payment, reactivation may require payment of the outstanding balance and any reactivation charge stated in the signed MSA or SoW.
• Third parties: Third-party components remain subject to their own licences or service terms. Their use does not transfer TBD accounts, credentials, or provider contracts to the client.
• Cancellation and refunds: Before a signed SoW there is no payment. Cancelling mid-build, after the SoW but before delivery, costs 50% of the setup fee. Cancelling after delivery but before acceptance costs 100% of the setup fee. Setup fees and prepaid periods are non-refundable except where the signed documents or applicable law expressly provide otherwise.
• One application: One application means one coherent workflow with one business outcome, primary decision-maker, and user base. Multiple internal roles or sites using the same shared rules and data normally remain one application; a distinct workflow, separate user base, or compulsory data isolation is separately scoped.
• Multiple instances and add-ons: The tables above state the standard reference pricing. The signed SoW or Change SoW fixes the binding commercial treatment for each engagement.
• Structured database records: Structured database records are not metered under the standard offering.

TBD delivers the agreed phase against the acceptance criteria in the SoW. Unless the SoW states otherwise, the client has ten Business Days after delivery—the two-week testing period—to test the deliverables against those criteria.

• Material non-conformity: A report must be in writing, identify the relevant acceptance criterion, include reproduction steps, expected result, actual result, and useful evidence.
• What does not block acceptance: Minor defects, cosmetic issues, later-priority ideas, and enhancement requests do not prevent acceptance when the deliverables substantially meet the agreed acceptance criteria.
• Cure: TBD will address a properly notified material non-conformity within a reasonable cure period and resubmit the affected deliverable for acceptance.
• Deemed acceptance: Where the standard MSA applies, deliverables are deemed accepted if the client does not notify TBD of a material non-conformity within the applicable testing period.
• Client delay: If required inputs, access, data, approvals, or feedback are delayed, the delivery timetable may extend accordingly. Prolonged non-cooperation may be treated as a material breach under the signed MSA.

By the end of the testing period, the client must give written notice whether it elects TBD-hosted service, client-operated handover, or no continuing service. Any temporary testing environment is only for the stated testing period; it is not an ongoing hosted service by silence.

• TBD-hosted service: A hosted service begins only if the client elects it and the SoW records the applicable activation and commercial terms.
• No automatic continuation: If no route is elected by the deadline, temporary testing hosting may end. TBD then has no obligation to provide continued hosting, production operation, support, or handover until the parties record a route in writing.
• Handover condition: A client-operated handover is available only if elected and after payment of the fees due for that phase. It does not transfer TBD accounts, credentials, secrets, or an unagreed support commitment.
• Return from self-hosting: A later request for TBD hosting after client-operated handover requires a signed Change SoW. If the client has not modified the delivered codebase, database schema, dependencies, configuration, or deployment architecture, TBD will resume hosting at the applicable hosted-service fee from the agreed activation date, without a separate re-entry or migration charge. If the client or a third party has made any such modification, TBD will quote the assessment, migration, remediation, security review, or deployment work required to resume hosting. That work is an additional charge to the hosted-service fee and must be approved before it begins.

Service levels, maintenance, monitoring, and support apply only to a TBD-hosted service expressly elected in a SoW. The SoW may set service-specific commitments; no service level is implied for a client-operated environment.

• Maintenance: TBD may correct reproducible defects against the agreed scope, apply reasonable dependency and security maintenance, and make operational changes needed to keep a TBD-hosted application running.
• Maintenance boundary: Maintenance does not include new workflows, integrations, reports, modules, material business-rule changes, expanded capacity, data migration, major redesign, or work caused by an upstream third party. Those items require a signed Change SoW.
• Standard service levels: The standard hosted-service reference is 99.5% monthly uptime, a first response to a reported issue within two Business Days, and a fix or a workaround for a P0 or P1 issue within two Business Days of the first response.
• Availability: Any uptime target, support hours, response target, maintenance window, and service credit are those stated in the signed documents for the hosted service.
• Client-operated environment: After client-operated handover, TBD has no support, security, uptime, backup, monitoring, or operational duty unless a later SoW expressly creates one.
• Standard support allocation: Unless the SoW says otherwise, the standard hosted-service reference includes four hours of Maintenance-class support per application per calendar month. Unused hours do not roll over; any overflow is quoted and approved before work begins.
• Issue priority: The SoW may classify P0/P1/P2/P3 issues. A P0 is an unavailable application or broken primary action; P1 is a major defect with a workaround; P2 is a minor defect or ordinary change; P3 is feedback or a later-priority idea. Out-of-hours work is best-effort unless the SoW says otherwise.
• Service credits: Where a SoW adopts the standard service-credit policy: uptime below 99.5% but at or above 99.0% earns a 10% credit, below 99.0% but at or above 98.0% earns 25%, and below 98.0% earns 50% of the monthly hosted fee. A missed first response earns 5% per ticket, capped at 25% of the monthly fee, and a missed P0 or P1 fix earns 10% per overrun day, capped at 50%. Credits apply to the following invoice and are not cash refunds; total credits in a month are capped at 50%.

An integration is a connection between the application and another system, such as an identity provider, calendar, payroll system, CRM, messaging platform, or hardware. It is separately scoped because the access, data mapping, reliability, and provider-side change risk vary substantially.

Every integration fee is an additional charge: it is added to the base application setup fee and, where applicable, to the hosted-service fee. The signed SoW or Change SoW fixes the actual integration scope and commercial terms.

• Integration acceptance: Each approved integration is added to the SoW or Change SoW with its own scope, setup fee, recurring fee, credentials, and acceptance check.
• Upstream changes: A provider-side API, authentication, pricing, or permission change is outside ordinary maintenance. TBD will notify the client when reasonably aware and quote remediation before it begins.
• Client responsibilities: The client owns and pays for its third-party accounts, supplies valid credentials and administrator consent, and tells TBD before a provider-plan change that may affect an integration.
• Excluded integrations: Payment-card handling, protected-health-information processing, hostile or undocumented APIs, and cross-jurisdiction data arrangements are out of the standard offering unless a specific SoW covers the required controls.

AI features, such as summarisation, classification, extraction, chat, or embeddings, are optional per application. They are never enabled by default and require written approval in the SoW or Change SoW.

• Usage charge: Standard AI usage is charged at five times the underlying model-provider token cost. The multiplier covers prompt engineering, logging, guardrails, evaluation, and operational management; it does not cover building the AI feature itself.
• Reconciliation: Usage is invoiced monthly in arrears, itemised by model and endpoint where the provider permits. The client pays only for the usage generated by its application.
• Spend cap: AI usage runs on a prepaid monthly budget that acts as a hard cap. TBD alerts at 80%. When the budget is spent, AI features pause until the client tops up or resets the budget for the next cycle. The AI budget is excluded from any annual prepayment discount.
• No instance discount: The AI multiplier does not receive the multi-instance discount because it tracks actual provider consumption.
• Building the AI feature: Adding an AI capability to an application carries a one-time build uplift on top of the setup fee: AI-1 at S$750 for a single contained call such as summarisation or classification, AI-2 at S$1,500 for retrieval over your own documents or a multi-step flow, and AI-3 from S$3,000 for agentic or multi-model work with evaluation harnesses.
• Model availability and price changes: Model pricing and availability are set by the provider. Where a provider changes price, deprecates a model, or withdraws capacity, TBD will move the feature to a comparable model and tell the client what changes. AI output is provided as-is and must be reviewed before it is relied on.
• Separate work: Fine-tuning, dedicated capacity, custom model hosting, or non-standard retrieval infrastructure is separately scoped and quoted.

For a TBD-hosted service, TBD processes personal data only as necessary to provide the agreed services and maintains reasonable application-layer controls. The client remains responsible for the purposes and lawfulness of its processing and for the data it enters into the application.

• Data roles: The client is ordinarily the Data Controller and TBD acts as Data Intermediary for the agreed services, subject to the signed MSA and any client-required privacy annex.
• Processing instructions: For a TBD-hosted service, TBD processes personal data only as necessary to provide the agreed services and on the client's documented instructions in the signed documents.
• Security measures: TBD's hosted application controls include authentication and authorisation logic, input validation, access controls, secure coding practices, and dependency hygiene appropriate to the agreed service.
• Breach and requests: The standard MSA requires TBD to notify the client within 72 hours of discovering a relevant personal-data breach and to provide reasonable assistance with access, correction, or withdrawal requests. The client remains responsible for the substantive response and legal assessment.
• Location and providers: The SoW records the selected hosting model and material data-location or provider information required for the client's approval. The website does not permanently commit TBD to a named provider, and overseas transfers require the written approval stated in the SoW.
• Return and deletion: Data export, return, deletion, and retention follow the signed MSA and SoW. The standard MSA provides for exit delivery after due fees are paid and deletion within its stated retention period, subject to lawful retention.
• Storage and exports: Hosted applications include 50 GB of uploaded-file storage per application. Database records are not metered under the standard offering. The application should include an administrative export function for the data tables available to the authorised client user; a specific export format or migration is separately scoped where needed.

On full payment of the relevant SoW fees, the client owns the client-specific deliverables created exclusively for its application, including bespoke business logic, custom user interface, client branding, and unique workflow code. TBD retains its pre-existing tools, reusable modules, build tooling, templates, methodologies, and general know-how.

• TBD Primitives Library: The client receives a perpetual, royalty-free, non-exclusive right to use embedded TBD reusable components solely as part of operating its delivered application.
• Third-party components: Third-party components remain subject to their applicable terms. They do not transfer TBD accounts, credentials, or service contracts to the client.
• Hosted operation: While TBD hosting is elected, TBD controls the live repository, deployment environment, secrets, and infrastructure for maintenance, monitoring, and security. Operational control is separate from ownership.
• Client-operated handover: After all relevant fees are paid, the elected handover package normally includes a source-code snapshot, database export, configuration inventory, and reasonable operating runbook. It excludes TBD accounts, credentials, secrets, and unagreed support.
• After handover: The client is responsible for its environment, deployment, credentials, access controls, backups, monitoring, patching, availability, data protection, provider relationships, and compliance. TBD has no ongoing operational obligation unless a later SoW expressly creates one.
• Retained record: TBD may retain the delivered code solely for audit, dispute-resolution, and statutory record-keeping purposes, subject to the confidentiality obligations in the signed MSA.

The MSA begins on its Effective Date. Each SoW remains in force for its stated phase, and an elected hosted service continues only on the term stated in its SoW or MSA.

• Termination for convenience: Either party may terminate on the notice period stated in the signed MSA; the standard MSA uses 30 days' written notice.
• Termination for cause: A party may terminate for a material breach that is not cured within the period stated in the MSA, or for insolvency or cessation of operations. The standard MSA uses a 14-day cure period.
• Effect: Accrued payment obligations remain payable. Data return, deletion, exit delivery, cancellation payments, and ongoing hosted-service shutdown follow the signed MSA and SoW.
• Survival: Data protection, ownership and handover, liability, confidentiality, and the general legal terms survive termination to the extent stated in the MSA.

TBD performs services with reasonable care and skill. Other warranties, the liability cap, excluded losses, and indemnities are set out in the signed MSA, subject to limits that cannot be excluded under applicable law.

• No guaranteed outcome: TBD does not promise uninterrupted or error-free operation, a particular business outcome, or fitness for an unstated purpose.
• Liability cap: Where the standard MSA applies, TBD's aggregate liability is capped at the fees paid by the client in the 12 months before the relevant event, subject to its stated carve-outs.
• Excluded loss: Subject to the signed MSA and applicable law, TBD excludes indirect, consequential, special, incidental, exemplary, and punitive loss, including lost profits, revenue, goodwill, business interruption, or unrecoverable data loss.
• Client-operated and third-party risk: Except where directly caused by TBD's breach, TBD is not responsible for a failure, security incident, or data loss caused by a client-operated environment, client or third-party modification, client-selected provider, unauthorised integration, or a failure to maintain operational controls.
• IP indemnity: The standard MSA provides a limited IP infringement indemnity for TBD's original application code, subject to prompt notice, TBD control of the defence, and the client's reasonable cooperation; it excludes third-party components and client-directed integrations.
• Client indemnity and review: The client is responsible for its data, end users, legal compliance, and use of the application, and must review outputs, calculations, reports, workflows, business rules, and approvals before relying on them for operational, HR, financial, or regulatory decisions.

Each party may receive non-public information from the other. Each must use that information only to perform the engagement, protect it with reasonable care, and not disclose it except as the MSA permits or applicable law requires.

The MSA states the confidentiality term, permitted disclosures, and any publicity or reference rights. A client should raise any stricter confidentiality requirement before signing the applicable SoW.

• Exceptions: Confidential information does not include information that is publicly available without breach, lawfully received from a third party without a confidentiality duty, independently developed without use of the other party's information, or required to be disclosed by law.
• Required disclosure: Where disclosure is legally required, the receiving party gives advance notice where legally permitted and discloses only what is required.
• Duration: The standard MSA confidentiality obligation continues for three years after termination, subject to any stricter signed requirement.

The client is responsible for its authorised users, the accuracy and lawfulness of its data, confirmation of business rules and role permissions, and compliance with laws applying to its operations. The application supports the client's work; it does not replace the client's judgment or legal obligations.

• Cooperation: The client should provide timely inputs, approvals, feedback, access, and decisions required by the SoW.
• Business rules: The client is responsible for confirming business rules, calculations, role permissions, approval workflows, and validation logic before acceptance and go-live.
• Credentials: The client must protect its credentials and promptly notify TBD of suspected unauthorised access to a TBD-hosted application.
• Regulated data: Payment-card data, protected health information, and other specially regulated data are out of scope unless an SoW and any required controls expressly cover them.
• Client-hosted operation: Following client-operated handover, the client is responsible for its hosting account, deployment, credentials, access controls, backups, monitoring, patching, availability, data protection, and operational decisions.

The application must not be used for unlawful activity, infringement, defamation, privacy violations, or activity that compromises the application or third-party infrastructure. TBD may suspend service for serious or repeated violations as allowed by the signed MSA.

Security testing of third-party infrastructure is not permitted. A client may test its own delivered code only with prior written notice and within the agreed environment.

• Prohibited conduct: The application must not be used to transmit malware, interfere with service, gain unauthorised access, evade controls, or infringe another person's rights.
• Sensitive uses: Payment-card data, protected health information, and other regulated data are not permitted unless the signed SoW expressly covers the required controls.
• Suspension: TBD may suspend a service for serious or repeated misuse as allowed by the MSA, without waiving its other rights.

The standard MSA is governed by Singapore law. It includes force majeure, non-solicitation, assignment, severability, notice, electronic-signature, independent-contractor, and dispute-resolution provisions.

• Force majeure: Neither party is liable for delay or failure caused by events beyond its reasonable control, including natural disaster, war, pandemic, government action, or infrastructure outage. The standard MSA permits termination if the event continues beyond its stated period, while preserving accrued fees.
• Non-solicitation: The standard MSA restricts direct hiring or engagement of TBD personnel with whom the client had material contact during the engagement and for 12 months afterwards, subject to its stated exceptions.
• Disputes: The parties first attempt good-faith negotiation, then mediation where required by the MSA, before unresolved matters proceed in the Singapore courts.
• Assignment and severability: Neither party may assign the agreement except as the MSA permits. If a provision is unenforceable, the remainder continues in effect.
• Entire agreement and notices: The signed MSA and SoWs are the entire agreement for the engagement. Formal notices must be in writing to the addresses specified in the signed documents.
• Amendments: A contract change requires a written instrument signed by both parties. Website updates are prospective information only and do not amend signed agreements.
• E-signature and status: The standard MSA permits counterparts and electronic signature. TBD acts as an independent contractor; the agreement creates no partnership, joint venture, employment, or agency relationship.
• No personal liability: The client contracts with The Boring Department Private Limited, not with its founders, directors, employees, contractors, or representatives personally.