Yes, and for most independent kitchens this is the single biggest change you can make to your bottom line. The math on marketplace delivery is brutal once you actually run it. If your food cost is around thirty two percent and your labor is in the low thirties, a thirty percent commission means you are cooking that order at a loss before the driver ever pulls into the lot. You are not fixing that with volume, and you are not fixing it by quietly raising your prices on the app, because the platforms have terms that restrict price differences between channels. The fix is to stop renting the transaction in the first place.

When somebody orders from your own site, you keep the ticket. The commission does not exist, because there is no marketplace sitting between you and your customer taking a cut for the privilege of introducing you to somebody who already lives four miles away. You still have your payment processing fee, the same as you do at the counter, and that is it. Ordering is an integration on top of the base website build, so it is priced separately from BWD Launch, but it is usually the add on that pays for itself fastest.

You use the same delivery companies you use now, except you hire them as couriers instead of partnering with them as a marketplace. That distinction is everything. As a marketplace, they own the customer and take a percentage of the whole ticket. As a courier, they are just a driver you paid a flat fee to move one bag from your door to an address, and the price does not change because the order happened to be a large one.

I can set this up two ways depending on your volume and your budget. The simpler version is manual dispatch, where the order comes into your site and a staff member requests a driver through a portal when the food is close to ready. The higher tier is an automated dispatch integration, where a driver is requested the moment the customer checks out and nobody on your crew has to do anything at all. Either way, I configure checkout so the flat delivery fee is passed to the customer, exactly the way it already works on the apps they are used to. Your margin on a delivery order ends up looking almost identical to your margin on a dine in order, which is the entire point.

No, and I would not build it that way even if you asked me to. Forcing a stranger to make an account before they can buy a pizza is how you lose the sale. Guest checkout is the default on both the custom plugin build and the WooCommerce build, so anybody can land on your site, order, pay, and be done without creating anything.

Accounts are still worth talking about, though, because your regulars are a different animal from your first time visitors. If the same family orders the same thing every Friday, an optional account lets them save an address, save a payment method, and reorder a past favorite in one tap. That convenience is a real part of why people default back to the apps, and matching it keeps those orders coming to you directly. Optional accounts require the WooCommerce route, which I will explain next.

WordPress has a reputation for being slow, and most of the time that reputation is earned by plugin bloat rather than by WordPress itself. Every off the shelf plugin you install ships with a pile of features you will never use, and your visitors pay for all of it in load time. That is why my default for a restaurant menu is a custom plugin built specifically for your site. It does exactly what your restaurant needs and nothing else, it ties into a WordPress payment gateway so you can take money, and it stays out of the way of your page speed.

The trade off is that the custom plugin is deliberately lean. It does not do customer accounts, and it does not track order history beyond what your payment gateway already records for you. If you want saved addresses, saved payment methods, and one click reordering for your regulars, that is WooCommerce territory. WooCommerce is the heavier option and the restaurant ordering extension is a paid plugin that you purchase and renew annually, so there is a recurring cost that belongs to you rather than to me. Both routes are integrations quoted on top of BWD Launch, and which one is right for you comes down to whether repeat customer convenience is worth the extra weight and the annual license.

They can, through an API integration, and it removes one specific headache. Without it, somebody on your staff reads the order off one screen and types the address and details into another, which is exactly the kind of task that goes wrong at seven o’clock on a Friday. With the API connected, that information transfers directly and your employee never retypes anything.

I want to be clear about what this does not solve, because I would rather set the expectation now than argue about it later. It stops your employee from fat fingering an address. It does not stop a customer from typing their own address wrong when they place the order, and it does not stop anybody from double tapping a button. Those are human problems and no integration on earth fixes them. What it does do is remove one of the two places where a typo can enter the system, and in a busy kitchen that is worth having.

This is called a phantom storefront, and if you have ever taken an angry phone call about an order you never received, you have probably met one. The apps run automated bots that scrape menu data wherever they can find it, which in small town restaurants usually means a photo of your laminated menu sitting on your Facebook page or an old PDF nobody has touched since before the pandemic. They build a listing out of that scraped data and start accepting orders without asking you. When the price is wrong or the item was discontinued in 2021, your staff absorbs the argument and your restaurant collects the one star review. It is a well documented practice and advocacy groups have been pushing state lawmakers to ban it outright.

What I can do is cut off the food supply. A real website with a live, text based menu becomes the single verified source of truth for what you sell and what it costs, which means the bots have accurate data to find instead of a three year old JPEG. I also build in proper ownership and copyright markings so there is clear documentation that the menu, the logo, and the photography belong to you. That documentation is what you need when you go to the platform and demand the unauthorized listing come down. I am a web developer and not an attorney, so I am building the evidence and not filing the paperwork, and if a platform digs in you should talk to a lawyer. Linking your Google Business Profile directly to the verified site is an optimization service, and it helps route people to your real menu instead of a hijacked listing.

