Investment & technical due diligence · confidential · 28 July 2026

Conditional Go.

Proceed to a controlled pilot build. The problem is credible, the product is coherent, and the core architecture is sound. Investment remains conditional on proving connector access, customer willingness to pay, data quality, and a disciplined AI-assisted engineering process. This report is not legal, accounting, or investment advice.

Source design
AMR Platform Concept & System Design
Scope
Pre-build product, architecture & execution review
Decision
CONDITIONAL GO
Overall score
7.6 / 10

Executive decision

The scorecard

The review treats the AMR design as the authoritative specification, and incorporates the stated delivery assumption: AI coding agents produce most implementation work while a senior engineer owns architecture, reviews critical changes, and controls production releases.

Problem severity
8.5 / 10
Strong need in a low-margin, fragmented sector.
Product coherence
9.0 / 10
Metrics, coaching, guest intelligence and huddles form a coherent operating loop.
Competitive differentiation
6.5 / 10
Real, but the design understates overlap with Tenzo, SevenRooms, Nory, Avero.
Architecture
8.5 / 10
Sound deterministic core and tenancy model; several Phase 1 choices need simplification.
Privacy & security readiness
6.5 / 10
Good isolation intent; retention, deletion, device caching and AI-content controls incomplete.
AI-assisted build readiness
7.5 / 10
Well suited to agents — if the senior engineer is an active owner, not an occasional reviewer.
Commercial readiness
6.0 / 10
Promising pilot cohort; pricing, willingness to pay and integration access unproven.
Overall
7.6 / 10
Conditional Go.

Product & market

A credible problem, a loop worth keeping, a profile to narrow

New Zealand hospitality generated NZ$15.99 billion in sales in the year ended June 2025, but restaurant and cafe sales grew only 0.3% and average wage cost reached about 40% of revenue — a market where modest operating improvements matter materially.

The underlying customer problem is credibleStrength · retain

EvidenceNZ had 9,867 cafe and restaurant geographic units as at February 2025 — 18,243 including takeaway. Sector sales are large; cost pressure is severe.

AssessmentAMR addresses a measurable operating problem rather than manufacturing an AI use case. The strongest need is not more data — it's faster recognition of financially meaningful exceptions and clear actions.

RecommendationKeep profit improvement, management time saved, and guest return behaviour as the primary value measures. Do not market AMR as a general-purpose AI assistant.
The initial customer profile is too broadMedium

AssessmentA small cafe with limited reservations and a basic POS may produce little usable guest data and not support the subscription or onboarding cost. Premium owner-led restaurants have the data, margin opportunity and management cadence AMR requires.

RecommendationDefine the initial ICP as owner-led premium restaurants and groups of 1–5 venues: roughly NZ$1.5M+ annual venue revenue, a reservation platform, an integrated POS, stable management, and willingness to run a weekly operating rhythm. Treat the revenue threshold as a pilot hypothesis.
The product loop is the strongest part of the conceptStrength · retain

AssessmentGoverned metrics → weekly report → critical number → owner focuses → statused opportunities → pre-service stories → follow-up outcomes. A closed loop — observe, interpret, act, record, evaluate — is more defensible than a chatbot or dashboard because it becomes part of the operating cadence.

RecommendationMake the loop the product architecture and the marketing narrative. Every feature should improve data trust, select a better action, help the team execute, or measure the result.
The Monday report is a valid wedge — not proof of product-market fitMedium

AssessmentOwners often praise reports but stop opening them once novelty declines. Fit requires evidence that recommendations are accepted, assigned, discussed and revisited.

RecommendationPilot success must include behaviour: report open rate, opportunity acceptance and completion, repeat Ask AMR use, huddle usage, and at least one target metric that moved. Require paid continuation after the pilot.
Cross-tenant benchmarking is a potential advantage, not an early moatConditional

AssessmentA small dataset won't be statistically useful, and restaurant comparisons are sensitive to concept, price point, service model and region. Poorly normalised benchmarks can mislead customers. NZ privacy law limits retention and overseas disclosure; Australian rules require de-identification when data is no longer needed.

RecommendationDon't present benchmarking as an investable moat until there's enough opt-in data, stable metric definitions, minimum cohort thresholds and a documented de-identification assessment. The nearer-term moat is reliable local integrations plus an outcome-labelled operating dataset.

