Back to ManifestQ Studios

Policy / Client delivery

Built clearly.
Operated responsibly.

The practical rules for designing, developing, integrating, launching, and supporting digital products for our clients.

Effective August 28, 2026

The written scope defines the build.

The Client controls production approval.

Compliance is designed in—not assumed.

Operational ownership is planned before launch.

/01

Purpose and application

This Client Development Policy explains how ManifestQ Studios (“ManifestQ,” “we,” or “the Studio”) delivers digital work for a customer or client (“Client”). It applies to websites, ecommerce, mobile applications, web applications, internal business systems, SaaS products, APIs, dashboards, data integrations, automation, artificial intelligence features, and communications products including SMS and MMS.

This policy is an operating framework, not a standalone contract or legal advice. The signed master services agreement, proposal, statement of work (“SOW”), change order, data-processing agreement, or other written project document controls if it conflicts with this page.

/02

Scope, decisions, and change control

Each engagement begins with written deliverables, assumptions, exclusions, dependencies, schedule, fees, and acceptance criteria. Discovery may change what should be built; it does not automatically expand the approved scope.

Requests affecting functionality, integrations, content volume, supported platforms, compliance work, schedule, or technical architecture may require a written change order. We will identify the expected effect before beginning materially different work.

/03

Client participation

The Client will provide timely access to decision-makers, systems, accounts, brand materials, content, policies, data, and accurate business requirements. The Client is responsible for reviewing work, consolidating feedback, making approvals, and identifying industry-specific obligations that apply to its business.

Delays in access, content, approvals, third-party reviews, registrations, or payment may move delivery dates. ManifestQ is not responsible for defects caused by incomplete, inaccurate, or unauthorized Client materials.

/04

Accounts, infrastructure, and third parties

Whenever practical, production domains, hosting, app-store accounts, communications providers, analytics, payment processors, repositories, and other critical services should be owned by the Client. The Client is responsible for provider fees, usage charges, taxes, renewals, account verification, and compliance with each provider’s terms.

Third-party services may change pricing, APIs, policies, availability, or approval requirements. ManifestQ may recommend or integrate a service but does not control that service and cannot guarantee its continued operation.

/05

Apple and Google application projects

ManifestQ can build, submit, publish, and maintain applications for a Client. A Client is not required by this policy to maintain its own Apple Developer or Google Play developer account. The project documents will select the publishing model appropriate to the product:

  • Studio-managed: ManifestQ publishes and administers the application through a ManifestQ-controlled developer account and grants the Client the visibility or operational access supported by the platform and engagement;
  • Client-owned: the Client owns the developer account and gives ManifestQ the role-based access needed to develop, submit, and maintain the application; or
  • Private or managed distribution: ManifestQ publishes to an approved enterprise, organization, testing, or private-distribution channel.

The chosen model must identify the public developer or seller name, application owner, signing authority, account administrator, party receiving store revenue, party paying platform fees, access rights, maintenance duties, and what happens at termination. Platform rules or the application’s category, content, monetization, distribution method, or regulated use may require a particular model.

Where a Client-owned account is selected, the Client will designate an authorized account holder and handle identity or organization verification, agreements, memberships, tax and banking information, paid-application terms, and matters only the owner can complete. ManifestQ will use individually assigned, role-based access; passwords, recovery codes, and personal authentication factors should not be shared.

For Apple and Google releases, ManifestQ may prepare builds, signing configuration, store records, screenshots, descriptions, review notes, testing tracks, privacy manifests, data-safety responses, permission explanations, and submission materials within the agreed scope. The Client must review and approve:

  • the legal entity, developer name, app title, bundle identifier or package name, categories, age/content ratings, pricing, territories, and support contacts;
  • the privacy policy, collected-data and data-safety disclosures, tracking declarations, third-party SDK behavior, retention practices, and user account-deletion path;
  • regulated claims, subscriptions, in-app purchases, external purchase flows, advertising, user-generated content controls, and any special entitlement or restricted permission; and
  • the final production build and store submission.

Store acceptance is controlled by Apple or Google and is never guaranteed. Review delays, rejections, policy changes, removals, account actions, required retesting, and provider outages may affect scope and schedule. ManifestQ will address implementation issues within the agreed scope; business-model changes, new platform requirements, appeals, legal analysis, or remediation of Client content and conduct may require additional work.

Signing keys, certificates, provisioning profiles, API keys, service accounts, app-transfer records, store metadata, source repositories, and recovery procedures will be documented and stored according to the selected publishing model. A Studio-managed application does not automatically give the Client ownership of ManifestQ’s developer account, credentials, or unrelated applications.

If an eligible application is to move between developer accounts, both parties will cooperate with the platform’s official transfer process. Transfers may require active accounts, current compliance, fees, technical changes, and platform approval, and may not carry every report, test group, integration, credential, entitlement, or financial record. Transfer work is included only when stated in the SOW or offboarding terms.

After launch, responsibility for memberships, agreements, store notices, user support, disclosures, platform funding, and compatibility or policy updates follows the selected publishing and maintenance model. ManifestQ’s ongoing management is limited to the services and term expressly included in the project or support agreement.

/06

Telnyx, SMS, and MMS projects

Messaging is a regulated product function—not simply a notification feature.

