Production development timeline

Decisions to make

• Who owns NCR or Aloha access, vendor communication, and approvals.
• Which Aloha path is available for the first release: API, export/import, middleware, or staff-reviewed handoff.
• Which menu, tax, tender, payment, and store rules must match before orders can be trusted in POS.

Why this timing is realistic

The time-consuming part is not the first code pass. It is getting credentials, confirming the exact store setup, understanding what NCR will allow, and identifying any certification or vendor review steps before development commits to an integration path.

Ready to move on when

The team knows the approved Aloha path, the access owner, the data that must match, and the fallback process if direct POS push is not ready.

Decisions to make

• Which provider and merchant account will process production catering payments.
• Whether the first release supports deposits, full payment, staff-selected terms, or a combination.
• What finance needs for settlement review, refunds, reconciliation, and exception handling.

Why this timing is realistic

This work runs early because the dependencies are partly external. Provider setup, account review, finance expectations, and refund rules should be known while payment implementation is still flexible.

Ready to move on when

The production payment path, merchant responsibilities, refund policy, and reconciliation expectations are clear enough to build and test against.

Decisions to make

• Which payment events change order status and which require staff review.
• Who can request payment, resend payment, cancel payment, and issue refunds.
• What staff and finance see when payments fail, settle, refund, or need manual attention.

Why this timing is realistic

The checkout screen is not the hard part. Production confidence comes from testing webhooks, duplicate events, declined cards, refunds, reconciliation, support recovery, and finance review with real operating rules.

Ready to move on when

A first-release order can be paid, refunded if needed, and reconciled without special engineering help.

Decisions to make

• Who can view, edit, approve, cancel, refund, export, and manage customer records.
• Which users are limited to one store, which users can see a region, and which users can see the full brand.
• How new staff are added, removed, reviewed, and deactivated over time.

Why this timing is realistic

The implementation is manageable, but permission mistakes are expensive. The schedule gives the team time to test real staff scenarios across money, customer information, store boundaries, reporting, and approvals.

Ready to move on when

Each staff role can do its job, sensitive actions are limited, and store or regional boundaries are clear.

Decisions to make

• Which messages customers receive at each step: quote request, payment, order confirmation, changes, and cancellation.
• Which staff members are alerted, and when a regional or support contact should be pulled in.
• What tone and sender identity should be used so the messages feel like Mission catering, not system mail.

Why this timing is realistic

Message copy, sender setup, and deliverability need calendar time. The business also needs to review the content because customers will treat these messages as official commitments.

Ready to move on when

Customers receive the right messages, staff alerts reach the right people, and support can see what was sent.

Decisions to make

• Whether mission-bbq.com links into the flow, embeds it, or sends customers to a dedicated ordering URL.
• Which parts of the existing flow can go live as-is, and which need final copy, brand, analytics, or tracking review.
• Which store limits still need to be explicit: lead time, service area, order minimums, blackout dates, and availability.

Why this timing is realistic

This should not be treated like a ground-up build. The time is mainly website integration, final business rules, customer-facing polish, and a few end-to-end tests with staff.

Ready to move on when

Customers can reach the ordering flow from Mission's website, place a valid order, and staff can review or confirm it without a side conversation.

Decisions to make

• Which production-like scenarios must pass before the first store uses the flow.
• Which issues block release, which can be managed operationally, and which can wait.
• What support needs to see when payment, notification, permission, or order handoff problems happen.

Why this timing is realistic

QA needs people from different parts of the business in the same loop. It also exposes missed details, so the schedule needs room for a few rounds of corrections before rollout planning takes over.

Ready to move on when

The team can run the full process without hand-holding, and the most likely problems have clear owners and recovery paths.

Decisions to make

• Which orders should go to Aloha automatically, and which should stay staff-reviewed.
• What staff see when a POS handoff succeeds, needs review, or fails.
• How finance and operations compare CRM orders, payments, and POS records.

Why this timing is realistic

With the core workflow clarified, a first integration pass can move quickly. The calendar risk is validating real menu items, tax, tenders, store routing, duplicate orders, failed pushes, and any vendor approval steps.

Ready to move on when

Orders either push cleanly to Aloha or route through an approved staff handoff, and exceptions are visible to the team.

Decisions to make

• Which customer moments should trigger a message: quote follow-up, missed payment, post-event thank-you, or reorder reminder.
• What consent rules and suppression rules apply.
• Which results matter: completed orders, repeat catering, customer replies, or staff follow-up saved.

Why this timing is realistic

Campaigns depend on clean customer and order data. It is better to launch a few high-confidence messages after the core ordering, payment, and notification flow is proven than to automate too broadly too early.

Ready to move on when

The first campaigns are approved, measurable, consent-aware, and ready to turn on after data quality is proven.