--- title: Food and Beverage Platform Development description: url: https://miracuves.com/industries/food-beverage date_modified: 2026-08-17 author: miracuves language: en_US --- # Food and beverage platforms, built for the hour that actually decides everything. Ordering, dispatch and settlement engineered around the dinner rush, because that is the hour where promise times slip, couriers run short and margin disappears. Thirty food and grocery platforms already in production, and a custom engineering team for everything beyond them. [Talk to an engineer](https://miracuves.com/schedule-consultation/) [See what we've shipped](#shipped) Where this starts from **30**Platforms in production **8**Operator types served **2-8*wks***Custom build, scoped **6*days***Ready-made launch Peak load designed forThe dinner rush, not the average Source codeYours, in full DeploymentYour infrastructure Support, fixes, updates60 days, 6 and 12 months *Menu, dispatch and payouts* · modelled together, not bolted together Custom build Starting from a shipped platform Custom build - 2 to 8 weeks, scoped Catalogue Order engine Dispatch and payouts Peak testing Onboarding Launch Ready-made platform - 6 working days Rebrand, deploy, live Six working days is the launch timeline for a ready-made platform as it ships - branded, deployed and live on infrastructure you own. Sector work beyond that, and the custom track above, is scoped and quoted in writing before anything starts. Both tracks are the same engineering team. Every figure on this page is defined on our [facts page](https://miracuves.com/facts/). ## What a food platform build actually contains The sequence below is where food and grocery platforms are won or lost. Every phase names what it requires and, where one exists, the shipped platform that removes it. Almost nothing in this sector fails on the happy path. A single order placed at three in the afternoon works on every platform ever built. What separates a platform that survives its first Friday night from one that does not is what happens when four hundred orders arrive in twenty minutes, a merchant stops accepting, and the courier pool in one postcode goes to zero at the same moment. Three of the seven phases have no shortcut, and we mark them as such below. What a shipped platform removes is the middle: the order state machine, the dispatch logic and the payout engine, which is where most of the build time and nearly all of the subtle correctness problems live. At a glance Phases7 With no shortcut3 Removed by a shipped platform3 Fixed regardless of trackCatalogue, peak testing, launch **01**Weeks 1-2 ### Catalogue, menu and modifier modelling This is the phase every team underestimates and the one that quietly decides whether the platform can scale past one vertical. A restaurant menu is not a product list. It is a tree of items, variants, modifier groups with minimum and maximum selection rules, availability windows, and per-store overrides on price and stock. Grocery is a different shape again: tens of thousands of SKUs, weight-based items where the final price is not known until picking, and substitution rules the customer has to pre-approve. A platform that models a burger and a kilogram of tomatoes with the same schema will be rebuilt within a year. The output is a catalogue model that survives both, plus the merchant-facing rules for what a store can override and what stays central. Modifier groupsPer-store overridesWeight-based itemsSubstitutions No shortcut here. Catalogue shape is the same problem on both tracks - and getting it wrong is the single most expensive mistake in this sector. **02**Weeks 2-3 ### Order lifecycle and the state machine An order is a state machine with roughly a dozen states and a much larger number of illegal transitions. Placed, accepted, rejected, preparing, ready, assigned, picked up, delivered, cancelled by three different parties, refunded in part or in full. Every one of those transitions can arrive twice, out of order, or from a client that has been offline for four minutes. The correctness question is not whether the happy path works. It is whether a merchant tablet that reconnects after a dropout can cancel an order that has already been picked up, and what the platform does when it tries. Idempotency keys on every write and a state machine that rejects illegal transitions outright are the difference between a support queue and a refund liability. Partial fulfilment belongs here too. Grocery orders routinely ship short, and the money has to follow the goods that actually arrived. State machineIdempotency keysPartial fulfilmentCancellation policy **Already built**A production order engine with a guarded state machine, partial fulfilment and refund handling.[Swiggy Clone](https://miracuves.com/swiggy-clone/) · [Doordash Clone](https://miracuves.com/doordash-clone/) · [Instacart Clone](https://miracuves.com/instacart-clone/) **03**Weeks 2-4 ### Dispatch and courier assignment Dispatch is the hardest engineering problem in the sector and the one most platforms get wrong by treating it as a nearest-courier lookup. The real problem is a scheduling one: you are assigning a limited courier pool against orders that are not yet ready, with prep times that are estimates, in a city where travel time depends on the hour. Assigning too early strands a courier at a kitchen for eleven minutes and removes them from the pool. Assigning too late means the food sits. Batching two orders raises courier earnings per hour and lowers your cost per drop, but only if the second pickup is genuinely on the way, and a naive batcher will happily send a courier backwards. This is also where courier supply meets economics. Incentives, surge and zone-level pricing are dispatch inputs, not a marketing feature bolted on afterwards. Assignment timingBatchingZone pricingCourier supply **Already built**Dispatch with prep-time-aware assignment, batching and zone-level incentives.[Ubereats Clone](https://miracuves.com/ubereats-clone/) · [Deliveroo Clone](https://miracuves.com/deliveroo-clone/) · [Glovo Clone](https://miracuves.com/glovo-clone/) **08**Weeks 3-6 ### Payments, splits and merchant payouts One customer payment becomes four or five obligations: the merchant's share, your commission, the courier's earnings, the tip, and the tax that sits on top of some of those and not others. Getting the split right at order time is straightforward. Getting it right after a partial refund, a substituted item and a tip adjusted an hour later is where platforms leak money. Merchant payouts run on a schedule, usually weekly, and every one of them is a statement a merchant will check line by line. If your ledger cannot reproduce a payout from the orders that made it up, you will spend the first month of every quarter reconciling by hand. Tips deserve their own attention. In most markets a tip is legally the courier's, which means it cannot sit in your revenue and cannot be netted against a chargeback. Split calculationMerchant statementsTip handlingRefund flows **Already built**Split payments, scheduled merchant payouts and courier earnings with reconcilable statements.[Zomato Clone](https://miracuves.com/zomato-clone/) · [Grubhub Clone](https://miracuves.com/grubhub-clone/) **05**Weeks 5-7 ### Peak load and promise-time accuracy Food platforms do not have traffic, they have two spikes a day. Sizing against average load is how a launch goes down at seven on a Friday. Load testing here means replaying a realistic peak: concentrated in two postcodes, with merchant accept latency and courier supply modelled rather than assumed infinite. Promise time is the number the customer judges you on, and it is the composition of four estimates that each have their own error. Quoting a tight window you miss is worse than quoting an honest one you hit, and the platform should be measuring its own accuracy per merchant and per hour from day one. Peak replayETA accuracyMerchant latencyDegradation modes No shortcut. Partially. Shipped platforms arrive load-tested at a reference profile, but your city, your merchant mix and your courier density have to be tested against your own numbers. **06**Weeks 6-7 ### Merchant and courier onboarding at scale Supply onboarding is an operational problem that presents as a software one. Getting the first fifty merchants live is a spreadsheet and a determined operations hire. Getting to five hundred is a self-serve flow with menu ingestion, bank verification, and a review queue for the ones that need a human. Courier onboarding carries compliance weight that varies sharply by market: right-to-work checks, vehicle and insurance documents, and in some jurisdictions background screening with a defined re-check interval. Documents expire, and a platform that does not track expiry will eventually dispatch to an uninsured courier. Menu ingestionDocument expiryBank verificationReview queue **Already built**Self-serve merchant onboarding with menu ingestion, plus courier document capture and expiry tracking.[Talabat Clone](https://miracuves.com/talabat-clone/) · [Rappi Clone](https://miracuves.com/rappi-clone/) **07**Weeks 7-8 ### Launch city and day two One city, one merchant cohort, one courier pool, then widen. Launching three cities at once triples the operational surface before you have learned what your promise times actually are, and every early problem in this sector is discovered through operations rather than monitoring. Day two is where the sector differs from most: the first month generates a backlog of merchant disputes, courier earnings queries and refund edge cases, and the platform needs the tooling to answer them without engineering involvement. Sixty days of dedicated support, six months of priority bug resolution, twelve months of updates. Single cityOps toolingDispute handlingDay two support No shortcut. Same on both tracks. A shorter build does not shorten a launch - and any vendor telling you otherwise has not run one. Want any of these phases costed against your own catalogue and city? [Book a technical call](https://miracuves.com/schedule-consultation/) ## Where an order actually goes Every food platform is this diagram with different names on the boxes. The hops are easy. What separates a platform that holds its promise time from one that does not is what happens when a hop fails, and whether the money still balances afterwards. At a glance Hops, tap to doorstep5 Failure modes named5 ReconciliationDaily, per merchant Order isA state machine, not a record **Order flow, tap to doorstep**Customer to delivery, with the failure mode at every hop CustomerMerchantKitchenDispatchDoorstep Order placedBasket, address, payment held Accept or rejectUnder a clock PrepEstimate, not a fact Courier assignedTiming decides cost DeliveredProof captured Settlement, daily Split against merchant, courier and tip. Breaks surface here or not at all. Failure modes Silent merchantPrep overrunCourier reassignPartial fulfilmentTip adjusted late Standard pathWhere platforms break A silent merchant is the first failure and the most common. The tablet is on, the order is showing, and nobody has pressed accept because the kitchen is slammed. A platform that waits indefinitely has already lost the customer; one that auto-rejects at ninety seconds without telling the merchant loses the merchant instead. ### Why the order is a state machine and not a record A row in a table with a status column will pass every test you write and fail in production within a week. The reason is that transitions arrive concurrently: a courier marks picked up at the same second a customer cancels, and a merchant tablet that has been offline replays four events at once. With a status column, last write wins and the order ends in a state nobody intended. A state machine that declares its legal transitions rejects the illegal ones by construction, and an idempotency key on every write makes the replay harmless. The cost is a few days of design. The alternative is a refund process that runs on judgment rather than rules, and a support team that cannot explain to a customer what happened to their money. At a glance Status columnLast write wins State machineIllegal transitions rejected Replayed eventsHarmless with idempotency CostDays of design, not weeks Want the order model and settlement walked through against your own volumes? [Talk to an engineer](https://miracuves.com/schedule-consultation/) ## Eight operators, eight different builds "Food delivery" is not one buyer. The catalogue, the margin structure and the failure mode change completely between them. At a glance Operator types8 Can start from a shipped platform6 Need a custom build2 ### Restaurant marketplaces Many merchants, one courier pool, commission on every order. The classic three-sided problem: customer demand, merchant supply and courier supply all have to grow together, and the platform is judged on promise time it only partly controls. 6 shipped platforms ### Quick commerce Ten to thirty minute grocery from dark stores. Inventory accuracy is the whole business, because a substitution at the picking stage is a customer decision you have seconds to get approved. 4 shipped platforms ### Full-basket grocery Weekly shops, hundreds of lines, weight-based pricing and a delivery slot booked days ahead. Slot capacity planning matters more than dispatch speed, and the final total is not known until picking completes. 5 shipped platforms ### Alcohol and regulated Age verification at order and again at handover, licence-bound delivery zones, and hours that change by jurisdiction. The compliance layer is not optional and cannot be configured after launch. 4 shipped platforms ### Single brand and chains One brand, many stores, no marketplace. Loyalty, order-ahead and store-level menu control dominate, and the economics are completely different because there is no commission to take. 3 shipped platforms ### Cloud kitchens Multiple virtual brands from one physical kitchen, sharing prep capacity. The scheduling problem is internal: which brand's order gets the fryer next, and how prep time is estimated when four menus share equipment. Custom build ### Meal kits and subscription Recurring orders, a menu that rotates weekly, and a cut-off after which the box is locked. Churn and skip logic are the product, and the delivery problem is a scheduled one rather than an on-demand one. Custom build ### B2B and wholesale food Restaurants ordering from distributors. Credit terms, standing orders, price lists that differ per account and a delivery window measured in hours rather than minutes. 2 shipped platforms Six of the eight can start from something already running. Two are custom builds because nothing off the shelf carries the domain properly, and we would rather say that than sell you an adaptation that fights you for two years. Not sure which of these you are, or you sit across two of them? [Book a scoping call](https://miracuves.com/schedule-consultation/) ## How the work actually runs Six stages, the same on both tracks. What changes between a custom build and a platform adaptation is how long stage three takes, not whether the other five happen. At a glance Stages6 Identical on both tracks5 Varies by trackStage 3 only 01Stage ### Scoping against your catalogue and cities We start from the catalogue you actually carry, the cities you are launching in and the courier model you intend to run, because those three decide the architecture before any preference does. A quick-commerce operator with owned dark stores and a marketplace with third-party restaurants are not the same build, and finding that out in month four is expensive. **Ends with**Written scope: catalogue model, courier model, launch city, and the merchant integrations to open first. 02Stage ### Architecture and the money model Every commercial rule gets mapped to a place in the system before the system is built. Commission structures become configuration rather than code, tip handling becomes a ledger decision, and refund policy becomes a state-machine rule. Commercial terms change monthly in this sector; a platform that needs a release to change a commission rate will hold the business back. **Ends with**A ledger model, a commission engine held as configuration, and refund rules a finance team can change. 03Stage ### Build against peak-shaped data Food platforms fail on concentration, not on volume, so test environments carry realistic shapes from the start: four hundred orders in twenty minutes across two postcodes, merchants that accept late, couriers that go offline mid-delivery, and partial fulfilment on a third of grocery baskets. A platform that has only seen evenly distributed test traffic will meet a Friday night as a novelty. Length varies by track **Ends with**Test data carrying concentrated peaks, late accepts, courier dropouts and partial baskets. 04Stage ### Compliance and payment validation Age verification where the catalogue requires it, food-safety record keeping where the regulator requires it, and PCI scope kept small by tokenizing at the boundary. Our platforms arrive with a VAPT and compliance document, so the external test starts from a documented baseline rather than a blank page. **Ends with**A VAPT and compliance document, plus age and licence checks proven against the live catalogue. 05Stage ### Merchant integration and pilot cohort A pilot cohort of real merchants, running real orders, before the city opens. This is where menu ingestion meets reality: POS systems that export inconsistently, stores that price differently from their own website, and modifier rules nobody documented. It depends on third parties and is the most common cause of a date slipping. **Ends with**A live pilot cohort, ingested menus and the POS integrations your merchant mix actually needs. 06Stage ### Launch and day two One city, watched through its first two weekends, with the operations team and the engineering team in the same room for the first of them. Then we stay on, because the edge cases in this sector arrive with volume rather than with time. Sixty days of dedicated support, six months of priority bug resolution, twelve months of updates. **Ends with**Sixty days dedicated support, six months priority bug resolution, twelve months of updates. Want this sequence mapped against your catalogue and launch city? [Book a technical call](https://miracuves.com/schedule-consultation/) ## Thirty food and grocery platforms already in production Every one ships with full source-code ownership, deployed on your infrastructure under your brand. Adapt one, or use it as the reference architecture for a custom build. They fall into four groups, and which group you start from matters more than which name you recognise. **Restaurant marketplaces** carry the merchant, courier and commission model and are the usual starting point for aggregators. **Quick commerce and grocery** platforms add inventory, picking and substitution, which is where most of the engineering risk in grocery actually sits. **Regulated categories** add age verification and licence-bound zones. **Wholesale and B2B** platforms handle credit terms, standing orders and per-account price lists rather than consumer checkout. At a glance Platforms already shipped30 Operator types covered8 DeploymentYour infrastructure, your brand [Swiggy](https://miracuves.com/swiggy-clone/) [Zomato](https://miracuves.com/zomato-clone/) [Doordash](https://miracuves.com/doordash-clone/) [Deliveroo](https://miracuves.com/deliveroo-clone/) [Ubereats](https://miracuves.com/ubereats-clone/) [Uber Delivery](https://miracuves.com/uber-delivery-clone/) [Grubhub](https://miracuves.com/grubhub-clone/) [Justeat](https://miracuves.com/justeat-clone/) [Foodpanda](https://miracuves.com/foodpanda-clone/) [Talabat](https://miracuves.com/talabat-clone/) [Hungerstation](https://miracuves.com/hungerstation-clone/) [Glovo](https://miracuves.com/glovo-clone/) [Rappi](https://miracuves.com/rappi-clone/) [Postmates](https://miracuves.com/postmates-clone/) [Delivery Hero](https://miracuves.com/delivery-hero-clone/) [Chownow](https://miracuves.com/chownow-clone/) [Instacart](https://miracuves.com/instacart-clone/) [Blinkit](https://miracuves.com/blinkit-clone/) [Zepto](https://miracuves.com/zepto-clone/) [Bigbasket](https://miracuves.com/bigbasket-clone/) [Grofers](https://miracuves.com/grofers-clone/) [FreshDirect](https://miracuves.com/freshdirect-clone/) [AmazonFresh](https://miracuves.com/amazonfresh-clone/) [Onecart](https://miracuves.com/onecart-clone/) [Goldbelly](https://miracuves.com/goldbelly-clone/) [Drizly](https://miracuves.com/drizly-clone/) [Flaviar](https://miracuves.com/flaviar-clone/) [Nestor Liquor](https://miracuves.com/nestor-liquor-clone/) [Vivino](https://miracuves.com/vivino-clone/) [Weedmaps](https://miracuves.com/weedmaps-clone/) ## Where the promise time actually comes from The number on the customer's screen is the sum of four estimates, each with its own error. Platforms that quote a single confident figure are usually hiding the widest of the four, and the customer discovers it at the door. At a glance Estimates in a promise4 Widest errorPrep time MeasuredPer merchant, per hour Honest window beatsA tight one you miss **Promise time composition**Four estimates, and which one actually moves Quoted window Accept30-90 sec Prep8-35 min. The widest error, and the one you do not control. Courier to store3-12 min Store to doorstep6-20 min, traffic dependent What a platform can actually do Measure prep per merchant, per hour of day Quote a window rather than a point, and widen it honestly at peak Hold assignment until prep is credible, so couriers are not stranded Report accuracy back to the merchant, because they can fix what they can see PredictableWhere the error lives Prep time is the only component a platform cannot directly control and the one that dominates the error. Everything useful a platform does about promise time is really about measuring prep honestly and quoting around it. ## What this sector requires ### Catalogue integrity Modifier groups with real selection rules, per-store price and stock overrides, weight-based items and pre-approved substitutions. The schema decides which verticals you can enter later, so it is worth more design time than it usually gets. ### Promise-time accuracy Measured per merchant and per hour rather than assumed, quoted as a window, and reported back to merchants. Accuracy is a retention metric in this sector, not an operational nicety. ### Dispatch economics Assignment timing, batching that never sends a courier backwards, and zone-level incentives that respond to supply. Dispatch is where your cost per drop is decided, and small logic changes move it materially. ### Money splits that reconcile Merchant share, commission, courier earnings, tips and tax, reproducible from the orders that made them up. Tips are usually legally the courier's and cannot sit in platform revenue or net against a chargeback. ### Regulated categories Age verification at order and at handover, licence-bound delivery zones, and trading hours that differ by jurisdiction. These cannot be retrofitted after launch without re-verifying every existing account. ### Peak resilience Sized against the concentrated peak rather than the daily average, with defined degradation: which features shed load first, and what the customer sees when they do. The alternative is discovering it on a Friday. Want to open any of these platforms and look inside before deciding? [See the live demos](https://miracuves.com/solutions/) ## Inventory is where quick commerce quietly fails A ten minute promise is an inventory promise before it is a delivery promise. If the picker reaches the shelf and the item is not there, no amount of dispatch quality recovers the order. At a glance Stock states tracked3 Substitution decided byThe customer, in seconds ReconciliationPer pick, not per day Root causeAvailable is not the same as on shelf **Pick and substitution flow**Basket to handover, or to a customer decision BasketReservePickHandover Order placedShows available Soft reservationHeld, not yet picked Picker at shelfTruth arrives here Basket finalCharged for what shipped Substitution offered Customer approves or removes, in seconds Basket adjustedSplit recalculated What breaks without this Customer charged for an item that never shipped, and a refund queue that grows faster than the business Standard pathWhere the truth arrives Available in the catalogue and present on the shelf are different facts, and only one of them is known at order time. Platforms that treat them as the same number generate their refund volume by design. Want your inventory and substitution model reviewed against your store format? [Talk to an engineer](https://miracuves.com/schedule-consultation/) ## Built custom when nothing off the shelf fits The same team, working from zero. These are the capabilities we build into food and grocery platforms that no shipped product carries, because they are specific to how you operate. At a glance Custom capabilities6 Operator types needing custom2 ### Cloud kitchen scheduling Multiple virtual brands sharing one kitchen's equipment and staff, with prep estimates that account for contention rather than treating each brand as independent. [Custom software development](https://miracuves.com/service/custom-software-development/) ### Slot and capacity planning Delivery windows booked days ahead against picking and van capacity, with dynamic slot pricing that fills the quiet hours instead of overselling the busy ones. [Backend engineering](https://miracuves.com/service/backend-development/) ### POS and menu integrations Two-way integration with the till systems your merchants already run, so menu and price changes flow without a second data entry job that nobody does. [API development](https://miracuves.com/service/api-development/) ### Demand and prep forecasting Per-merchant, per-hour models that improve promise-time accuracy and tell dispatch when to hold assignment, trained against your own order history rather than a generic curve. [Data engineering](https://miracuves.com/service/data-engineering/) ### Courier earnings engines Incentive structures, guarantees and surge that respond to real supply, with earnings statements a courier can query and a finance team can defend. [Custom software development](https://miracuves.com/service/custom-software-development/) ### Regulated category compliance Age verification, licence-bound zones and jurisdiction-specific trading hours, built as configuration so entering a new market does not require a release. [Compliance engineering](https://miracuves.com/service/compliance-consulting/) Need something this list does not cover? [Ask about custom work](https://miracuves.com/schedule-consultation/) ## What we built, and what it delivered Three deployments in this sector, described by what was actually built rather than by a metric we cannot show you the working for. At a glance Builds detailed here3 Quick commerce ### Dark-store grocery, single city Inventory-first build with soft reservations, picker app and customer-approved substitution. Launched on one dark store, extended to four before the platform changed shape. Restaurant marketplace ### Aggregator with own courier fleet Order engine, dispatch with batching, and merchant payouts on a weekly cycle with statements merchants could reconcile themselves. Regulated delivery ### Alcohol delivery with licence zones Age verification at order and handover, licence-bound zones and jurisdiction trading hours held as configuration rather than code. We describe these by scope rather than by outcome metrics, because the numbers that matter to you are your own and we would rather model them with you than quote someone else's. Want to speak to a reference operating in your format? [Request a reference](https://miracuves.com/schedule-consultation/) ## Written on this sector Longer pieces on the problems above, written by the engineers who build these platforms. At a glance Articles4 [Dispatch ### Why nearest-courier assignment costs you money](https://miracuves.com/blog/) [Catalogue ### Modelling menus and groceries in one schema](https://miracuves.com/blog/) [Promise time ### Measuring prep time honestly, per merchant](https://miracuves.com/blog/) [Settlement ### Splits, tips and refunds that still reconcile](https://miracuves.com/blog/) If a question here is not covered, the fastest route to an answer is a call with the engineer who would run your build. Want these as a briefing pack for your board or engineering team? [Request the pack](https://miracuves.com/schedule-consultation/) Every quote we had assumed we were building a restaurant app. Miracuves asked about our picking process in the first twenty minutes, which told us they had done this before. The failure pattern this page is built around That gap is the whole reason this page exists. Forty client testimonials sit on the site with names, titles and companies attached, and none of them are invented. [Read all forty](https://miracuves.com/client-testimonials/) ## Questions food and grocery buyers actually ask The ones that come up in the first call, answered as we would answer them there. At a glance Questions answered12 Can we really launch in six working days? Yes, for the shipped platform as it comes - branded, deployed and live. Catalogue extension is custom work quoted separately, and none of it covers merchant recruitment, which is your operational timeline and usually the longer one. Do we own the source code? Yes, in full, deployed on your infrastructure. No per-order licence, no per-seat fee, no runtime dependency on us. How do you handle merchants with existing POS systems? Through an integration layer rather than direct coupling, so one merchant's till system does not become an architectural constraint. Which integrations you need depends on your merchant mix and is scoped in stage one. What happens when a merchant does not accept an order? You set the policy: auto-reject with a customer refund, escalate to a call, or reassign to a nearby merchant where your model allows it. What matters is that the policy is explicit and the customer is told promptly. Can the commission structure change without a release? Yes. Commission, courier incentives and zone pricing are held as configuration precisely because they change monthly in this sector. How is dispatch tuned for our city? Against your own order history and courier density once you have them, and against a reference profile before that. Dispatch parameters are meant to be tuned continuously, not set once. Do you build the courier and merchant apps too? Yes. A food platform is three applications and an operations console, and shipping only the customer app is how projects stall at month four. How do you handle tips? As courier money held separately from platform revenue, adjustable within a window, and never netted against a chargeback. In most markets that treatment is a legal requirement rather than a preference. What about age-restricted categories? Verification at order and again at handover, licence-bound zones, and trading hours per jurisdiction. If you intend to carry alcohol later, say so in scoping - retrofitting it means re-verifying every existing account. Can we run our own couriers and third-party fleets together? Yes, and most operators end up doing so. Dispatch treats them as separate pools with different cost and reliability, and decides per order which to use. What does support look like after launch? Sixty days of dedicated support, six months of priority bug resolution and twelve months of updates. The first month is where the sector's edge cases arrive, so that is when we stay closest. What if we are not ready to build yet? We will say so. If your merchant supply is not secured or your unit economics do not survive a delivery cost, a platform will not fix either, and we would rather tell you that than scope work you cannot use. Question not answered here? [Ask us directly](https://miracuves.com/schedule-consultation/) ## Tell us what you are building. Bring the catalogue and the city. We will tell you honestly which track is right - including when the answer is that you do not need us yet. [Book a technical call](https://miracuves.com/schedule-consultation/) [Browse all solutions](https://miracuves.com/solutions/) A first call takes about thirty minutes and covers four things **01** ### Catalogue shape Restaurant menus, grocery SKUs, or both in one platform. **02** ### Courier model Own fleet, third party, or a mix you dispatch across. **03** ### Launch city Where you start, and what your merchant supply looks like there. **04** ### Existing systems The POS, payment and accounting stack a platform must fit into. Those four answers are usually enough for us to tell you which track fits, roughly what it costs, and whether your unit economics survive a delivery cost before you build anything. If the honest answer is that your merchant supply needs to come first, we will say that instead of scoping work you are not ready to use.