For products using Telnyx or another communications provider, ManifestQ may build number collection, consent records, messaging profiles, templates, API integrations, verified webhooks, queues, status tracking, suppression controls, audit records, and administrative tools. The exact controls included must be listed in the SOW.

ManifestQ’s Privacy Policy and Messaging Terms provide a reusable Studio framework. Each messaging program still requires an accurate program schedule, opt-in disclosure, message flow, samples, and the applicable provider registration or verification.

The Client is the sender and operator of its messaging program. Unless a written agreement says otherwise, the Client is responsible for:

  • obtaining valid, purpose-specific consent before sending and retaining evidence of when, where, and how consent was obtained;
  • using accurate opt-in language that identifies the brand, expected message types and frequency, support path, applicable message/data-rate disclosure, and a clear method to opt out;
  • honoring STOP, UNSUBSCRIBE, CANCEL, END, QUIT, and other applicable revocation requests, maintaining suppression records, and not bypassing provider or carrier blocks;
  • providing truthful brand, campaign, sample-message, website, privacy-policy, and terms information for 10DLC, toll-free, short-code, sender-ID, or country-specific registration;
  • sending only approved traffic for the registered use case and avoiding prohibited, deceptive, unsolicited, harassing, or unlawful content;
  • complying with Telnyx terms and acceptable-use rules, carrier and industry requirements, and the laws that apply to the sender, recipient, content, and destination country; and
  • monitoring the program after launch, including complaints, delivery failures, opt-outs, abnormal traffic, account balance, registration status, and credential security.

Client approval is required before production traffic is enabled. Registration approval does not establish legal compliance. Message acceptance by an API does not guarantee delivery: carriers and providers may filter, delay, reject, throttle, reroute, or block traffic. Numbers may be reassigned, and delivery receipts may be incomplete or delayed.

ManifestQ may pause messaging work or disable a sending function when we reasonably believe it creates a security, abuse, provider-policy, or legal risk. We will not import purchased lists, design around opt-outs, spoof identity, or knowingly enable unconsented messaging.

/07

Privacy, data, and security

We apply reasonable safeguards appropriate to the project, including least-privilege access, secret management, encrypted transport, validation, dependency review, logging, and abuse controls where relevant. No connected system can be represented as completely secure.

The Client must disclose sensitive, regulated, health, financial, biometric, children’s, location, or authentication data before it is used. Collection should be limited to what the product needs. The Client is responsible for its privacy notices, lawful basis, retention instructions, user requests, and required agreements with processors. Production credentials and sensitive personal data must not be sent through the public contact form or ordinary email.

/08

Accessibility, quality, and compatibility

We design and engineer for usable, responsive, maintainable products. Where applicable, our baseline is to work toward WCAG 2.2 Level AA. Formal accessibility conformance, legal review, assistive-technology testing, penetration testing, load testing, device labs, or certifications are included only when expressly scoped.

Supported browsers, devices, operating-system versions, traffic levels, performance targets, and uptime requirements will be defined by the project. Behavior outside that supported environment is not guaranteed.

/09

Content, AI, and automated decisions

The Client is responsible for the accuracy, legality, disclosures, permissions, and business use of Client-supplied content and data. AI-generated or assisted output may be incomplete, inaccurate, or unsuitable and requires appropriate human review.

Features that make or support consequential decisions about people require explicit scoping, appropriate review, explainability and appeal processes where applicable, and Client-approved governance. Sensitive Client data will not be submitted to a generative-AI service unless the project terms permit it.

/10

Testing, approval, and launch

ManifestQ will test the agreed workflows and provide the Client an opportunity to review them against the acceptance criteria. The Client is responsible for final business, content, compliance, and production approval. Approval may be recorded through email, the project system, or another agreed written channel.

Launch depends on completed approvals, required registrations, production access, content, and payment status. Material defects within the agreed acceptance or warranty process will be addressed under the project agreement; new requirements and third-party changes are separate work.

/11

Ownership and licensing

Ownership is governed by the signed project agreement. Unless it states otherwise, after full payment the Client receives the rights specified there in custom final deliverables created for the project. ManifestQ retains its pre-existing materials, reusable components, tools, methods, general know-how, and materials not created exclusively for the Client.

Open-source software, fonts, stock assets, platforms, APIs, and other third-party materials remain subject to their own licenses. The Client confirms it has the right to provide all names, marks, copy, images, code, data, and other materials supplied to ManifestQ.

/12

Fees, suspension, and offboarding

Fees, deposits, milestones, expenses, provider charges, and payment timing are set in the project documents. Work or production services may be paused for overdue payment, missing dependencies, misuse, or material security or compliance risk, subject to the agreement.

At completion or termination, we will provide the agreed deliverables and reasonable transition materials after required payment. Ongoing hosting, monitoring, backups, provider administration, security updates, app-store maintenance, messaging operations, and support are not included unless covered by an active support arrangement.

/13

Confidentiality, publicity, and contact

Each party will handle confidential information according to the project agreement and any applicable nondisclosure agreement. Unless restricted in writing, ManifestQ may identify the Client and display publicly released work in its portfolio without exposing confidential information, private systems, credentials, or nonpublic data.

Questions about this policy or a project’s requirements can be sent to [email protected].

Standards we reference

Project-specific requirements may draw from current provider and industry guidance. These external standards can change and must be rechecked for each launch.