Competitive position

The claimed gap is overstated — the real wedge is narrower and stronger

Several competitors now make claims that overlap directly with AMR. The competitive section should be revised before it is shown to investors.

CompetitorVerified current positionImplication for AMR
TenzoAggregates restaurant data, automates reports, supports AI questions, recommendations, forecasting, scorecards, 90+ integrations — explicitly serves single sites and small chains."Tenzo merely shows what happened" is no longer defensible. Tenzo is the closest direct threat.
SevenRoomsGuest CRM, 100+ guest data points, AI notes, segmentation, POS-linked spend, marketing and service personalisation.Guest data and personalisation alone are not a moat. AMR must win on cross-stack neutrality, local integrations and management workflow.
NoryAI-led sales forecasting, labour, inventory and profitability — currently aimed at operators with two or more locations.AMR stays more relevant to single premium venues and guest/service workflows, but Nory owns a strong profitability narrative.
AveroAnalytics for independent restaurants and groups: revenue, labour, menu engineering, group comparisons.Not solely enterprise. AMR needs a sharper service-execution and guest-noticing distinction.
MarginEdgePublic pricing includes a US$350/month restaurant management tier; strong food-cost and back-office automation.The price ceiling for proven software is higher than AMR assumes — but buyers expect direct financial value.
The claimed market gap is overstatedHigh

AssessmentAn absolute category claim ("no incumbent combines guest intelligence, coaching and huddle execution") is difficult to prove and easy for an investor or competitor to rebut. It weakens credibility even where the underlying distinction is real.

RecommendationUse a narrow claim: AMR is designed for owner-led ANZ restaurants using fragmented local systems, and turns governed cross-system data into a weekly accountability loop and pre-service guest briefing. Validate the wording in customer interviews.
ANZ connector coverage can be a wedge — but access is not yet provenHigh

EvidenceNow Book It activates API keys through its support and partner process; public documentation does not establish that a new third party can obtain unrestricted access on demand.

AssessmentA connector roadmap based on presumed API access can fail for commercial, contractual or technical reasons. CSV exports reduce the dependency but add onboarding and schema-drift costs.

RecommendationBefore production development, obtain written confirmation of export formats, API availability, partner requirements, rate limits, fees, permitted data use and sandbox access for Now Book It, Bepoz, Loaded, Xero and Me&U. Treat each connector as a commercial partnership workstream, not just an engineering ticket.
The defensible position is workflow plus evidence — not the chatbotStrength · retain

EvidenceNatural-language analytics is becoming a standard capability; Tenzo already exposes AI access to restaurant data and released an MCP server beta in 2026.

AssessmentAsk AMR will be useful but is unlikely to remain differentiating. The harder-to-copy asset is a governed restaurant ontology, source mappings, service workflows, and labelled evidence showing which actions produced outcomes.

RecommendationKeep Ask AMR constrained and useful. Invest more heavily in the opportunity lifecycle, huddle adoption, outcome measurement, local connector quality and restaurant-specific metric definitions.

Technical architecture

The core is right. The edges need tightening.

Eleven findings. The deterministic core, the metric registry and the tenancy model are confirmed; privacy retention, prompt-injection defence and several Phase 1 ambitions require redesign or deferral.

Deterministic core with a generative shell is the correct architectureLow · retain

AssessmentComputing metrics, trends, segments and lifecycle rules in code — with the model only explaining and recommending — sharply limits arithmetic hallucination, supports auditability, reduces model cost and makes regression testing practical. Consistent with NIST guidance on generative-AI governance.

RecommendationRetain unchanged. Never let the language model become the source of metric definitions, identity decisions, financial calculations or authorisation rules.
The typed metric registry is appropriate for the pilotLow · retain

AssessmentStarting with an application-level registry and deferring a semantic-layer product achieves the important property — one tested definition per metric — without adding a platform dependency before product-market fit.

RecommendationRequire each metric to include owner, formula, grain, dimensions, inclusion/exclusion rules, source lineage, freshness, tests and version. Remove the exact "21% vs 98–100%" benchmark from investor material unless its methodology is independently reviewed — vendor figures are not neutral evidence.
Shared-schema Postgres with RLS is sound — only if operational controls are strictMedium

