# Project specification appendix Draft templates only. Professional legal review under applicable Israeli law is required before binding use. These documents are not legally approved. Draft version: 2026-11-10 / draft-4 A reusable specification structure for defining a project before development, including testable delivery and acceptance criteria. ## 1. Package scope and equal quality Starter: One landing page, ₪700; Business: Up to 5 pages, ₪1,200; Advanced: Up to 10 pages, ₪3,000; Custom: By quotation, individually quoted. Every BTNXIO website is custom-designed for the brand, with careful user experience, responsive layouts for computers, tablets and phones, professional development and consistent testing. Packages differ in page count and agreed scope, not design quality. Colors, fonts, structure, components and content are tailored to the project. Animation, effects and interactions are available in every package where appropriate to the specification; unusually complex motion and functionality require agreed pricing. BTNXIO proposes the initial plan and design direction. Together we refine the structure, content and details before final approval, within the agreed scope and chosen working method. This does not provide unlimited development or additional deliverables. Actual pages and deliverables are listed within the selected package limit; additional pages or complex functionality require a separate quotation and prior approval. ## 2. Development-stage working method Three alternatives, available in every package at the same design and development quality. Choose one; these are not three mandatory stages. The method does not automatically change the package price. A — Flexible development: Request adjustments throughout development without a fixed number of rounds, within the agreed specification and scope. Significant changes or additions outside that scope are reviewed and separately quoted, with customer approval before any additional charge. B — Three coordinated revision rounds: Three coordinated adjustment rounds are available before launch or final handover. Further requests are assessed according to their scope; they do not automatically incur a charge. Any additional paid work requires a quotation and approval in advance. C — Design approval before development: Approve the proposed design direction and structure first. After development begins, focused adjustments remain possible within the specification. Material changes are discussed separately, including any effect on scope, cost or milestones, before approval. Record the selected method in the quotation or specification; it can be changed by mutual agreement. In-scope adjustments refine the approved pages, structure, content and components without adding new deliverables. Additional work requires a quotation and approval before charging. Defects attributable to BTNXIO do not count as a revision round. Final publication or handover always requires customer approval. These pre-handover arrangements do not use the post-handover annual minor-change round. ## 3. Purpose, pages and content structure The appendix defines the project objective and intended audiences, then records each page, route, section and primary action. Each item has a content owner, language coverage and acceptance outcome. Navigation hierarchy, legal/contact links, empty states and error/not-found behavior are identified. The Starter one-page limit, Business maximum of 5 pages or Advanced maximum of 10 pages applies; Custom page count is recorded individually. The actual sitemap and content responsibilities are listed within that scope, without unlimited content entry. ## 4. Features, forms and interactions For each feature the specification describes inputs, required/optional fields, validation, state changes, outputs, error handling and responsible service. Forms identify recipients, consent/disclosure needs, spam controls and the distinction between accepted processing and completed delivery. Search, filtering, accounts, commerce, bookings and AI appear only if expressly selected. Test modes must be clearly identified and must not impersonate live integrations. ## 5. Design, languages and responsive behavior The agreed design direction, brand assets, components and review version are recorded. Hebrew and English or other selected languages have content responsibility, RTL/LTR direction, appropriate typography and mixed-direction handling. The project defines representative mobile/tablet/desktop widths and browser targets, touch behavior and reduced-motion requirements. BTNXIO’s eight showcase experiences do not mean that every customer project includes eight complete designs. ## 6. Integrations and infrastructure Each chosen provider has an identified account holder, required permissions, allowed data flows, commercial prerequisites, fees and test/live activation conditions. Client-side public settings are separated from private server credentials. Hosting/deployment, custom domain, HTTPS and access requirements are recorded for the chosen model. No API availability, payment approval or supplier subscription is assumed. ## 7. Content, accessibility and search scope The customer supplies or approves lawful content, media, translations and project-specific legal notices according to the responsibility inventory. Accessibility tasks and testing, including keyboard/forms, headings, text alternatives and any specialist audit, are expressly scoped; legal certification is not inferred. SEO tasks can include semantic markup, metadata, sitemap, robots rules, internal links and image work, without a ranking or indexing guarantee. ## 8. Acceptance tests and defect classification The test inventory identifies actions, environments, expected outcomes and evidence for the agreed pages/features, responsive/RTL behavior, links, forms, failures and delivery. Attributable defects are distinguished from omitted customer content, third-party restrictions and new requirements. Critical open issues and any accepted limitations are recorded explicitly; a passing build alone is not acceptance. No performance score, full browser coverage or legal compliance is asserted without a corresponding test. ## 9. Delivery requirements and change control The appendix lists source/build/design files, export formats, documentation, account handover and any agreed training. It identifies excluded infrastructure and licences and the conditions for publication or delivery to customer hosting. Proposed changes are logged with their scope, cost, dependency and approval impact; only an expressly accepted revision changes the specification. Customer launch approval is separate from design approval and from the final payment record. ## Individual project schedule These particulars form part of the individual approved documents. An empty schedule is not an order, signature or acceptance. No information is submitted or saved through this template. - Selected A/B/C method, development adjustments reviewed and separate post-handover annual round: ________________ - Project and quotation identifiers; approved specification version: ________________ - Page/feature inventory, languages and content owner for each item: ________________ - Supported environments, integrations and acceptance test inventory: ________________ - Delivery formats, dependencies, exclusions and approvals: ________________ ## Related drafts - [Quotation and work order](en-quotation-work-order.md) - [Service terms and development agreement](en-service-agreement.md) - [Website delivery and launch approval](en-launch-approval.md)