Almost always because your menu is a picture. Google finds your pages with automated crawlers that read text, and a photograph of a laminated menu is just pixels to a crawler. If you make the best scratch made gluten free crust within fifty miles, but those words only exist inside a JPEG on a Facebook gallery, then as far as Google is concerned you do not sell it. Somebody five minutes away searches for gluten free pizza near me, and a chain with a text based menu takes the order that should have been yours.

A live text menu fixes this at the root. Your dish names, your descriptions, and your ingredients become readable content on a page you own, which is what search engines index and what puts you in front of people who are actively looking to spend money right now. This is also why the menu is worth doing properly instead of bolting a photo onto a page and calling it done. Local search is how people find restaurants now, and being invisible in that moment costs you far more over a year than the build costs once.

No, and it fails for two separate reasons. The first is the same indexing problem as the Facebook photo, because the text inside a PDF is effectively invisible to search crawlers. The second is that PDFs are miserable on a phone, and the majority of restaurant searches happen on phones. The text does not reflow to the screen, so your customer is pinching, zooming, and panning around a document built for a sheet of paper. Most of them give up.

The maintenance side is worse. When your poultry cost jumps and you need to raise a price, updating a PDF means finding the original design file, editing it, exporting a new version, logging into the site, deleting the old file, and uploading the new one. Nobody running a kitchen has time for that, so it gets put off, and six months later your website says eleven dollars while your printed menu says fourteen. The customer feels lied to, your manager honors the old price to keep the peace, and you eat three dollars on every one of those tickets because of a file nobody had time to update.

This trips people up, so let me separate two things that sound like one thing. Building the menu system is an integration, which means I write the plugin, wire it to your payment gateway, and hand you a working menu that is ready to be filled. Typing in ninety dishes with descriptions, prices, modifiers, and photos is something else entirely. That is data entry, and it is not part of the base build and it is not part of the integration.

You entering your own menu costs you nothing but an evening, and honestly it goes faster than most owners expect once they get a rhythm. If you would rather hand it off, I will do it, and it is billed like any other ongoing work at the monthly retainer plus the hourly rate with a one hour minimum. That is the same arrangement whether it is the initial menu, a seasonal rewrite, or adding a new item next spring. I would rather you know that before we start than find it on an invoice.

You do, and that is by design. When I finish a build I hand you the keys, and the keys are yours. Your content is your content, and nobody on earth knows your business better than you do, so you should not need to file a support ticket and wait on me to change the price of a burger. This is the main reason I build on WordPress. Changing a price is about as difficult as writing an email, and once you have done it twice you will never have to think about it again.

I do the heavy lifting on the build so that what is left for you is filling in the blanks. If a particular task turns out to be complicated enough that several people ask me the same question about it, I write it up on the Buckeye Web Development blog so there is a public reference anyone can follow. If you would rather not touch it at all, I can do the updates for you under a retainer, but I would encourage you to try it yourself first. Most owners are surprised by how quick it is.

The website gives you a place where that information is visible to everybody who lands on your page, which is something a Facebook feed can never do. On social media the algorithm decides who sees your post and when, so somebody can visit your page on Friday and be shown Tuesday’s soup. If you close early for a furnace repair, the notice gets buried under older posts and people drive out anyway, then take their frustration out on whoever is standing at the host stand. You cannot fix that on Facebook because you do not control the ranking.

On your own site you can, but you have to actually do it. If you post a special, set it to expire on the date it ends so it takes itself down without you having to remember. If you are closed for the day, put the notice up and take it down when you reopen. Your Google Business Profile is a separate manual step in both directions, so you go in, mark yourself closed for those hours, and then go back afterward and restore your normal hours. Nothing syncs that for you automatically. A dedicated announcement or closure area is not part of the standard build, but it can be added as an integration if you want something purpose built.

We work with what you have. A decent phone photo taken in good light is usually better than people expect, and a real picture of your actual plate beats anything generated every time. Uploading them is the easy part, and it is the same process as adding any other menu detail, so this is work you can do yourself as you take new pictures.

Where you have gaps, I can generate an image that represents the dish so the page is not sitting empty on launch day. If somebody is ordering lasagna, they see lasagna. I would treat that as a placeholder rather than a permanent solution, and there is a practical reason beyond aesthetics. A generated image that implies a specific portion size, a specific cut of meat, or plating your kitchen does not actually do sets an expectation you then have to meet at the table, and the person standing there when a customer is disappointed is you and not me. Swap in real photos of your real food as you get them, because your phone is fine and your food is the selling point. If you would rather I handle the uploading and cropping for you, that falls under the same retainer and hourly arrangement as any other menu work.