AssessmentRLS is a strong control, not a complete tenancy strategy: superusers and BYPASSRLS roles still bypass it, and a single privileged application connection, migration role or background worker can expose data.

RecommendationSeparate database roles for migrations, API reads/writes, workers and support. The application role must not own tables or hold BYPASSRLS. Automated cross-tenant tests for every table — including jobs, exports, search, backups and support tooling. All security-critical SQL reviewed manually.
The raw landing-zone policy conflicts with privacy retention dutiesHigh

AssessmentTokenisation reduces exposure but does not make all raw data non-personal — free-text notes, dates, booking context and linkage patterns may remain identifying. Crypto-shredding requires complete key coverage and doesn't address downstream copies, logs, AI outputs or exports. NZ Principle 9 and Australian APP 11 impose retention and destruction duties.

RecommendationReplace "forever" with a documented retention schedule: raw source files kept only as long as needed for reconciliation and replay (e.g. 90–180 days); normalised history retained under a stated purpose; free text removed or separately encrypted; a tested deletion workflow across raw, canonical, caches, AI outputs, exports and backups. Obtain privacy counsel before launch.
PII separation stays — per-guest cryptographic deletion is too complex for Phase 1Medium

AssessmentPer-guest key lifecycle, rotation, backup restoration, merge/split behaviour and deletion verification add substantial security-critical code. AI generation does not reduce the need for expert design and review.

RecommendationKeep stable surrogate guest IDs and a separate encrypted identifier store. Start with managed key management and tenant-scoped envelope encryption, short raw retention, strict access, audited deletion. Add per-guest crypto-shredding only after a threat model proves its benefit exceeds its complexity.
The guest identifier model should be normalisedMedium

AssessmentEmail/phone arrays and JSON source-ID maps are convenient initially but make uniqueness, history, confidence, consent status and identifier-level correction harder. Identity resolution is central IP and deserves an explicit model.

RecommendationCreate guest_identifier(tenant_id, guest_id, type, normalised_value, encrypted_value/token, source, verified_at, valid_from, valid_to, consent flags). Preserve source lineage for every link. Never use fuzzy names as unique identifiers.
Identity stability is well recognised — split handling is incompleteMedium

AssessmentErroneous merges are inevitable. Undoing them safely requires knowing which source facts and child records came from which original identities — re-pointing all children during a merge can lose that information.

RecommendationAdd identity_decision and identity_membership history with reversible provenance. Keep source facts attached to source identities; derive canonical membership. Require human approval for ambiguous merges and a tested split workflow before the huddle exposes guest notes.
Numeric grounding should be structural, not a post-generation text checkMedium

AssessmentString-matching numbers in model output is brittle: wrong labels, wrong periods, transposed values and unsupported arithmetic can pass; legitimate transformations get blocked until exceptions accumulate.

RecommendationReturn typed fact objects with fact IDs, units, periods and provenance. The model references fact IDs; application code renders the numbers. Derived calculations only through a deterministic calculation tool. Store the fact set with the answer.
Prompt injection and untrusted content are not sufficiently addressedHigh

AssessmentAMR ingests reviews, feedback emails, booking notes and dot notes, then exposes them to a model. A malicious or accidental instruction inside feedback can influence output if source text is treated as trusted. Risk increases when the same agent can query metrics, guest records or future write-back actions. (OWASP LLM Top 10.)

RecommendationTreat all external text as untrusted data: message-role separation, content boundaries, no tool instructions derived from source text. Keep Phase 1 read-only. Add adversarial tests, output schemas, per-tool authorisation, data-loss-prevention checks and model-provider retention controls.
The huddle offline mode needs a privacy designMedium

AssessmentOffline caching is operationally sensible, but guest names, celebrations, preferences and notes may remain on personal phones after a shift, after staff leave, or after access is revoked.

RecommendationCache the minimum required; encrypt local storage where supported; expire automatically after service; require device re-authentication; support remote session revocation; avoid sensitive free text; display a clear staff-use policy. No full guest profiles offline.
The platform baseline is slightly overbuilt for the first pilotMedium

AssessmentGood controls are necessary, but a small AI-assisted team can spend more time maintaining platform machinery than validating the product. SOC 2 certification before customers require it is unlikely to be the best use of capital.

