Statement of Work · v3
Innovative AAC Application for iPad
Design, development, and publication of a novel AAC application for children ages 12–48 months — scene-based, contextual, and built for the App Store.
Section 1
Purpose
AbleNet seeks to advance innovation in the Augmentative and Alternative Communication (AAC) space for young children. The current market — dominated by products designed over a decade ago — has not kept pace with what modern interaction design, child development research, and platform capabilities make possible.
This SOW establishes a framework for the design, development, and publication of that application. The goal is bigger than a single app. The application is built from day one as the foundation for an innovation ecosystem — an architecture, content model, and clinical framework designed to absorb new ideas, new interaction modalities, and new research as the AAC field evolves. Most existing AAC products were built as finished objects, which is why the field has been frozen for a decade. This one is built to keep changing.
This is an innovation project. The path from concept to viable product will involve discovery, learning, and adaptation. This SOW is structured accordingly.
It uses precise definition where the path is known, and decision-making frameworks where it is not.
Section 2
Relationship Structure
Any Funded Need ("Developer") will design, develop, and publish the application. AbleNet, Inc. ("Funder") is commissioning the work and owns all intellectual property created under this SOW. Developer publishes and maintains the application under license from Funder.
2.1 Intellectual Property Ownership
All work product created under this SOW — including source code, designs, illustrations, vocabulary content, sentence templates, interaction designs, and documentation — is a work made for hire as defined under 17 U.S.C. § 101. To the extent any work product does not qualify as a work made for hire under applicable law, Developer hereby irrevocably assigns to Funder all right, title, and interest in and to such work product, including all intellectual property rights therein.
“Background Technology” means all pre-existing materials, development tools, frameworks, libraries, templates, processes, methods, know-how, and other reusable technology used to perform the work under this SOW. Developer retains ownership of all Background Technology. To the extent any Background Technology is incorporated into the work product, Developer grants Funder a perpetual, worldwide, non-exclusive, royalty-free license to use such Background Technology solely as embedded in, and as necessary to use, the work product delivered under this SOW.
2.2 Publication License
Funder grants Developer a license to publish, distribute, and maintain the application on the Apple App Store under Developer's entity. The specific terms of this license — including scope, exclusivity, duration, revocability, territorial restrictions, and sublicensing rights — shall be documented in a separate Publication License Agreement between the parties.
Until the Publication License Agreement is executed, Developer is authorized to take all steps necessary to prepare the application for App Store submission, including registering an Apple Developer account and configuring App Store assets.
Clinical Publishing Partner
The parties may agree — prior to App Store submission — to publish the application under the entity of a recognized speech-language pathologist, AAC clinical organization, or non-profit partner ("Clinical Publishing Partner"), in lieu of or alongside Developer's own entity, in order to establish credibility within the AAC clinical community. Any such arrangement requires Funder's prior written consent and shall be documented in a separate agreement addressing the Clinical Publishing Partner's role, Funder's anonymity, IP ownership (which remains with Funder regardless of publishing entity), Funder's indemnification obligations extending to the Clinical Publishing Partner in their publishing capacity, and exit provisions.
2.3 Brand Identity
The application will be published under the product brand "Meadow" (or such other product name as the parties may agree). The product brand is distinct from both AbleNet's brand and Developer's entity name. Visual identity, tone, and messaging for the product brand will be established during Phase 1.
2.4 Funder Anonymity
AbleNet will not be referenced in any public-facing capacity related to the application. This includes the application name, in-app content and credits, App Store listing, marketing materials, support communications, and any promotional materials. AbleNet will not publicly claim involvement with the application without Developer's written consent. Developer will not disclose Funder's identity in connection with the application without Funder's written consent. Funder may provide private clinical guidance for support responses, which will not be attributed to Funder publicly.
Section 3
Collaboration Framework
3.1 Roles
Developer
Responsible for all design, architecture, implementation, publication, and ongoing maintenance. Brings product vision, technical execution, and domain expertise in AAC design and child interaction.
Funder
Provides financial support, AAC market insight, clinical perspective, and SLP access. Funder's input is integral to product decisions and strengthens the product through collaborative dialogue.
3.2 Decision-Making Process
Decisions are made collaboratively. Both parties bring distinct expertise to the table.
Product Decisions
What to build, how it works, visual design, interaction patterns. Developer proposes; Funder provides feedback. Decisions are reached collaboratively, with Developer carrying the technical and product-vision perspective and Funder contributing AAC market and clinical insight.
Both parties have a stake in getting this right. Genuine dialogue produces better product than either party deciding alone.
Priority Decisions
What to build next, what to defer. Either party may propose; both discuss. Priorities are set jointly, weighing Funder's market perspective against Developer's assessment of technical dependencies and feasibility.
Market need and technical sequencing both matter. Neither lens alone produces the right roadmap.
Scope Decisions
What's in, what's out, what changes. Governed by the Scope Management process (Section 6). Scope changes require mutual agreement in writing.
Neither party should be surprised by a scope change — the framework ensures discussions happen early and decisions are shared.
In the rare event of genuine deadlock after good-faith discussion, both parties agree to escalate to a brief structured conversation (in person or by call). If the deadlock persists after that conversation, Funder holds the deciding vote. This tiebreaker is a last resort — the expectation is that collaborative discussion resolves the vast majority of decisions without invoking it.
3.3 Communication
Milestone Demos
Developer presents milestone deliverables (design specs for M1, working software for M2+). Funder has three (3) business days to provide informal feedback — reactions, questions, concerns. Formal acceptance is governed by Section 3.6.
Progress Updates
Developer provides brief written updates at least every two (2) weeks during active development.
Scope Discussions
Either party may initiate a scope conversation at any time. These are expected and productive, not adversarial (see Section 6).
3.4 Funder Contributions (In-Kind)
In addition to financial support, Funder will provide the following non-monetary contributions.
SLP Access
Funder will connect Developer with three to five (3–5) independent speech-language pathologists for design validation during Phase 1 and clinical review during Phases 2 and 3. Typical expectation: 8–16 hours per phase. SLP engagement is advisory — incorporation of feedback is a collaborative product decision under Section 3.2.
SLP Attachment
Funder may, at its discretion, facilitate attachment of a high-profile speech-language pathologist from its professional network to serve as a clinical advisor to the project. Terms of any such engagement — including scope, compensation, and IP assignment — will be documented separately.
Apple Developer Program
Funder will reimburse Developer for the annual Apple Developer Program membership fee ($99/year) required to publish and maintain the application. Reimbursement is due within thirty (30) days of Developer presenting a receipt.
Publisher Infrastructure
Funder will reimburse Developer for documented, reasonable infrastructure costs incurred in operating the publisher presence: domain registration, email hosting, and static site hosting. Estimated cost: $10–15/month. Reimbursement due within 30 days of itemized invoice. Developer obtains Funder's written approval before incurring costs exceeding $25/month.
3.5 Publishing Obligations
Developer, as publisher, will provide the following post-launch publishing and support services.
Support Channel
A dedicated public-facing contact channel monitored during U.S. business hours (Eastern Time, Monday–Friday, excluding federal holidays) for technical issues related to the application, App Store listing, and support site.
Support Site
A simple static website providing: frequently asked questions, a getting-started guide, a privacy policy, and terms of service. May be hosted on a free or low-cost platform (e.g., Vercel, GitHub Pages).
Response Times
Critical issues (app crash affecting core communication, data loss): response within 1 business day.
Non-urgent technical inquiries (minor bugs, public-site issues): response within 3 business days.
Non-urgent technical inquiries (minor bugs, public-site issues): response within 3 business days.
App Store Monitoring
Developer will monitor and respond to App Store reviews as appropriate, maintaining a professional and supportive tone consistent with the product brand.
Initial Support Period & Scope Limits
For the first 90 days following initial App Store launch, routine technical support is included at no additional cost beyond infrastructure reimbursement. If support volume exceeds 2 hours/week average thereafter, the parties will negotiate a support retainer via Feature Addendum.
Clinical, therapeutic, and end-user onboarding inquiries may be routed to Funder's designated SLP or support contact. Developer is not responsible for providing routine clinical guidance. Any support or services outside this scope are billed at Developer's standard rate of $200/hour, subject to Funder's prior written approval.
3.6 Milestone Acceptance
Two Distinct Review Windows
Informal feedback (3 business days). As described in Section 3.3, Funder has three (3) business days from a milestone demo to provide initial reactions, questions, and informal feedback. This is the working dialogue — it does not constitute formal acceptance or rejection.
Formal acceptance (5 business days). Funder will provide a formal written decision within five (5) business days of milestone delivery. Funder will either: (a) accept the milestone in writing; or (b) provide a written rejection describing the specific ways in which the deliverable does not materially conform to the milestone description. If Funder does not provide written acceptance or rejection within that five-business-day period, the milestone is deemed accepted.
Both windows run from milestone delivery. The informal feedback window gives Funder a prompt opportunity to raise concerns; the formal acceptance window gives Funder sufficient time to assess the deliverable and issue a binding decision.
Section 4
Project Structure
Four phases from discovery to ongoing innovation, with precise definition where the path is known and decision-making frameworks where it is not.
$10K
Phase 1: Discovery & Design
$15K
Phase 2: Foundation + First Scene
$20–35K
Phase 3: Full App + Launch
Ongoing
Phase 4: Innovation Layers
$45,000 – $60,000
Estimated budget through launch (Phases 1–3). Phases 1 and 2 are firm commitments. Phase 3 becomes firm through amendment. Phase 4 is ongoing innovation funded per Feature Addendum. Either party may choose not to proceed with subsequent phases.
Phase 1: Discovery & Design — $10,000
The mockups and research in the proposal show what could be. This phase turns concepts into buildable specs through deep R&D, clinical validation, and design iteration.
M1
Design Specs
Validated design system, vocabulary architecture, and buildable feature specs
Deliverables
- Target developmental level determination with SLP input (single level appropriate for the 12–48 month population; Phase 1 research determines exactly which level)
- Vocabulary architecture: core word list, scene-specific vocabulary, vocabulary scope calibrated to target developmental level
- Interaction design specs: navigation flow, conversation loop behavior, communication board layout, scene-to-board toggle interaction
- Visual design system: illustration style, color system, animation language, Fitzgerald Key integration
- Parent gate & onboarding flow: first-run setup, parent gate mechanism (two-layer: multi-touch + optional PIN), settings architecture
- SLP review: 3–5 independent speech-language pathologists validate vocabulary structure, interaction design, developmental appropriateness, and clinical credibility
- Buildable feature specs for every Phase 2 deliverable
- Product brand identity: name confirmation, visual tone, App Store positioning
Phase 1 Payment Schedule
| Payment | Amount | Trigger |
|---|---|---|
| Project Start | $5,000 | Upon signed SOW |
| M1 Accepted | $5,000 | Design specs delivered and reviewed |
| Phase 1 Total | $10,000 |
Phase 2: Foundation + First Scene — $15,000
With validated specs in hand, this phase produces the architectural foundation and one complete scene that proves the entire approach on real hardware.
M2
Engine Foundation
Core application engine, running on iPad hardware with developer-only UI
Deliverables
- Single developmental level driving vocabulary scope and sentence complexity (level determined in Phase 1)
- Navigation state machine (Scene → Zone → Sub-zone → Item, with variable depth)
- Communication board: persistent grid-layout vocabulary board available alongside scene navigation via swipe gesture toggle
- Sentence template engine (2–3 word combination templates appropriate to target developmental level)
- Speak-Choose-Speak conversation loop engine
- Text-to-speech with age-appropriate voice profile
- Persistent core word bar (high-frequency words calibrated to developmental level)
- Scene-contextual avatar system (self-expression vocabulary per scene)
- Parent gate (two-layer: randomized challenge + PIN)
- Child profile setup (interests, hearing status, sensory preferences)
- Interaction event logger (structured, append-only, from day one)
- Reward/celebration system (variable-ratio, surprise-based)
- Accessibility infrastructure (VoiceOver, Switch Control scaffolding, 60–80pt touch targets)
Architectural Commitments (built for future, not shipped as features)
- Fully data-driven content hierarchy — scenes, zones, sub-zones, vocabulary, avatar phrases, sentence templates, and SCS follow-ups defined in structured configuration. Adding content at any level requires zero code changes.
- Unified zone data model — zones and sub-zones share the same structure, enabling variable depth per scene.
- VocabularyStore protocol abstraction enabling future cloud sync without rewriting consuming components.
- Profile-keyed data throughout, enabling future multi-profile support as UI work only.
- Three-modality speech hook enabling future ASL animation and symbol highlighting.
- Observable state machine enabling future hardware integration.
- Swappable SCS strategy enabling future AI-powered follow-up generation.
- Semantic symbol ID system enabling symbol set swaps via lookup table update only.
- String externalization as foundation for future localization.
- Developmental level abstraction enabling future multi-tier support if the population scope expands.
M3
Kitchen Scene Complete
One scene taken to full viable depth — proving the interaction model works at real-world scale
Deliverables
- Kitchen scene with final illustrations (AI-generated to consistent visual theme)
- 6+ zones (Fridge, Pantry, Stove, Table, Fruit, Drinks) with sub-zones where vocabulary depth demands it
- Full vocabulary depth: 100+ items across zones including food, drinks, utensils, people, actions, descriptors
- Avatar context phrases for Kitchen (self-expression: hungry, thirsty, all done, yummy, yucky, etc.)
- Sentence templates (2–3 word combinations) for every item
- SCS follow-ups tagged by pragmatic function for every item
- Communication board functional and togglable alongside scene navigation
- Complete child experience: navigate → explore → tap → speak → converse → celebrate
- Both orientations, VoiceOver functional, touch targets validated on hardware
Why Kitchen First?
It has the deepest vocabulary requirements (food alone demands 60+ items), the most complex zone structure (fridge with sub-shelves), and the highest daily relevance for families. If the UX works for Kitchen, it works for everything.
What We Learn from Kitchen
Does the zone pattern hold at 100+ items per scene?
How long does vocabulary authoring actually take at viable depth?
What's the real illustration pipeline effort per scene?
Does the SCS loop feel like a conversation or a menu?
Does the communication board complement scene navigation effectively at the target developmental level?
Phase 2 Payment Schedule
| Payment | Amount | Trigger |
|---|---|---|
| M2 Accepted | $8,000 | Engine foundation on hardware |
| M3 Accepted | $7,000 | Kitchen scene complete at viable depth |
| Phase 2 Total | $15,000 |
Phase 3: Full App + Launch — Scoped via Amendment
After Kitchen is complete, both parties will have concrete knowledge about what "viable depth" means per scene: vocabulary count, illustration effort, authoring time, and UX patterns that work.
M4
All Scenes
Remaining scenes built on the proven foundation, parent area functional
- Remaining scenes at appropriate vocabulary depth per scene (scene count and selection determined collaboratively based on Phase 1/2 findings and Funder's market perspective)
- Parent dashboard, child profiles, and settings
- SLP export functionality
M5
Ship It
Accessibility audit, App Store compliance, submission, and launch
- Accessibility testing on hardware (VoiceOver, Switch Control)
- Apple Kids Category compliance
- App Store submission by Developer, plus reasonable iteration to address ordinary App Store review feedback
- Support site live (per Section 3.5)
- Final review with Funder
Amendment Scope
Phase 3 will be defined in a SOW Amendment based on what we learned in Phases 1 and 2. The amendment will specify scene count and selection, target vocabulary depth per scene, parent area scope, accessibility and compliance work, timeline, and payment milestones for M4 and M5.
Estimated Budget: $20,000 – $35,000 (Not to Exceed $35,000)
This estimate will be refined in the amendment. The amendment structure lets us price Phase 3 honestly. Total Phase 3 fees will not exceed $35,000 without a further written amendment signed by both parties.
Amendment window. The parties will work in good faith to agree on the Phase 3 amendment within thirty (30) days of M3 acceptance. If no amendment is executed within that window, the project exits under Section 7.4 with all completed work belonging to Funder and all accepted milestones paid in full.
Total Project Estimate (Through Launch)
| Phase | Structure | Estimated Budget |
|---|---|---|
| Phase 1: Discovery & Design | Fixed scope, defined above | $10,000 |
| Phase 2: Foundation + First Scene | Fixed scope, defined above | $15,000 |
| Phase 3: Full App + Launch | Amendment after Phase 2 | $20,000 – $35,000 |
| Total Through Launch | $45,000 – $60,000 |
Phases 1 and 2 are firm commitments. Phase 3 is an estimated range that becomes firm through amendment. Either party may choose not to proceed with subsequent phases (see Section 7.4). Phase 4 (Innovation Layers) is funded separately per Feature Addendum — see Section 5.
Section 5 — Phase 4
Innovation Layers (Post-Launch)
M6
Grow
Ongoing innovation releases funded per Feature Addendum — the innovation pipeline stays open
M6 is an ongoing milestone, not a one-time deliverable. It represents the continued evolution of the application after launch: new scenes, new innovation layers, hardware integrations, and clinical refinements. Each release under M6 is governed by its own Feature Addendum. Intellectual property created under a Feature Addendum is owned by Funder under the same terms as Section 2.1.
5.1 Feature Development Framework
Following publication, Developer will continue enhancing the application. Funder may fund additional features on a per-feature basis through Feature Addendums.
Feature Addendum Contents
Each Feature Addendum specifies what the feature delivers (user-facing behavior), what architectural foundation it builds on or extends, cost, and acceptance criteria. Default payment: 50% on start, 50% on acceptance. Feature Addendums are lightweight — typically 1–2 pages.
Pricing Guidance (not binding — actual pricing per Feature Addendum)
$3–5K
Content Addition
New scene, vocabulary expansion, visual theme
$5–10K
Feature Build
Parent dashboard analytics, SLP export, custom vocabulary UI
$10–15K
Platform Capability
Switch Control, hardware integration, concept features
5.2 Feature Decision Framework
User Impact
How many children/families does this serve?
Innovation Value
Does this advance the state of AAC, or is it table stakes?
Foundation Leverage
Does the existing architecture support this, or does it require new infrastructure?
Market Signal
Are SLPs, parents, or competitors indicating this matters?
Developer determines feasibility and timeline. Funder determines funding. Neither party is obligated to propose or accept features.
5.3 Sustainability Threshold
Graceful Conclusion of Funding
AbleNet's funding purpose is to bring an innovative AAC product to viability and give it room to grow. The application will be offered free of charge. Funder's obligation to fund Feature Addendums under this Section concludes eighteen (18) months after initial App Store launch, or upon mutual written agreement that the application has reached an alternative sustainability path (institutional adoption, grant funding, sponsor support, or similar), whichever comes first.
Any Feature Addendum in progress when the threshold is reached is completed and invoiced per its terms. Developer continues publishing and maintaining the application under the Publication License (Section 2.2). Funder retains all intellectual property rights per Section 2.1.
Nothing prevents Funder from voluntarily funding features beyond the threshold by mutual agreement.
Section 6
Scope Management
Scope will change. Requirements will be discovered. Priorities will shift. This section establishes how those conversations happen productively.
6.1 Key Assumptions
The following assumptions underpin the current scope and estimates. If any assumption proves wrong, it triggers a scope conversation — not a crisis.
Assumption
A single developmental level (determined in Phase 1 with SLP input) is appropriate for the 12–48 month target population
If wrong: SLP review indicates the population needs stratified vocabulary or multiple interaction modes
Triggers: Scope conversation about adding developmental tiers; affects engine complexity and content volume
Assumption
The number of scenes selected for launch provides sufficient vocabulary breadth for a credible AAC product
If wrong: User testing or SLP review indicates critical gaps
Triggers: Additional scenes needed, affecting Phase 3 scope
Assumption
AI-generated illustrations can achieve consistent, child-appropriate visual quality
If wrong: Art quality is inconsistent or insufficient
Triggers: Professional illustration costs enter scope
Assumption
Vocabulary authoring at viable depth takes roughly 1–2 days per scene
If wrong: Kitchen scene reveals it takes significantly longer
Triggers: Phase 3 timeline and budget need adjustment
Assumption
The data-driven scene system handles all scenes without architectural changes
If wrong: A scene type requires fundamentally different interaction (e.g., People scene isn't zone-based)
Triggers: Architecture adjustment needed before that scene
Assumption
Apple approves the app under Kids Category on first or second submission
If wrong: Apple rejects for unexpected compliance reasons
Triggers: Compliance remediation affects M5 scope in Phase 3
Assumption
Emoji/AI-generated symbols are acceptable for launch
If wrong: SLP review indicates clinical-grade symbols required
Triggers: Symbol licensing cost enters scope
Assumption
Communication board and scene-based navigation are complementary (not confusing) at the target developmental level
If wrong: User testing shows the dual-mode interaction is overwhelming or unused
Triggers: Simplify to one primary navigation mode
6.2 How Scope Changes Work
- Either party identifies a scope question — a new need, a wrong assumption, or a discovered dependency.
- Developer assesses impact — what changes, what it costs (time and money), what it affects downstream.
- Both parties discuss — is this essential, important, or nice-to-have? Does it fit in the current phase or become a future amendment?
- Decision is documented — as an amendment to the current phase, a new Feature Addendum, or a noted deferral with rationale.
Scope changes are not failures. They are evidence of learning. The goal is to make the best product decisions with the information available at each stage.
6.3 Scope Boundaries
Regardless of discovery and adaptation, the following boundaries hold unless explicitly amended:
- ✓ iPad-only (no iPhone, no Android)
- ✓ Offline-first (no network dependency in child-facing experience)
- ✓ Target population: children ages 12–48 months
- ✓ Native iOS application (no web prototype or web-based version)
- ✓ All data remains on-device (no cloud services in initial release)
- ✓ Targets Apple Kids Category compliance
- ✓ Free of charge (no in-app purchases, subscriptions, or paid tiers)
Section 7
General Terms
7.1 Intellectual Property
All intellectual property created under this SOW is owned by Funder as set forth in Section 2.1. Developer's rights to publish and distribute the application are governed by the Publication License described in Section 2.2.
Developer represents and warrants that all work product delivered under this SOW will be original or properly licensed, and will not infringe upon any third party's intellectual property rights. Developer will not incorporate open-source software into deliverables without first providing written disclosure to Funder, including the applicable license terms.
7.2 Confidentiality
Definition. "Confidential Information" means any information disclosed by one party to the other in connection with this SOW that is marked confidential, identified as confidential at the time of disclosure, or that a reasonable person would understand to be confidential given its nature and the circumstances of disclosure. Includes, without limitation, the terms of this SOW, pre-release deliverables, source code, design specifications, vocabulary content, illustrations, business plans, financial information, and product roadmaps.
Obligations. The Receiving Party shall: (i) use Confidential Information solely for purposes of performing under this SOW; (ii) protect it with at least the same degree of care used for its own similar confidential information, and no less than reasonable care; and (iii) not disclose it to any third party except to employees, contractors, and advisors who have a need to know and are bound by equivalent obligations.
Survival. Confidentiality obligations survive expiration or termination of this SOW for five (5) years; obligations with respect to trade secrets survive for as long as the information remains a trade secret under applicable law.
7.3 Non-Affiliation and Brand Identity
Non-Affiliation. Funder anonymity is governed by Section 2.4. Neither party shall use the other party's name, logo, trademarks, or service marks in marketing materials or public communications without the other party's prior written consent, except as required by law.
Brand Identity. The product brand established under Section 2.3 is owned by Funder as part of the intellectual property created under this SOW. Developer is licensed to use the product brand in connection with publishing and maintaining the application under the Publication License (Section 2.2).
7.4 Phase Transitions and Exit
Either party may choose not to proceed with the next phase for any reason.
Upon such decision:
- All work completed to date belongs to Funder (per Section 2.1)
- All accepted milestones are paid in full
- No future payment obligation exists
- Developer delivers all work product to Funder in a usable format within fourteen (14) days
- The Publication License (Section 2.2) terminates unless the parties agree otherwise in writing
- The relationship ends on professional terms
This structure ensures neither party is locked into a project that isn't working. Phases 1 and 2 produce validated specs, a functional engine, and one complete scene — valuable regardless of whether subsequent phases proceed.
7.5 Termination Mid-Phase
Fourteen (14) days written notice
Either party may terminate during an active phase. Upon termination:
- All work completed to date belongs to Funder (per Section 2.1)
- Funder pays for accepted milestones plus any milestone more than 50% complete, as assessed in good faith by Developer with supporting documentation
- No refund is due for accepted milestones
- Developer delivers all work product to Funder within fourteen (14) days of the termination effective date
- The Publication License (Section 2.2) terminates unless the parties agree otherwise in writing
7.6 Warranty
Developer warrants that delivered software (M2+) will function substantially as described in accepted milestones for thirty (30) days following each milestone acceptance. Bug fixes within this period are included at no additional cost. Feature requests or enhancements are not covered. Bugs reported after the warranty period may be addressed under a Feature Addendum.
7.7 Limitation of Liability
To the maximum extent permitted by law, each party's aggregate liability arising out of or related to this SOW shall not exceed the total fees paid or payable under the current active phase. Neither party shall be liable for indirect, incidental, consequential, special, or punitive damages, including lost profits or loss of goodwill, even if advised of the possibility of such damages.
Exceptions. The foregoing limitations and exclusions do not apply to: (a) a party's indemnification obligations under Section 7.8; (b) breach of confidentiality obligations under Section 7.2; (c) infringement, misappropriation, or unauthorized use of intellectual property rights, including breach of Section 2.1 or Section 7.1; (d) gross negligence, fraud, or willful misconduct; or (e) Funder's obligation to pay fees that have become due under this SOW or any executed amendment.
7.8 Indemnification
Funder's Indemnification of Developer. Funder shall indemnify, defend, and hold harmless Developer and its members, officers, employees, and agents from and against any and all third-party claims, demands, suits, proceedings, losses, damages, liabilities, costs, and expenses — including reasonable attorneys' fees and all court costs — arising out of or related to:
- The application and its content, design, features, functionality, and intellectual property
- Any claim that work product created under this SOW infringes, misappropriates, or violates any third-party intellectual property rights
- Funder's breach of this SOW
- Funder's gross negligence or willful misconduct
This obligation reflects the fundamental structure of the arrangement: Funder owns all intellectual property in the application and has approved all substantive product decisions. Developer publishes on Funder's behalf and should not bear legal exposure for claims arising from IP that Funder owns.
Developer's Indemnification of Funder. Developer shall indemnify, defend, and hold harmless Funder and its officers, employees, and agents from and against any and all third-party claims, demands, suits, proceedings, losses, damages, liabilities, costs, and expenses — including reasonable attorneys' fees and court costs — arising out of or related to:
- Developer's gross negligence or willful misconduct in performing its obligations under this SOW
- Developer's breach of this SOW
Procedure. The party seeking indemnification shall promptly notify the other party in writing of any claim and give the other party sole control over the defense and settlement, provided that the indemnifying party shall not settle any claim in a manner that imposes obligations or unreimbursed liability on the indemnified party without prior written consent.
7.9 Governing Law
This SOW shall be governed by and construed in accordance with the laws of the State of Vermont, without regard to its conflict-of-laws principles. Any disputes arising under this SOW shall be resolved in the state or federal courts located in Chittenden County, Vermont, and both parties consent to the exclusive jurisdiction of those courts.
7.10 Force Majeure
Neither party shall be liable for failure or delay in performance caused by circumstances beyond its reasonable control, including but not limited to acts of God, natural disasters, war, terrorism, pandemic, government action, labor disputes, or failure of essential third-party services (including Apple App Store review delays). The affected party shall notify the other promptly and resume performance as soon as practicable. If a force majeure event continues beyond sixty (60) days, either party may terminate the current phase under Section 7.5 terms.
7.11 Feedback
Suggestions, comments, ideas, recommendations, feature requests, or other feedback provided by either party regarding the application or deliverables ("Feedback") may be incorporated into the work product at Developer's discretion as a collaborative product decision under Section 3.2. All incorporated Feedback becomes part of the work product owned by Funder under Section 2.1.
7.12 Late Payment and Work Suspension
If Funder fails to pay any undisputed amount when due under this SOW, Developer may: (a) charge interest at 1.5% per month (or the maximum rate permitted by applicable law, whichever is lower); (b) recover reasonable costs of collection, including attorneys' fees; and (c) if payment remains past due for more than ten (10) days after written notice, suspend work until all past-due amounts are paid in full. Any milestone deadlines affected by such suspension shall be extended by the duration of the suspension.
7.13 Equitable Relief
Each party acknowledges that a breach or threatened breach of Section 2.1 (Intellectual Property Ownership), Section 7.2 (Confidentiality), or Section 2.4 (Funder Anonymity) would cause the non-breaching party irreparable harm for which monetary damages would be inadequate. The non-breaching party shall be entitled to seek injunctive relief, specific performance, and other equitable remedies without the requirement of posting bond or proving actual damages.
7.14 Independent Contractor
Developer is engaged as an independent contractor. Nothing in this SOW shall be construed to create an employment, agency, partnership, joint venture, or fiduciary relationship between the parties. Developer may engage subcontractors (including illustrators, voiceover artists, and contract engineers) to perform any portion of the work, provided Developer remains responsible for their performance, ensures they are bound by confidentiality obligations no less protective than those in Section 7.2, and secures appropriate IP assignments from subcontractors consistent with Section 2.1.
7.15 Assignment
Neither party may assign this SOW or any rights or obligations under it without the prior written consent of the other party, except that either party may assign this SOW without consent to a successor in connection with a merger, acquisition, reorganization, or sale of substantially all of its assets, provided written notice is given to the other party. Any attempted assignment in violation of this Section is null and void.
7.16 Survival
The following Sections survive expiration or termination of this SOW: 2.1 (Intellectual Property Ownership), 2.2 (Publication License, to the extent a Publication License Agreement has been executed), 2.4 (Funder Anonymity), 7.2 (Confidentiality), 7.3 (Non-Affiliation and Brand Identity), 7.4 (Phase Transitions and Exit) and 7.5 (Termination Mid-Phase) each to the extent of payment and delivery obligations for accepted work, 7.7 (Limitation of Liability), 7.8 (Indemnification), 7.9 (Governing Law), 7.11 (Feedback), 7.12 (Late Payment and Work Suspension) to the extent of unpaid amounts, 7.13 (Equitable Relief), 7.14 (Independent Contractor), 7.15 (Assignment), and 7.17 (Entire Agreement).
7.17 Entire Agreement
This SOW, together with any executed amendments, Feature Addendums, and the Publication License Agreement referenced in Section 2.2, constitutes the entire agreement between the parties regarding its subject matter and supersedes all prior discussions, proposals, and understandings. Any modification must be in writing and signed by both parties.
Section 8
Acceptance
By signing below, both parties agree to the terms outlined in this Statement of Work. This agreement defines four phases and six milestones (M1–M6). It covers Phases 1 and 2 (M1–M3) in full. Phase 3 (M4–M5: Full App + Launch) is governed by amendment after Phase 2. Phase 4 (M6: Innovation Layers) is governed by Feature Addendums executed under this SOW's framework.
Developer
Name
Title
CompanyAny Funded Need
Date
Signature
Funder
Name
Title
CompanyAbleNet, Inc.
Date
Signature