Apple Desktop & Mobile Application Development

1. Purpose and Quote Objective Narrin is seeking quotations from experienced Apple mobile and desktop developers to adapt three existing, actively developed products for Apple platforms. The requested work is not a greenfield product design and is not a request to replace the established architecture. The selected supplier will work from the existing GitHub repositories, preserve current behavior, implement Apple-specific platform capabilities, and prepare reproducible builds for beta and store distribution. The product owner will remain the lead developer and architectural decision-maker for the codebase. The supplier is expected to provide focused Apple platform engineering, release engineering, quality assurance, and App Store submission expertise through reviewable pull requests and documented handoff. Quote goal: Provide comparable effort, schedule, staffing, assumptions, and cost for three progressive outcomes: a functional Apple developer build, a distributable beta, and App Store-ready polish. Quote each product and phase separately. 1.1 Products in scope • Narrin Studio Desktop for macOS, based on the existing cross-platform desktop application. • Narrin Studio for iPadOS/iOS, based on the existing Android tablet application and shared mobile codebase. • Narrin View for iPadOS/iOS, based on the existing Android read-only slideshow and offline playback application. 1.2 Information intentionally omitted This vendor brief intentionally excludes database schema details, credentials, OAuth identifiers, internal paths, proprietary implementation logic, production data, and deployment secrets. Qualified suppliers will receive full authorized GitHub repository access for technical discovery. Secrets will be supplied only through approved secure channels and must never be committed to source control. 1.3 Requested quote structure Suppliers should provide a fixed-price proposal where feasible, supported by an effort estimate and a stated hourly rate for approved changes. A capped paid discovery phase is acceptable. The quote must separate required base scope, optional alternates, third-party fees, and contingency assumptions. 2. Existing Product and Architecture Summary The products are functional development-stage applications with automated tests and established behavior. The objective is maximum responsible reuse. Apple adaptations must remain compatible with the existing Windows and Android products unless an approved platform-specific implementation is required. Product Existing foundation Apple target Reuse expectation Narrin Studio Desktop .NET desktop application using Avalonia for UI and Skia for deterministic image operations macOS Retain the current layered desktop architecture; add and validate macOS platform services, packaging, signing, and UX adaptation. Narrin Studio Mobile Expo/React Native application in a shared mobile monorepo; Android tablet implementation is functional iPadOS primary; iPhone as a separately quoted alternate Reuse shared TypeScript/React Native behavior and UI where appropriate; implement targeted Apple-native bridges rather than a wholesale rewrite. Narrin View Mobile Independent Expo/React Native application sharing product-neutral mobile packages; Android implementation is functional iPadOS and iOS; quote iPhone layout validation separately if material Preserve the read-only and offline-first boundaries; reuse shared packages and add Apple platform services. 2.1 Desktop architecture Narrin Studio Desktop is organized into practical boundaries for user interface, core product rules, external-service integration, and deterministic image rendering. The current application targets a modern .NET runtime, uses Avalonia for cross-platform desktop UI, and uses Skia-based rendering independent of UI screenshots. This architecture is specifically intended to support Windows and macOS from one codebase. • Desktop presentation: resizable, keyboard/mouse/trackpad-oriented studio workspace. • Core behavior: media identity, selection, metadata assignment, filtering, permissions, and workflow rules. • Infrastructure: authentication, database access, cloud providers, local files, secure token storage, caches, and preferences. • Rendering: deterministic image composition, photo/map editing exports, slideshow output, and testable output dimensions. 2.2 Mobile architecture Narrin Studio and Narrin View are separate applications within one mobile monorepo. They have independent product identities, builds, and release lifecycles, while sharing narrowly scoped packages for product-neutral domain rules, data access, cloud read contracts, and reusable UI controls. Studio retains write and authoring capabilities; View remains read-only with respect to source media and authoring data. • Shared-package changes must be backward compatible and regression-tested against both Android applications. • Product-specific screens and native modules remain inside the owning application when behavior is not safely shareable. • Sensitive sessions are stored in platform-protected storage; no client uses privileged backend credentials. • Current Android-native functions will require Apple equivalents or platform-neutral replacements where Expo modules are insufficient. 2.3 External service boundaries All three products use an existing hosted authentication and data service and integrate with Microsoft OneDrive and Google Drive. Some workflows also use local files or the system photo library. The supplier must preserve current tenant isolation, role-based permissions, cloud item identity, and non-destructive source-file behavior. Backend redesign is not part of this request. 3. Scope Principles and Delivery Constraints 1. Use the existing repositories and agreed baseline commits as the source of truth. Do not create a parallel replacement codebase. 2. Preserve product behavior and data contracts. Apple-specific adaptations should be isolated behind existing or newly approved platform interfaces. 3. Do not rewrite the mobile applications in native Swift or the desktop application in AppKit/SwiftUI unless presented as a separately priced alternative and approved in writing. 4. Do not modify the production database, security policies, or cloud data without explicit written authorization and an owner-reviewed change plan. 5. Do not place client secrets, privileged keys, refresh tokens, signing certificates, or production credentials in source control. 6. Maintain Windows and Android compatibility. Any shared-code change requires the applicable existing regression suites and a summary of observed impact. 7. Keep memory and storage bounded for large media libraries and offline slideshows. Apple lifecycle behavior must be designed explicitly rather than assumed from Android or Windows. 8. All work is delivered through branches and pull requests with reviewable commits, tests, release notes, and handoff documentation. 3.1 Baseline definition At kickoff, Narrin and the supplier will identify one baseline commit for each repository and agree on the feature-parity checklist. The codebase may continue to evolve under the lead developer. The quote should include a reasonable allowance for merging approved upstream changes, but material scope added after baseline will use written change control. 3.2 Apple platform assumptions • macOS base scope targets Apple Silicon. A Universal build including Intel support must be quoted as an optional alternate unless the supplier includes it in base scope. • Narrin Studio Mobile is tablet-first. Base scope is iPadOS in landscape and portrait; iPhone-specific Studio layouts are an optional alternate. • Narrin View should be assessed for both iPadOS and iPhone. The supplier must state which device classes and orientations are included. • The supplier should recommend minimum supported Apple operating-system versions based on framework compatibility, security support, and App Store requirements current at submission time. • Apple Developer Program membership, App Store Connect access, bundle identifiers, certificates, and provisioning will be controlled by Narrin and delegated at the minimum required access level. 4. Workstream A: Narrin Studio Desktop for macOS The macOS assignment is an enablement and production-readiness effort for the existing Avalonia desktop application. The supplier should reuse the current UI, core, infrastructure, and Skia rendering layers and implement only the platform-specific work needed for a reliable native macOS experience. 4.1 Functional developer build • Establish and document a clean macOS development environment, including supported .NET SDK, Avalonia, Skia, Xcode command-line tools where required, and reproducible repository commands. • Build and launch the application on current Apple Silicon hardware without Windows-only dependencies. • Implement or validate macOS file and folder pickers, local media access, drag/trackpad/mouse behavior, keyboard navigation, clipboard behavior, window sizing, high-DPI scaling, and application lifecycle. • Implement secure session and cloud-token persistence through macOS Keychain with clean logout and no plaintext fallback. • Validate system-browser OAuth callbacks and refresh behavior for supported cloud providers using public-client security patterns. • Validate image metadata reading, thumbnails, map/photo editing, deterministic rendering, file timestamps, save-back, and cloud/local destinations on macOS. • Run existing tests and add focused macOS tests for platform adapters and rendering differences. 4.2 Signed and notarized beta • Create a Release build with stable application identity, icons, versioning, entitlements, hardened runtime configuration, and reproducible packaging. • Produce a Developer ID-signed and Apple-notarized beta package suitable for external testing outside the Mac App Store. • Document certificate/profile handling without exporting long-lived secrets into the repository. • Perform smoke testing on a clean macOS user account and at least one additional supported macOS version or hardware configuration. 4.3 Mac App Store polish and submission support • Assess sandboxing, entitlements, file-access bookmarks, Keychain groups, network access, and cloud-provider compatibility for Mac App Store distribution. • Resolve App Store validation issues, required privacy declarations, permission explanations, application metadata, icons, screenshots, and reviewer notes. • Prepare and upload an App Store Connect build. If TestFlight for macOS is selected, configure and support that beta path as a separately identified deliverable. • Support reasonable review remediation for implementation-related rejection issues during the agreed warranty period. Distribution choice: Quote direct signed/notarized macOS distribution as the required beta path. Quote Mac App Store submission, sandbox adaptation, and Mac TestFlight as a separate phase or clearly priced option because those requirements may add platform constraints. 5. Workstream B: Narrin Studio for iPadOS/iOS Narrin Studio Mobile is a feature-rich tablet authoring application. The supplier must preserve the established Android behavior and shared mobile architecture while implementing Apple-native equivalents for platform services. The base user experience is iPad-first and must remain usable in landscape and portrait. 5.1 Apple-native capability audit The quote should include a repository audit that maps each Android-only or Android-sensitive capability to an iOS/iPadOS implementation. Expected areas include: • System photo and document selection, folder access where Apple permits it, security-scoped resources, and durable access rules. • Image metadata and EXIF orientation/capture-date handling with safe fallbacks. • Full-resolution image decoding, thumbnail generation, map and photo editing, deterministic rendering, JPEG/PNG encoding, and bounded memory use. • Secure authentication/session storage, Microsoft and Google authorization callbacks, token renewal, and account-switch behavior. • Cloud downloads/uploads, destination folder creation, cancellation, retry, background/foreground transitions, and provider error handling. • App lifecycle, orientation, safe areas, keyboard input where present, share/save behavior, and user-visible permissions. 5.2 Functional parity scope • Authentication, account/profile surfaces, tenant selection, role-aware controls, invitations where authorized, settings, About, and logout. • Local/system Photos, OneDrive, and Google Drive source selection appropriate to iPadOS; responsive Gallery browsing, thumbnail caching, full-image preview, imported-status recognition, multi-selection, import, and confirmed database removal without deleting originals. • Memory Context management for locations, people, events, tags, categories, hierarchical organization, maps, assignment, and role-controlled create/edit/delete workflows. • Map loading, naming, replacement, deletion, thumbnail preview, location assignment, and map hierarchy fallback for rendering. • Map Editor and Photo Editor interaction, orientation choices, non-overwriting save-back, and immediate Gallery insertion without a full cloud-folder rescan. • Single-image rendering for the established Wide and Tall output profiles, previews, non-overwrite naming, Render Library publishing, and stable memory behavior. • Slideshow filtering, preview, file availability classification, orphan review, cloud/local destination selection where supported, sequential rendering, cancellation, and progress reporting. 5.3 iPadOS developer build • Generate and maintain the iOS native project/configuration through the repository's supported Expo workflow. • Build for simulator and at least one physical iPad using development signing. • Deliver a functional parity report identifying complete, platform-adapted, constrained, deferred, and out-of-scope behavior. • Add unit/integration coverage for shared logic and native Apple bridges; retain Android regression coverage. 5.4 TestFlight and App Store polish • Create an App Store Connect archive with production JavaScript bundled and no dependency on a development server. • Configure bundle identity, version/build numbering, signing, associated callback schemes, capabilities, privacy manifest, usage descriptions, and required entitlements. • Distribute a TestFlight build, support internal/external tester setup, collect defects, and deliver agreed beta fixes. • Polish iPad layouts, rotation, loading/error/empty states, accessibility labels, VoiceOver order, contrast, touch targets, and Dynamic Type behavior where compatible with dense studio controls. • Prepare store metadata, screenshots, privacy responses, reviewer instructions, demo/test account procedure, and submission support. 6. Workstream C: Narrin View for iPadOS/iOS Narrin View is a separate read-only companion application for selecting, downloading, managing, and playing rendered slideshows. It must never acquire Studio authoring or source-deletion privileges. Apple work should reuse the existing shared read-side packages and keep the application independently buildable and releasable. 6.1 Functional parity scope • Authentication, secure session restoration, password recovery entry point, tenant selection, profile identity display, settings, About, and logout. • Read-only tenant-scoped slideshow filters for year, location, people, events, and tags, including hierarchy/category organization and established matching behavior. • Exact Render Library output selection without substituting another resolution, orientation, profile, source image, or tenant. • Read-only OneDrive and Google Drive authorization and download using stable cloud identity; no upload, overwrite, move, or delete methods. • Durable offline slideshow preparation, bounded concurrent downloads, retry, cancellation, progress, cache validation, storage limits, safe cache reuse, and reference-aware deletion of offline copies. • Full-screen slideshow playback with portrait/landscape behavior, contain fitting, play/pause, previous/next, durations, looping, stable shuffle, resume, keep-awake, and lifecycle-safe persistence. • Graceful handling of unavailable, missing, corrupt, or unreadable cached media without crashing or crossing tenant/user boundaries. 6.2 Apple-specific implementation • Implement Keychain-backed session/provider storage and Apple lifecycle-safe local persistence using the existing application data model. • Validate SQLite/file-system behavior, cache directory policies, storage reporting, backup exclusion, low-storage handling, and cleanup on logout/deletion. • Adapt orientation lock, keep-awake, media playback timing, background/foreground transitions, network reachability, and queued download resumption to iOS/iPadOS constraints. • Implement Microsoft and Google authorization registrations/callbacks for the separate Narrin View application identity. • Validate iPad and iPhone layouts included in the quote, including safe areas and accessibility. 6.3 Developer build, TestFlight, and store • Deliver simulator and physical-device developer builds with the complete included parity checklist. • Deliver a production-bundled TestFlight build and execute an agreed offline-playback test matrix on physical devices. • Prepare App Store metadata, privacy declarations, screenshots, reviewer instructions, and submission support independently from Narrin Studio. Strict product boundary: Narrin View is read-only. Apple adaptations must not introduce source-media deletion, metadata editing, rendering, upload, or privileged backend access. 7. Cross-Product Quality and Security Requirements 7.1 Security and privacy • Use only public-client authentication patterns appropriate to installed applications; do not embed client secrets or privileged backend keys. • Store sensitive sessions and tokens in Keychain or another owner-approved Apple-protected store. • Preserve tenant scope on every data operation and preserve existing role authorization. Never rely on hidden UI as the sole authorization control. • Use least-privilege cloud scopes and product-specific OAuth registrations. Studio write scopes and View read-only scopes must remain distinct. • Prepare accurate permission descriptions and assist Narrin with App Store privacy disclosures. No analytics, advertising, crash-reporting SDK, or tracking service may be added without written approval. • Disclose any use of subcontractors, external code-analysis services, or AI coding tools that could receive repository content. Private source must not be uploaded to unapproved services. 7.2 Performance and reliability • Keep large media folders responsive through virtualization, lazy thumbnails, caching, bounded concurrency, and cancellation. A representative use case exceeds 1,500 source images. • Keep batch rendering memory stable by processing and releasing one image at a time. • Keep offline slideshow playback stable for large manifests; only required media should be decoded or mounted at a time. • Handle expired tokens, connectivity loss, provider throttling, app suspension, low storage, and interrupted downloads with recoverable user-facing states. • Do not overwrite original source images or delete originals during database cleanup, editor output, rendering, or offline cache management. 7.3 Rendering and media correctness • Preserve EXIF orientation before portrait/landscape decisions and preserve capture-time semantics used by slideshow filtering. • Preserve exact output dimensions and orientation-specific contain/crop behavior without stretching. • Keep metadata, icons, map content, and borders within the final canvas at all supported profiles. • Validate deterministic output on Apple platforms against approved reference images or tolerances. • Preserve unique media identity by tenant, source, provider identity, and path; never match globally by filename alone. 7.4 Accessibility and Apple UX • Use native accessibility roles, labels, states, focus order, and VoiceOver announcements for actionable controls and status changes. • Meet reasonable contrast, touch-target, safe-area, keyboard, reduced-motion, and text-scaling expectations while preserving the application's compact professional layout. • Use Apple-standard dialogs, file/photo pickers, share/save surfaces, and error recovery where they improve platform fit without changing product rules. 8. Required Deliverables Deliverable Minimum content Applies to Discovery report Platform dependency map, Apple-native gaps, risks, included device/OS matrix, estimate reconciliation, and parity checklist All products Source changes Reviewable branches/PRs, focused commits, tests, no secrets, and owner-approved platform abstractions All products Developer builds Clean-checkout build instructions plus functional simulator/device or macOS build All products Beta artifacts Signed/notarized macOS beta and TestFlight builds for selected mobile products Quoted beta phases Release configuration Identifiers, entitlements, permissions, privacy manifest, icons, versioning, signing workflow, and environment documentation All Apple targets Test evidence Automated results, device/OS matrix, parity checklist, performance observations, defects, and accepted limitations All products Store package App Store Connect archive/upload, metadata checklist, screenshots, reviewer notes, privacy assistance, and validation results Quoted store phases Handoff Architecture notes, native bridge documentation, build/release runbook, known issues, and knowledge-transfer session All products 8.1 Documentation expectations Documentation should be concise and maintained near the owning code. It must allow the lead developer to reproduce builds, understand Apple-specific boundaries, renew or replace signing assets, update OAuth registrations, run tests, and prepare later releases without depending on the supplier's private environment. 9. Acceptance Criteria Final acceptance will be based on the kickoff parity checklist and the following minimum gates. Each phase may have its own agreed subset. 1. A clean authorized checkout builds using the documented supported toolchain without undocumented local patches or credentials. 2. The application launches as a production-style build and does not require a development server for beta or store distribution. 3. Included critical workflows pass on the agreed physical-device and operating-system matrix. 4. Existing applicable tests pass, new Apple-specific tests pass, and shared changes do not regress the current Windows or Android baselines. 5. Authentication restores securely, cloud authorization refreshes correctly, logout removes sensitive local state, and tenant boundaries remain intact. 6. Included source, Gallery, metadata, editor, rendering, slideshow, offline, and playback behaviors meet the approved parity checklist or have documented owner-approved Apple adaptations. 7. No original source file is unintentionally overwritten or deleted, and no filename-only identity regression is introduced. 8. Performance remains usable on representative large libraries and memory/storage behavior is bounded during long-running work. 9. Apple validation succeeds for the quoted distribution phase. Store approval itself cannot be guaranteed, but implementation-related review issues are addressed during the warranty period. 10. All source, documentation, configuration templates, and release runbooks are merged or delivered to Narrin, with no supplier-only dependency. 9.1 Suggested physical validation matrix Suppliers should state their proposed matrix and identify devices they will provide. At minimum, the quote should cover Apple Silicon macOS hardware, one current iPad, and one additional iOS/iPadOS device class for Narrin View. Include portrait/landscape checks where supported, a clean-install test, an upgrade test, connectivity interruption, low-storage behavior, and cloud authorization renewal.   10. Collaboration, Ownership, and Change Control 10.1 Narrin responsibilities • Remain lead developer, product owner, and final architecture authority. • Provide authorized GitHub access, product direction, acceptance priorities, branding assets, and available reference builds/test data. • Control production backend changes, Apple Developer/App Store Connect ownership, cloud application registrations, and release approval. • Review pull requests and answer product questions within an agreed cadence. 10.2 Supplier responsibilities • Provide an Apple platform technical lead and named contributors with relevant Avalonia/macOS, React Native/Expo iOS, Swift/native bridge, signing, and App Store experience. • Work transparently through issues, branches, pull requests, code review, test evidence, and weekly status/risk reporting. • Raise architecture or parity conflicts before implementation and present options with cost and schedule impact. • Maintain a current decision log, risk list, parity checklist, and release checklist. • Transfer all work product and avoid supplier-controlled build services, signing assets, or repositories as the sole source of release capability. The supplier must provide and maintain its own Apple development environment, including suitable Mac hardware, Xcode, and required development tools. All applications must be registered, signed, tested through TestFlight, and published exclusively under Narrin's Apple Developer Program and App Store Connect accounts. Bundle identifiers, application records, signing ownership, distribution history, and release control remain Narrin assets; the supplier receives only the role-based access needed to perform the work and must not publish any Narrin application through a supplier-owned or individual developer account. 10.3 Intellectual property and confidentiality The engagement agreement should assign project-specific work product to Narrin upon payment and protect all non-public source, credentials, product data, and documentation. Pre-existing supplier tools or libraries must be disclosed with their licenses. Copyleft or commercially restrictive dependencies require written approval before introduction. Before receiving repository access or any non-public technical or product information, the supplier and all assigned personnel and subcontractors must sign Narrin's non-disclosure agreement. The supplier acknowledges that Narrin Studio, Narrin View, and related designs and methods include patent-pending subject matter; disclosure does not grant ownership or license rights beyond those expressly stated in the engagement agreement. 10.4 Change control Material additions after baseline require a short written change request describing scope, affected products, effort, schedule, tests, and price. Routine defect correction needed to meet the accepted baseline is not treated as new feature scope. Suppliers should state the threshold they use for material change. 11. Assumptions, Exclusions, and Quote Risks 11.1 Base assumptions • Repository access and representative non-production test accounts/data will be available after contracting and required confidentiality steps. • Existing cloud and backend contracts remain available and materially unchanged during the quoted baseline. • Narrin will pay Apple program fees, third-party service fees, and approved device or certificate costs unless the quote states otherwise. • The supplier has legal access to current Apple development hardware, Xcode, and the physical devices included in its test matrix. • English-only UI and store materials are assumed unless localization is quoted separately. 11.2 Excluded unless separately quoted • Wholesale native rewrites, broad UI redesign, new product features, or backend/schema redesign. • Production data migration, bulk data repair, or direct production-database administration. • New subscriptions, in-app purchases, advertising, analytics, or billing/account systems. • Full Studio iPhone redesign, Intel Mac support, localization, MDM/enterprise distribution, or accessibility certification by an external auditor. • Ongoing operations, customer support, or indefinite compatibility maintenance after the stated warranty period. • Guaranteed App Store approval or guaranteed third-party cloud-provider approval; supplier remains responsible for correcting implementation defects within its control. 11.3 Risks the supplier must address • Apple sandbox and file-access differences from Windows/Android, including durable access to user-selected folders. • Differences in image codecs, EXIF handling, fonts, and rendering output across platforms. • OAuth redirect and secure token-cache requirements for three separately identified applications. • iOS background execution, download resumption, storage pressure, and app lifecycle constraints. • Framework or third-party package compatibility with current Apple submission requirements. • Maintaining Android and Windows behavior while introducing shared Apple changes. 12. Supplier Quote Response Requirements Please organize the quotation using the work packages below. Enter effort, calendar duration, price, staffing, assumptions, and exclusions for each line. Mark items not offered. Do not combine all three products into one unallocated total. ID Work package Effort / duration Price / assumptions D0 Capped repository discovery, dependency audit, parity checklist, and final implementation plan M1 macOS Narrin Studio functional Apple Silicon developer build M2 macOS signed and notarized external beta package M3 Mac App Store sandbox/polish/submission; identify whether Mac TestFlight is included S1 Narrin Studio iPadOS functional developer build and native capability parity S2 Narrin Studio TestFlight beta, device QA, and agreed beta fixes S3 Narrin Studio App Store polish, metadata, submission, and review support V1 Narrin View iPadOS/iOS functional developer build and offline/playback parity V2 Narrin View TestFlight beta, device QA, and agreed beta fixes V3 Narrin View App Store polish, metadata, submission, and review support R1 Shared CI/release automation, documentation, knowledge transfer, and warranty 12.1 Required commercial information • Fixed price and estimated hours by work package; hourly rates by role for approved changes. • Proposed start date, calendar schedule, dependencies, sequencing, and whether workstreams can run in parallel. • Named team roles, allocation, location/time zone, subcontractors, and expected product-owner time. • Payment milestones tied to demonstrable artifacts and acceptance gates. • Warranty period, defect-response targets, included submission/review cycles, and optional post-launch support rates. • Third-party licenses, services, hardware, accounts, travel, taxes, or pass-through costs not included in the quoted price. • Validity period of the quote and material assumptions that could change price. 12.2 Required technical response • Relevant macOS Avalonia/.NET and Skia experience, including signing/notarization or Mac App Store delivery. • Relevant React Native/Expo iOS experience, including custom Swift/Objective-C native bridges, TestFlight, and App Store submissions. • Proposed approach to Apple file/photo access, Keychain, OAuth, rendering parity, offline storage, and lifecycle constraints. • Proposed device/OS test matrix and the supplier-provided hardware available for testing. • Top technical risks, assumptions, proposed discovery activities, and any recommended scope alternatives. • Two relevant references or examples of shipped Apple applications of comparable complexity. 12.3 Optional alternates to price separately • Universal macOS build with Intel support. • Mac App Store/TestFlight path in addition to direct signed/notarized distribution. • Narrin Studio iPhone-specific UX adaptation. • Expanded Narrin View iPhone device matrix and phone-specific UX refinements. • Automated CI builds and signed beta delivery from an owner-controlled GitHub environment. • External accessibility audit, localization readiness, crash reporting, or extended maintenance. Selection basis: Narrin will evaluate relevant Apple experience, understanding of the reuse-first architecture, clarity of assumptions, delivery risk, collaboration model, evidence of quality, schedule, and total value - not price alone. 13. Proposal Acknowledgement By submitting a quotation, the supplier confirms that it has identified all major assumptions, understands that Narrin's product owner remains the lead developer, and will use the existing repositories as the implementation baseline. Any proposed architectural replacement must be clearly labeled as an alternate and must not be assumed in the base price. Full details are in the attached file.