RecommendationOne managed deployment platform, managed Postgres, object storage, a simple job queue, structured logs, Sentry-class error tracking, backups, CI, and IaC for critical resources. Design controls to be SOC 2-compatible; certify only when enterprise or integration partners require it.

AI-assisted delivery

AI improves feasibility. It does not make review light-touch.

Core conclusion

AI materially improves the feasibility of AMR, but it does not justify treating engineering review as a light-touch function. The senior engineer must own the technical system, not merely inspect occasional output.

DORA's 2025 research found near-universal AI use with positive throughput effects — but continued negative effects on delivery stability where control systems were weak; ~30% of respondents reported little or no trust in AI-generated code. A METR randomised trial found experienced developers on mature repositories took 19% longer with early-2025 AI tools, despite expecting to be faster. The useful planning question is not what percentage of code AI writes — it's whether AI reduces elapsed time and cost per accepted, production-safe feature.

Work typeAI suitabilityRequired human control
UI components, CRUD, OpenAPI clients, test fixtures, documentationHighProduct acceptance and normal code review.
CSV parsers, source mappings, migration scripts, metric SQLMedium-highGolden datasets, reconciliation tests, data-owner sign-off.
Connector adapters and retry logicMediumSandbox testing, rate-limit validation, replay tests, production observability.
Recommendation templates and evaluation casesMediumRestaurant-domain validation, outcome monitoring, safety review.
Tenant isolation, authentication, authorisation, secretsLowSenior engineer design and line-by-line review; security tests.
Identity merge/split logic and deletion workflowsLowSenior engineer ownership, adversarial tests, auditability.
Production infrastructure changes and incident responseLowHuman approval, least privilege, change records, rollback.
The senior engineer must be an active technical ownerHigh

AssessmentAI creates implementation capacity faster than review capacity. If the engineer is available only after features are generated, defects and architectural drift accumulate faster than they can be corrected.

RecommendationBudget ~0.4–0.6 FTE through Phase 1 and at least 0.25–0.4 FTE through pilot operations, with authority over architecture, security, database changes, production access and release approval. Increase during migrations, connector launches and incidents.
The design document cannot be the only source of truthMedium

AssessmentA long design document drifts as code and product decisions change; agents may follow outdated sections or reconcile contradictions inconsistently.

RecommendationConvert the design into versioned executable artefacts: ADRs, OpenAPI schemas, database migrations, metric definitions, threat models, data contracts, acceptance tests and evaluation cases. Every ticket identifies the authoritative artefacts it may change.
Quality gates must constrain agent output before reviewHigh

AssessmentHuman review alone will not scale with agent-generated change volume. The system must reject low-quality work automatically before the engineer sees it.

RecommendationCI requires formatting, linting, type checks, unit/integration tests, migration checks, dependency and secret scanning, RLS tests, API contract tests and deterministic data reconciliation. Agents must not merge, deploy or hold production credentials. Changes stay small enough to review; stateful changes carry a rollback plan.
Measure accepted output, not generated outputMedium

AssessmentLines of code and "% AI-generated" are easy to report but don't measure useful delivery — AI can increase code volume while also increasing rework, defects and review burden.

RecommendationTrack lead time to accepted change, review time, share of agent changes substantially rewritten, escaped defects, change-failure rate, rollback rate, test effectiveness, cost per accepted feature, pilot outcome. Use these to decide where agents genuinely help.

Recommended engineering workflow

  1. Product owner writes a bounded outcome, data examples, acceptance criteria and explicit non-goals.
  2. Senior engineer confirms architecture and identifies security-critical paths.
  3. AI agent implements on an isolated branch with no production access.
  4. CI validates code, contracts, tenant isolation, data reconciliation and security checks.
  5. A separate review pass identifies design drift, missing tests and unsafe assumptions; the senior engineer reviews critical changes directly.
  6. Deploy to staging with synthetic multi-tenant data, then to one pilot behind a feature flag with rollback.
  7. Production behaviour, data quality and customer outcomes feed new tests and specifications.

Commercial model

Price for the service you're actually delivering

The serviceable market is meaningful — but smaller than the headline sector countMedium

EvidenceNZ: 9,867 cafe/restaurant units (Feb 2025). Australia: 55,000+ cafe and restaurant businesses in 2024; ~89,000 including takeaway (June 2025).

