# Amsterdam Modern — Website & Platform Modernization ## Development Proposal **Prepared for:** Amsterdam Modern **Prepared by:** Artcode Inc. **Date:** October 2026 **Engagement type:** Fixed-price, milestone-based **Total:** $50,250 USD — 670 hours at $75/hour --- ## 1. Executive Summary Amsterdam Modern's Rails platform has run the business for over a decade. In this engagement, Artcode Inc. rebuilds it on a modern, modular foundation — a public website, a staff admin application, and a shared API — while preserving the business logic and workflows that already work. This proposal covers **the complete feature set documented in the Modernization Brief's Backend Requirements and Customer-Facing Requirements**, plus full migration of the existing catalog from the legacy SQL database. Three things make this project unusually well-positioned: 1. **Requirements risk is already retired.** The prototype is not a wireframe — the current customer-facing direction (`e2`) and the staff admin together run to roughly **17,900 lines of working interaction design across 29 pages**, with functioning hold/sale event models, editing locks, and tag systems. Nearly every "what did you actually mean by that?" question has already been answered and demonstrated. That is worth substantially more than a typical discovery phase. (Throughout this proposal, "the prototype" means this one. "Prototype II", the separate warehouse-readiness sandbox, is excluded in Section 8.) 2. **Design is handled separately.** The prototype is itself the design deliverable; visual specifics such as type, color, and spacing are taken directly from it. This proposal covers development only; no design hours are included. 3. **One senior developer, end to end.** Artcode Inc. delivers the engagement through a single senior developer: no coordination overhead, no handoffs between specialists, consistent architectural judgment across the whole stack. **Three efficiency decisions are already built into this estimate.** First, the staff-facing admin runs on a neutral utility-based visual system rather than the brand identity, removing bespoke design implementation across seven admin surfaces. Second, Amazon ECS Express Mode replaces manual container orchestration — a single API call provisions the Fargate service, load balancer, and networking, removing hand-wired VPC, load-balancer, and task-definition setup. Third, existing, production-tested image-processing code is reused rather than rebuilt. Without these, the same scope would cost materially more. --- ## 2. Understanding of the Project This is explicitly **not a rip-and-replace**. The goal is to preserve capabilities that work, establish a cleaner architecture underneath them, and make future improvement incremental rather than another rebuild. A prior evaluation of Shopify concluded that Amsterdam Modern's workflows exceed what off-the-shelf commerce supports. That conclusion holds, and this architecture is shaped by it: the business runs on inquiry and conversation, not checkout; on multi-unit partial sales, concurrent holds for different reasons, and staff-curated private collections. Those are not standard commerce primitives, and they are the reason a custom platform is justified. **Who this is being built for:** | User | Scale | Primary need | |---|---|---| | Internal staff | Under 20 | Fast catalog work — tag, filter, bulk-edit, triage, track holds and sales | | Trade customers & collectors | Public | Find pieces, save them, ask about them | | Private clients | Invited | Receive curated, link-shared collections without an account | --- ## 3. Scope of Work *Grouped by delivery area*: ### 3.1 Data Model & Core Platform - Full relational schema: products, specs, packages, images, tags, entities, events, users - **Dims / Specs** — locked Width/Depth/Height/Weight, plus reorderable optional specs from an extensible label list - **Packing** — repeatable per-box child records with dimensions, weight, instructions - **Status model** — Draft / Available / Hold / Sold, single-select, Draft as the creation default - **Hold events** — multiple concurrent holds per product, each with quantity, single-select reason, optional entity link, independent release, convert-to-sale. Multiple "Additional Hold" events (a waiting list behind the primary hold) can queue on the same product, each showing a computed queue position (1st in line, 2nd in line, etc.) - **Sale events** — independent per-transaction records, immutable, reversal by linked entry, running quantity ledger; schema leaves room for a future QuickBooks sync - **Quantity enforcement** — committed quantity checked against total before any new hold or sale - SKU uniqueness enforcement, Price Notes, Live Date, Sold As, 1stDibs panel - **Wishlist entries carry an `archived` flag**, distinct from a live item's hold state, so a piece saved from the Archive stays distinguishable from one saved while still available — the field a future notify-on-similar-arrival feature keys off - **Every AI classification records the model and version that produced it.** Cheap to store now and expensive to retrofit; it is what later makes "re-check the oldest, weakest classifications first" possible rather than re-crawling the catalog evenly. The scheduled re-crawl itself is excluded (Section 8) ### 3.2 Staff Administration - Multi-user authentication, flat permissions structure with simple admin/staff role distinction (admins can manage user roster and see purchase cost) - **Audit trail** — system-wide field-level change capture with a per-product History view - **Editing locks** — enforced at the *product record* level across every save surface (Product Editor, Inventory inline tagging, bulk actions), with timeout expiry and admin force-release - **Inventory** — free-text multi-field search, status filters, sort, pagination, grid/list views, Show My Items, CSV export respecting active filters - **Bulk actions** — multi-select with bulk tag apply/remove and bulk status change, including the two-step Hold reason picker - **Product Editor** — all panels, image gallery with ordering and key-photo selection, merged Activity timeline - **Provenance** — Designers, Producers, Countries; alias, merge, and shared-alias detection for Designers and Producers, searchable/sortable table with side-panel editing. Countries are a flat list; historical name variants are resolved during data migration. Designer entities carry an optional years/dates field (e.g. "Dutch, 1922–2019"), surfaced on the public Designers directory - **Tag Switchboard** — Internal Operations, Customer-Facing, Clients & Collabs, read-only Status and Data Health areas, with deep-links into filtered Inventory - **Client / Colab entities** — reclassifiable type, public/private toggle, private collection links - **Archive Review Queue** — three-state triage, quick-edit, bulk publish/exclude, always-reachable undo - **Site Content** — featured sections, homepage banner, category tile images, per-section heroes, site settings, and downloadable-forms management (Memo/Rental agreement PDFs — view current file, replace) - **Pages** — About, Contact, Policies with rich-text editing - **Users** — staff roster tied to the Peeps vocabulary, with role, active state, and real login - **Customer Accounts** — admin roster with free-text search, admin-initiated password reset and email change, and per-customer wishlist visibility - **Sale pricing** — `originalPrice` alongside `price`, driving strikethrough display wherever a product appears - **Sale Groups** — named, bulk-applied discounts across selected products, reversible by snapshot replay rather than blind reset, protected against double-discounting, with each sale generating its own public landing page - **Staff wishlist visibility** — three linked views over one dataset: what a given customer wants, who wants a given product, and an aggregate sortable demand signal in Inventory - **Save / Save & Continue** with dirty-state tracking and unsaved-changes warnings - **Analytics dashboard** — a small set of key PostHog metrics (product views, search terms, Wishlist activity) surfaced directly in admin so staff don't need to leave the tool for day-to-day checks; full exploration remains in PostHog itself - **Responsive layout** — mobile slideout nav drawer, reflowing grids, and horizontally-scrollable tables below common tablet widths, so staff aren't locked to a desktop - Admin runs on a **separate visual system** from the public site (Section 4) ### 3.2a Pricing & Availability Rules - Price is **hidden on any hold**, full or partial, replaced by an inquiry prompt — protecting a designer's pricing discretion when a piece is specified for their own client - Partial holds display a real stock breakdown ("N in stock · M on hold") rather than collapsing to a bare "On Hold", on both listing cards and the product detail page - Where a piece is recorded as selling individually or as a set, the stock line says so ("2 in stock — sold individually"); left unset, it shows quantity alone and assumes nothing ### 3.3 Public Website - Server-rendered, mobile-first, **WCAG 2.1 Level AA** - Homepage — flex hero, category grid, stacked curated carousels wired to live section membership, More From The Floor - Category landing pages with refinement chips and live counts; Full Collection page - Product detail — gallery lightbox, share links, Producer/Designer/Country, specs, policies link - Designer and Producer profile pages, plus Brands and Designers directory grids - **Customer accounts** with server-backed Wishlist, notes, and shareable links, including guest-to-account merge on first login - **Inquire** flow from product page and Wishlist batch — a multi-intent chip picker (hold, memo, rental, shipping estimate, purchase request), each surfacing its own follow-up fields — emailing full details to staff and logging an Activity note on the product - Private client collection pages - **Brands, By Style, By Room, Collections, and curated Section landing pages**, plus an on-brand 404 - Header navigation consolidated into a single Shop dropdown - Policies page, cookie consent, Flodesk newsletter (a footer link out to Amsterdam Modern's hosted signup page) ### 3.4 Search & AI Classification - Postgres full-text search with a synonym layer and quoted-phrase exact-match support (e.g. "brutalist oak") - **Multimodal classification** — AI reasons over product imagery, title, and description together to assign Category and Subcategory tags against the authoritative taxonomy, rather than matching words in a product name - **AI Knowledge Base** — an admin-editable brand and classification ruleset that conditions every classification run - **Squashing and locking** — a rejected AI suggestion is remembered and never re-proposed; a reviewed product can be locked so a later crawl cannot undo a person's judgment - **Classification Coverage** — an Inventory panel surfacing unclassified products and counted candidate terms for Style, Room, Materials, and Functions - AI-assigned tags are visually distinguished from manually-assigned ones, and always staff-overridable - Header type-ahead with related-match flagging - Category refinement chips generated from live inventory, with overflow handling ### 3.5 Cross-Cutting - **SEO** — clean URLs, editable meta, schema.org Product structured data, auto-updating sitemap, canonicals, robots control - **Accessibility** — semantic markup, keyboard navigation, contrast, focus management, form labels, audited before launch - **Analytics** — product views, search terms, timestamped Wishlist events, staff IP exclusion reading `CF-Connecting-IP`. **PostHog**, per the brief's own recommendation - **Error handling and failure states.** The brief is explicit that these are unspecified, and that the prototype's demo-scale patterns hide failure modes a real backend must surface. Every save reports failure visibly rather than swallowing it; a failed or corrupt load is distinguished from genuinely absent data rather than silently resetting to defaults; a blocked form submission always says why; sessions revalidate so deactivating an account takes effect while that person is still working; and network timeouts, retries and 5xx responses are handled as a deliberate layer rather than assumed to come free with an API - **Backups and disaster recovery.** Automated daily database backups with a stated retention window, point-in-time recovery within it, and a restore procedure that has been rehearsed and documented rather than assumed — the brief confirms this as necessary with the specifics left to the developer - **Privacy compliance is CCPA-shaped, not GDPR-shaped**, the business being LA-based: cookie notice, privacy statement on the Policies page, and the disclosure and opt-out affordances CCPA expects. Legal review of the policy copy itself remains the client's, as does confirming which thresholds apply --- ## 4. Technical Architecture ### 4.1 Stack | Layer | Technology | Rationale | |---|---|---| | Language | **TypeScript** throughout | One language across three apps; shared types eliminate a whole class of integration bug | | Public site | **React Router v7** (framework mode) | SSR-first, mature Remix lineage, the most-trodden SEO path in React | | Admin | **React + TanStack Router + TanStack Query** (Vite SPA) | Best-in-class typed search params and data caching for a filter-dense internal tool | | API | **Fastify** + Zod | Lightweight, fast, schema-first; generates a typed client both frontends consume | | Database | **PostgreSQL** + Drizzle | Relational integrity for events, entities, and audit; SQL-proximate query building for faceted search and indexed full-text search, with schema and queries typed in TypeScript | | Monorepo | **pnpm workspaces** | Shared TypeScript types and validation schemas across all three apps without publishing to a registry; one CI pipeline. Task caching (Turborepo) can be layered on later if build times warrant it — it is additive, not a foundational choice | | Admin styling | **Tailwind** (zinc palette, Inter, brand accent) | The admin deliberately runs a different visual system from the public site — clarity and speed for staff over brand expression — which also decouples the admin build from ongoing design refinement | | Hosting | **Amazon ECS Express Mode**, client-owned account | Single-call containerized deploys — Fargate service, load balancer, and networking auto-provisioned, no manual VPC/ALB/task-definition wiring; the public site and API share one Application Load Balancer to keep the added ALB cost small. Client owns the account outright so another developer can take over | | Media | **S3 + CloudFront**, `sharp` pipeline | CDN in front of existing storage. Uploads generate thumbnail, medium, and large variants from one source image, defaulting to 3:2 with graceful letterboxing for odd ratios | | Auth | **Better Auth** | Two separate auth systems (staff and customer) per the brief, with user records living in the project's own Postgres so audit, locks, and wishlists can reference them directly | | Transactional email | **Resend** (AWS SES alternative) | Password reset, verification, and staff notification of customer inquiries | ### 4.2 Structure ``` amsterdam-modern/ ├── apps/ │ ├── web/ React Router v7 — public site, SSR │ ├── admin/ Vite + React + TanStack — staff SPA │ └── api/ Fastify + Drizzle — shared data layer └── packages/ ├── types/ Shared TypeScript definitions ├── schemas/ Zod validation, single source of truth ├── ui/ Shared components and design tokens └── config/ ESLint, TS, build configuration ``` ```mermaid graph TB V[Visitors] --> CF[Cloudflare DNS] S[Staff] --> CF CF --> WEB[Public Site
React Router v7 SSR
ECS Express Mode] CF --> ADM[Admin SPA
TanStack + Tailwind
S3 + CloudFront] WEB --> API[API Service
Fastify
ECS Express Mode] ADM --> API API --> DB[(PostgreSQL
RDS)] API --> S3[(S3 + CloudFront
Product Images)] API --> AI[Claude API
Batch Tagging] API --> EM[Resend
Transactional Email] API --> FD[Flodesk] ``` ### 4.3 Why This Shape **Why three services rather than one app.** The public site and the admin have genuinely opposite requirements. The public site needs server rendering, minimal JavaScript, and crawlability. The admin needs rich client-side state, aggressive caching, and zero SEO. Forcing both into one framework means compromising one of them. A shared API also means a future mobile app, a 1stDibs connector, or a QuickBooks sync plugs into an existing contract rather than requiring a rebuild — which is precisely the "modular, API-driven, adapt as needs evolve" goal in Section 2 of the brief. **Why React Router v7 for the public site.** The brief's Section 4.16 flags SSR as an architecture decision that must be made from the start, because retrofitting means restructuring URLs and breaking rankings. React Router v7 framework mode is the most mature SSR option in the React ecosystem — the Remix lineage dates to 2021 — and it ships less JavaScript on first load than SPA alternatives. On the one surface where a mistake is invisible until search rankings drop, maturity is the right trade. **Why TanStack for the admin.** The brief requires an unusual amount of URL-encoded state: Tag Switchboard deep-links into pre-filtered Inventory (brief Section 4.20), plus search, status filters, Hide Sold, sort, pagination, and Show My Items — all of which must survive a refresh and be shareable between staff. TanStack Router's typed, validated search params are the best tool in React for exactly this, and TanStack Query's cache model fits an admin where the same product data appears across many views. **Why Drizzle rather than a heavier ORM.** This platform is not CRUD-shaped. Faceted refinement chips whose counts update as filters combine, full-text search across seven product fields at once, per-dimension data-health checks, and wishlist trend analytics over time windows are all dynamic, aggregate-heavy queries. Abstraction-first ORMs handle the simple 80% well and then force a drop into untyped raw SQL for exactly the queries that matter most here — including full-text search, where the leading alternative cannot use database indexes at all. Drizzle stays close to SQL while keeping schema and results typed end to end, so the hard queries are type-checked rather than stringly-typed. **Why Better Auth.** Section 4.1 of the brief requires staff accounts and customer accounts to be **architecturally separate systems**, and both need to be referenced constantly from application data: the audit trail attributes every field change to a staff user, editing locks record who holds them, and on the customer side the Wishlist, its timestamped event history, and the Client-entity linkage in brief Section 4.18 all point at an account. --- ## 5. Data Migration Approach Migration is performed by the developer and is included in the quoted hours. It is treated as a real workstream rather than a pre-launch task, because Section 9 of the brief is correct that schema changes strand data continuously. **Approach — analysis first, then scripted transformation:** 1. **Legacy database profiling.** Obtain a dump of the production database and analyze actual state rather than assumed state: how many duplicate SKUs, how many country variants, how many products with a subcategory but no parent, how many records thin enough to warrant Archive Review. This produces a written gap analysis with counts. 2. **Migration scripts, written against real data.** Idempotent and re-runnable, so migration can be rehearsed repeatedly against staging before the production cutover. 3. **Known transformations:** | Issue | Handling | |---|---| | Duplicate SKUs | Identified and reported; deterministic re-coding rule agreed with staff, then applied by script | | Country variants ("USA" / "United States", "W. Germany" / "w. Germany") | Normalization map built from actual observed values, applied to canonical Country entities | | Designer/Producer name variants | Mapped as aliases to canonical entities rather than rewriting underlying data | | Free-text measurements | Best-effort parse into structured Width/Depth/Height (+ Seat Height / Arm Height); anything ambiguous flagged for review rather than guessed | | ALL-CAPS titles | Scripted title-casing | | Title-cased descriptions | Proposed rewrite generated for human comparison, never blind-applied — protected terms drawn from the live Provenance list | | Flat category checkboxes | Split by purpose into internal tags, customer-facing tags, and curated sections | | Legacy flat tags colliding with group names | Full audit across all groups; catch-all leaf value added per affected group | | Subcategory set without parent | Auto-set parent during migration, **plus** a defensive query-time union so future records can't reproduce the gap | | Free-text hold reasons | Split into independent hold events; original text preserved as an event note | | Thin / incomplete records | Migrated as-is, flagged private, routed into Archive Review rather than manually backfilled | | Aged inventory | Bulk-routed to Archive Review Pending using a cutoff date supplied by Ellen and Ivan | | Existing product imagery | Bulk pass generating thumbnail/medium/large variants for every image already in S3, using the same pipeline that handles new uploads | 4. **Verification before cutover.** Per-dimension uncategorized checks across Category, Style, and Section separately; category counts confirmed to include subcategory-only products; SKU uniqueness confirmed complete before the constraint is enforced. **What is needed from Amsterdam Modern:** a database dump early in the engagement, and business judgment on a small number of decisions a script cannot make — the archive cutoff date, the SKU re-coding rule, and confirmation of ambiguous name merges. The work is the developer's; the business decisions are the client's. --- ## 6. Timeline & Work Packages **Availability:** 30 hours per week. **Duration:** approximately 26 calendar weeks — **about 6 months** including holidays. | # | Work package | Hours | Weeks | |---|---|---:|---| | 1 | Foundations, data model & legacy database audit | 65 | 3 | | 2 | Staff admin — core workflows (Inventory, Product Editor, editing locks, audit trail, hold/sale events, bulk actions) | 140 | 5 | | 3 | Staff admin — supporting tools (Provenance, Tag Switchboard, Archive Review, Site Content/Pages, Users, Customer Accounts, Sale Groups) | 110 | 4 | | 4 | Data migration execution (scripts, staging rehearsal, production cutover) | 70 | 3 | | 5 | Public website — browsing & navigation (homepage, category pages, Full Collection, product detail, Designer/Producer/Brands directories) | 90 | 3 | | 6 | Public website — accounts, Wishlist, Inquire & private collections | 75 | 3 | | 7 | Search & AI classification (Postgres full-text search, multimodal classification, AI Knowledge Base, Classification Coverage) | 65 | 3 | | 8 | Cross-cutting, QA & launch (SEO, accessibility audit, analytics, backups/DR, staging/production deploy, documentation, handoff) | 55 | 2 | | | **Total** | **670** | **26** | ### Sequencing rationale The admin is built before the public site deliberately. It lets staff start testing workflows in the real system early, and it front-loads the work least dependent on the final design. Data migration (Work Package 4) follows the admin core specifically so the people who know the data best can validate migrated records in the real tool as they land, not after the fact. --- ## 7. Cost & Payment Schedule **Total: $50,250 USD** — 670 hours at $75/hour, fixed price. This lands close to Amsterdam Modern's proposed $50,000 budget — achievable specifically because of the efficiency decisions named in Section 1 and the requirements risk the prototype has already retired. It carries no contingency margin; see Section 10. | Milestone | Deliverable | Hours | Payment | |---|---|---:|---:| | 1 | Foundations, data model & migration audit (WP1) | 65 | $4,875 | | 2 | Staff admin core workflows live (WP2) | 140 | $10,500 | | 3 | Staff admin complete & catalog migrated (WP3–4) | 180 | $13,500 | | 4 | Public website — browsing, accounts & Inquire live (WP5–6) | 165 | $12,375 | | 5 | AI classification, search, launch & handoff (WP7–8) | 120 | $9,000 | | | **Total** | **670** | **$50,250** | Artcode Inc. invoices a $2,500 deposit on signing, credited against Milestone 1; each milestone is then invoiced on completion, net 15. **Not included in this figure — third-party costs billed directly to Amsterdam Modern by each provider:** - **AWS hosting** — estimated $80–150/month at this scale - **AI API usage (e.g. Claude) for classification** — a one-time pass over the existing catalog, then a marginal per-product cost. Because classification reasons over product photography, not just text, expect roughly $3,000–4,000 for the initial pass depending on final catalog size, then a negligible ongoing figure. A costed sample run over a few hundred products is scheduled in Work Package 7 before the full pass is authorized, so this is a measured number rather than an open-ended one - **Transactional email via Resend** — the free tier covers roughly 3,000 messages/month, which should exceed this volume (AWS SES is an alternative at about $0.10 per 1,000) - **Existing services** — Flodesk, domain registration, and Cloudflare Authentication itself carries no license or per-user cost. --- ## 8. Explicit Exclusions The following are **not** included. Each is documented in the brief as deferred or unscoped, and each can be quoted separately later. **Deferred features:** - Cart and checkout - QuickBooks integration - Online memo/rental agreement form with credit-card authorization (carries PCI-DSS obligations). Memo and rental are covered instead by downloadable PDF agreements linked from the inquiry form - Automated 1stDibs sync (dependent on 1stDibs offering a seller API, which is unconfirmed) - Instagram Shopping (dependent on Meta commerce approval) - Hold timers and reminder emails - Canned condition-description templates - Calculated shipping cost - AI-assisted listing copy generation - Product video - Euro cost-price tracking with permission gating - Price-range filtering - Press and Employees pages - Rental-only product flag - SMS notification and phone opt-in - Client-entity-to-customer-Wishlist linkage - Product description style/spell-check - "Related pieces" / "you might also like" recommendations on the product detail page - Automated Style/Room AI crawling (AI classification is scoped to Category/Subcategory only) - A confidence-scored AI review queue beyond the squash-based rejection already in scope - A "Most Viewed" sort or indicator on customer-facing cards **Out of scope by nature:** Prototype II and the Containers intake workflow · all visual design and design system authoring (handled separately via the prototype) · copywriting and content entry · product photography · SEO content strategy and link building · ongoing hosting fees · post-launch maintenance, support, and feature work (available separately) · third-party service subscriptions. **Worth naming specifically:** the existing prototype code is used as a functional and UX reference only. None of it carries into production — it is a set of standalone pages with no shared components, no backend, no build system, and no real images. Rebuilding is assumed throughout this estimate, not treated as an unexpected cost. --- ## 9. Assumptions & Client Responsibilities **Assumptions:** 1. A legacy database dump is provided within two weeks of kickoff. Migration estimates are best-effort until the audit in Work Package 1 completes. 2. The prototype serves as the design deliverable. No separate design files or component system are expected; visual details are taken directly from it. Any further design refinements are made to the prototype itself, and arrive before the corresponding work package begins (public website: Work Packages 5–6). 3. AWS account access with sufficient permissions is provided at kickoff. 4. Feedback on delivered milestones returns within five business days. 5. Browser support targets current evergreen browsers plus iOS Safari and Chrome Android — no IE11 or legacy Edge. 6. Two environments: staging and production. **Client responsibilities:** - Provide database access and AWS credentials - Supply the archive cutoff date and SKU re-coding rule - Make judgment calls on ambiguous entity merges surfaced by the audit - Review and accept milestones within five business days - Provide content, copy, and photography - Secure licensing/attribution for any third-party imagery used on the site (e.g. designer photography sourced from Wikimedia Commons or similar) - Keep the prototype current as the design reference --- ## 10. Risks & Mitigation **1. No contingency allowance — the primary risk.** The quoted hours cover the documented scope with no float. A project of this size and duration would normally carry 15–20% for the unknowns that always surface. **2. Legacy data worse than expected.** Prototype sample data is clean; a decade of production data will not be. *Mitigation:* the audit is scheduled first. **3. Scope creep from a living brief.** The brief's Section 9 establishes a standing practice of revisiting decisions as design evolves — good discipline, but on a fixed-price engagement each revisit is a potential change. *Mitigation:* Section 11. --- ## 11. Change Control Scope is defined by the Modernization Brief's Backend Requirements and Customer-Facing Requirements as of this proposal's date (see Section 1), as itemized in Section 3. Requests outside that boundary are estimated by Artcode Inc. before any work begins, and proceed only on Amsterdam Modern's approval. **Approved changes are billed at $100/hour**. Clarifications of existing requirements are not changes. New capabilities, reversals of decisions already implemented, and additional pages or workflows are. --- ## 12. Deliverables & Handoff **Software:** complete monorepo source in Amsterdam Modern's Git organization · production and staging environments running in Amsterdam Modern's AWS account · CI/CD pipeline · migration scripts, re-runnable and documented. **Documentation:** architecture overview and system diagram · database schema documentation · API reference generated from schemas · deployment and rollback runbook · environment and secrets configuration guide · migration procedure with verification checklist · staff user guide for the admin application. **Handoff:** two working sessions — one technical walkthrough for any future developer, one training session for staff. Thirty days of post-launch bug support for defects in delivered functionality is included; new work is quoted separately. **Ownership:** On final payment, Artcode Inc. assigns to Amsterdam Modern all rights in the source code and documentation produced under this engagement. Data and infrastructure belong to Amsterdam Modern throughout. No ongoing dependency on Artcode Inc. for hosting, deployment, or access. --- ## 13. Next Steps 1. Review this proposal and confirm scope, budget, and timeline 2. Sign and set a kickoff date 3. Provide the legacy database dump and AWS access 4. Begin Work Package 1 --- *This proposal is valid for 30 days from the date above.*