AssessmentOnly a subset has the systems, revenue, guest identification and management maturity AMR needs.

RecommendationDo not present total hospitality outlets as TAM. Build a bottom-up list of target venues in NZ and Australia from the actual ICP, then validate reachability and pricing. Several thousand high-fit venues can still support a valuable vertical SaaS company.
Pricing is probably too low for a support-heavy first productHigh

AssessmentAMR's main early costs are onboarding, mapping, connector support, data reconciliation and customer success — not LLM tokens. A low monthly price creates poor unit economics before self-service exists. MarginEdge's public US pricing includes a US$350/month tier; direct competitors commonly quote.

RecommendationTest NZ$399–499 per venue per month with group discounts and a one-off onboarding fee of ~NZ$1,500–5,000 based on data complexity. Offer a managed-coaching tier only after the software workflow is proven. Prices are test ranges, not final recommendations.
Value proof must be specific and conservativeMedium

AssessmentRestaurants are noisy environments — demand, events, weather, menu changes and staffing all move outcomes. Overstated attribution will destroy trust; correlation-only reporting may struggle to prove value.

RecommendationSeparate observed facts, estimated opportunity value and realised outcome. Show assumptions and ranges. Track accepted actions against defined outcome metrics and time windows. Report time saved, actions completed and metric movement; avoid claiming causal profit unless the evidence supports it.
Concierge onboarding is appropriate — and should be priced as part of the productLow · retain

AssessmentCSV-first with concierge onboarding is the correct way to learn mappings and workflows, but it creates a services burden that must be measured rather than hidden.

RecommendationFor every pilot, record onboarding hours, mapping exceptions, source quality problems, training time and ongoing support. Productise the repeated work into import templates and diagnostics. Don't promise self-service until the median onboarding is repeatable.
The best early distribution may be trusted advisors and system partnersConditional

AssessmentOwners rely on accountants, bookkeepers, hospitality consultants, POS vendors and reservation providers for technology decisions. Founder-led sales suits pilots but may be expensive at a single-site price point.

RecommendationTest channel partnerships with hospitality accountants, advisory firms and local platform vendors after value is demonstrated. No revenue-sharing or exclusive integration agreements before understanding their effect on gross margin and data access.
VenuesNZ$399 / month — ARRNZ$499 / month — ARR
100NZ$478,800NZ$598,800
250NZ$1,197,000NZ$1,497,000
500NZ$2,394,000NZ$2,994,000
1,000NZ$4,788,000NZ$5,988,000

Revised delivery roadmap

Fewer simultaneous unknowns, explicit exit gates

The existing roadmap is directionally sound. This revision reflects AI-assisted implementation with senior engineering ownership. Timings are planning ranges, not commitments.

Stage 0 · 4 wks Validation & access

Ten owner interviews; five written pilot commitments; manual reports; verified source exports/API access; metric pack; privacy data map. ≥3 pilot owners credibly willing to pay ≥NZ$399/month and providing usable historical exports.

Stage 1A · 8–10 wks Trusted scoreboard

Shared-schema tenancy, RLS, CSV ingestion, 8–12 governed metrics, historical baseline, freshness status, Monday email/web report for one pilot. Two consecutive weekly reports reconcile to source systems within agreed tolerances; zero cross-tenant test failures.

Stage 1B · 6–8 wks Controlled intelligence

Top 10 Ask AMR questions using typed facts; opportunity records; audit/provenance; privacy deletion workflow; second and third pilots. Owners use the product weekly; recommendations accepted and tracked; deletion and recovery tests pass.

Stage 2 · 12–16 wks Guest & service loop

First live reservation/POS connectors, identity review queue, reversible identity history, noticing rules, minimal offline huddle, staff role. 3–5 pilots use huddles repeatedly; identity error rate and connector freshness meet defined thresholds.

Stage 3 · 12–20 wks Coach & paid rollout

Opportunity templates, goals/outcomes, voice-of-guest, selected labour/accounting connectors, paid plans, support runbook. ≥5 paying venues, positive gross margin after onboarding, evidence of recurring operational use.

Stage 4 Scale decisions

Self-service, connector catalogue, multi-site views, benchmarking, write-back actions, formal compliance programmes as demanded. Triggered by customer demand and operating metrics — not the calendar.

Phase 1 — keep

  • Multi-tenant Postgres with enforced RLS and role separation
  • CSV-first ingestion through the permanent connector contract
  • A limited, tested metric registry and historical baseline
  • Visible freshness and reconciliation status
  • One useful Monday report and a constrained web scoreboard
  • Audit/provenance sufficient to trace every published metric
  • A practical data-retention and deletion workflow

Phase 1 — cut or defer

  • Twenty Ask AMR questions at launch — start with ten, after the scoreboard is trusted
  • Per-guest crypto-shredding and indefinite immutable raw storage
  • Full huddle, voice-of-guest, live connectors, context events, staff features
  • Formal SOC 2 certification, Temporal, a commercial semantic-layer product, columnar analytics, cross-tenant benchmarking
  • Any write-back action or autonomous agent capability

Risk register

Twelve risks, ranked and mitigated

RiskLikelihoodImpactPriority mitigation
Source vendors do not provide practical or commercial API accessHighHighWritten access terms before build; CSV first-class; prioritise partner agreements.
Data is incomplete, inconsistent or cannot reconcileHighHighGolden source datasets, mapping versions, source health, reconciliation tolerances, visible stale states.
Competitors close the perceived feature gapHighHighPosition narrowly around ANZ stacks, weekly accountability, huddles, outcome evidence; avoid generic AI claims.
Single-site pricing cannot support onboarding and supportMed-highHighCharge onboarding; test NZ$399–499/month; track support cost by venue; target high-fit ICP.
AI-generated code increases defects and review backlogHighHighActive senior engineer, automated gates, bounded changes, no agent production access, delivery-quality metrics.
Cross-tenant data exposureLow-medCriticalRole separation, forced RLS, default deny, CI cross-tenant tests, security review, incident plan.
Privacy retention / deletion failureMediumHighRetention schedule, data inventory, deletion tests, provider contracts, privacy impact assessment and counsel.
Incorrect guest merge exposes wrong notes or service promptsMediumHighConservative matching, reversible identity history, human review, minimal huddle PII.
Recommendations lose trust through weak evidence or fillerMediumHighTyped evidence, confidence/freshness, no-action option, outcome tracking, evaluation set.
Pilot praise does not convert to paid recurring useMed-highHighBehavioural success gates and paid continuation; stop or reposition if owners don't act on insights.
Scope expansion delays the trusted coreHighHighRoadmap gates, explicit non-goals, architecture owner veto, no Phase 2 work before Phase 1 exit criteria.
Founder and engineer capacity becomes a bottleneckMediumHighExplicit role allocation, decision rights, incident cover, plan for data/QA support after initial pilots.

Pre-build decisions

Seven conditions before material production expenditure

  1. Customer evidence: five named pilot venues, at least three with a credible path to paid continuation at the proposed price.
  2. Connector evidence: written confirmation of access, export formats, terms and sample data for the first reservation and POS systems.
  3. Metric contract: signed-off definitions and source mappings for the initial 8–12 metrics, including tolerances and reconciliation examples.
  4. Privacy design: data inventory, purposes, retention schedule, cross-border/provider assessment, deletion workflow, staff-device policy, privacy impact assessment.
  5. Engineering operating model: named senior engineer, minimum time allocation, decision rights, production access rules, review gates, incident ownership.
  6. Pilot economics: onboarding budget, support assumptions, price test and explicit stop conditions.
  7. Evaluation plan: golden datasets, cross-tenant security tests, top Ask AMR cases, recommendation quality rubric, customer behaviour metrics.
Recommended stop condition

Do not expand beyond the trusted-scoreboard phase if the first three pilots cannot reconcile core metrics, do not use the report repeatedly, or are unwilling to pay a price that covers onboarding and support. In that case, change the product or ICP before adding guest intelligence, huddles or more connectors.

Investment recommendation

CONDITIONAL GO. Fund validation and the trusted-scoreboard pilot. Release further capital against evidence of source access, metric reconciliation, weekly usage, paid conversion and controlled delivery quality.

The architecture does not need a redesign. It needs a tighter first slice, a corrected market position, a practical privacy model, confirmed source access, and an engineering operating system designed for supervised AI output. A senior engineer who actively owns those functions materially improves feasibility. A senior engineer who only checks finished work does not.