Scroll previewEvery order came through an Instagram message. Around a thousand followers, a five star hygiene rating, and a kitchen cooking fresh every Saturday — with the entire order book living in a direct message inbox and a paper list.
What was actually wrong with taking orders on Instagram?
Nothing, until it worked. The business had grown to the point where every single order was a conversation, every week, and the owner was typing them out by hand in the evening after a day of cooking.
In concrete terms:
The brief was not "we need a website". It was "we need the ordering to stop being a conversation".
- Every order arrived as a direct message, was totalled up mentally, then written on a list.
- Anyone messaging at eleven at night waited until morning for a reply — and some of them never came back.
- There was no record of who had ordered what, so the Friday shopping list and the Saturday cook list were rebuilt from scratch each week.
- Nothing captured an email address, so there was no way to tell existing customers what was on the menu.
- Payment was collected separately, order by order.
Why we built a working site before writing a proposal
Because a meal prep shop is easier to judge than to describe. We built the full ordering journey as a static site first — real menu, working basket, live pricing — and sent the link.
That turned an abstract quote into something the client could click. It also caught a scope problem early: the first version had two sidebars, ingredient tag filters, meal plans, a blog with its own sidebar and nineteen sample dishes. The feedback was blunt and correct — too busy. We cut it back to a single row of categories and nine real meals, and the page got better.
What the approved design covers:
- Home, menu, product template, basket, checkout, what we do, about, blog, FAQs, contact.
- Four legal pages: terms of sale, privacy policy, cookie policy, refunds and cancellations.
- Eight products, each with its own page, photography, ingredients, allergens and two full sets of macros.
- A live countdown to the weekly order deadline.
- Postcode delivery checker.
How we priced a basket that changes price as it fills
We built the tier ladder into the cart itself rather than hiding it behind a discount code. Meals are £6 each under ten and £5 each at ten or more, recalculated across the whole basket as items go in.
Five meals is £30. Ten is £50. The site tells the customer how close they are — and there is a quirk worth knowing that we left in deliberately: nine meals costs £54 and ten costs £50, so the tenth meal is free. The basket says so.
On top of that:
We wrote ten pricing test cases and checked every one against the build before handing it to the developers. They are in the specification as the acceptance criteria.
- Every meal is available standard or with extra protein at £1.50 more, and the two carry genuinely different macros. On the Firecracker Beef that is 33g of protein against 54.5g. Both sets are published on the card, so the upgrade sells itself.
- Cold-pressed shots are £8 on their own or £6 alongside meals, applied automatically.
- A five meal minimum, enforced at checkout rather than at add-to-basket.
- Guest checkout throughout. The client was clear that customers should never be forced to register.
How we handled a delivery area that does not match the postcodes
We measured the actual distance from the kitchen instead of listing postcode districts. PR3 and PR4 are enormous — they cover places the client will happily drive to and places they will not.
The checker geocodes the postcode, measures the distance from the kitchen and answers accordingly. Longridge, six and a half miles out, gets a yes. Garstang, ten miles out, does not — and they are both PR3.
- Inside eight miles: Sunday delivery, £3.
- Eight to twelve miles: no Sunday delivery, but an invitation to ask about the Monday workplace round — which turns a rejection into the exact enquiry the client wants.
- Beyond that: an honest no, with free collection from the kitchen offered.
- If the lookup ever fails it falls back to a district list, so a third party outage cannot take checkout down.
What went wrong, and how we caught it
The site displayed the wrong week for anyone looking on a Friday. It was live on the preview when we found it, and it is the kind of fault that quietly costs orders.
The menu header read "week of 7 September". The countdown and the delivery date were both correct — Thursday 17th, delivered Sunday 20th — but the week label was calculated from the current calendar week rather than the week being ordered for. On a Friday that is the Monday just gone. Three correct dates and one wrong one on the same screen is worse than no dates at all.
The fix was to stop saying "this week" anywhere on the site. Every date is now named in full, and a single function decides all of them:
The specification handed to the developers requires the cut-off to be enforced on the server as well, not just displayed. A countdown stops nobody.
- One function returns the cut-off, the delivery Sunday, the workplace Monday and the time remaining. Nothing else on the site computes a date.
- We tested the roll-over across a full week. At 21:59 on Thursday it still offers that Sunday. At 22:01 every date on every page moves forward seven days.
- The same window now appears on the menu, the basket, the checkout and every product page, so nobody can build an order without knowing which Sunday they are buying for.
- Under 48 hours it turns amber. Under 24 hours it turns orange.
How we structured the local SEO for Lancashire
Around the towns the delivery van actually reaches, not around "meal prep UK". The business is one kitchen with one Sunday round, so the search strategy matches the radius.
Location pages in the build:
Technical work:
We make no promises about rankings. Nobody can. What we can say is that the site is structured to be found for the searches that matter locally, and that the groundwork is in before launch rather than bolted on afterwards.
- /meal-prep-preston/ — the primary page, covering the city centre, Deepdale and Penwortham
- /meal-prep-fulwood/ — Fulwood, Ashton and the Docklands
- /meal-prep-leyland/ — Leyland, Farington and Moss Side
- /meal-prep-bamber-bridge/ — Bamber Bridge, Lostock Hall and Walton-le-Dale
- /meal-prep-chorley/ — Buckshaw Village and Euxton
- /meal-prep-longridge/ — Longridge and the villages north east of Preston
- Meta titles and descriptions written for all 14 pages and all 8 products, every one inside Google’s limits — titles 33 to 58 characters, descriptions 124 to 157.
- Product titles lead with the protein figure, because that is what this audience searches for: "Firecracker Beef & Rice | 33g Protein".
- Product schema including NutritionInformation, which the macros already provide, plus LocalBusiness and FAQPage.
- One permanent URL per meal. The weekly menu is controlled by a category, so a dish resting for a fortnight keeps its page and its history.
- Open Graph on every page, so links shared to WhatsApp and Instagram show the meal photograph rather than a bare address.
- Sitemap, canonicals, and a check that the preview noindex tag is removed before launch.
How does an order actually reach the kitchen?
Through a checkout, paid, with no account required. That is the whole point of the project.
It suits this trade because a meal prep customer is a weekly repeat buyer who decides in about ninety seconds on a phone. Anything that adds a step — registration, a password, a code to hunt for — costs an order. The postcode checker also does quiet work: it tells the business which postcodes are asking and being turned away, which is where to expand next.
- Guest checkout with card, Apple Pay and Google Pay. Payment is taken before the shopping is done, which is what makes the Friday shop possible.
- Every order lands in one list with the customer’s name, address, phone, what they chose, the delivery date and any allergy notes.
- A cook list screen totals the week: "47 teriyaki, 12 extra protein, 83 shots". That single screen replaces the manual tally.
- A delivery list sorts the same orders by postcode for the Sunday round, and exports to a spreadsheet.
- Every confirmation email carries an "Order this again" link with the whole basket encoded in the URL. One tap refills it. No password, no account, works on any device.
What does the business have now?
A live shop that takes the order and the money in one go, and a kitchen that finds out what it is cooking from a screen instead of a notebook.
Three weeks of design and specification with the client, then six working days to build. The ordering has stopped being a conversation.
- Orders placed and paid for online, with card, Apple Pay and Google Pay — no account required at any point.
- Every order in one list with name, address, phone, contents, delivery date and allergy notes, exportable to a spreadsheet.
- A cook list that totals the week on one screen, replacing the manual tally.
- A delivery list sorted by postcode for the Sunday round.
- Nine meals with photography, two full macro sets each, ingredients and allergens.
- A weekly menu the client changes themselves in about two minutes, from a phone, with no developer involved.
- Four legal pages — terms, privacy, cookies, and a refunds policy that correctly handles perishable food under the Consumer Contracts Regulations 2013.
- Six location pages and complete metadata, in place from day one rather than bolted on later.
Thinking about something similar?
If you are taking orders through direct messages and it has stopped being manageable, that is exactly the problem this site was built to solve.
See our pricing, or tell us about your project. We will tell you honestly whether you need a new site or just a tidy-up.
Message us on WhatsApp — 07725 541812.
- /web-design-preston/ — add to the case study list on that page
- /food-and-drink-web-design/ — feature as the lead example
- /case-studies/ — index listing
- /pricing/ — link from the e-commerce section
- /pricing/
- /web-design-preston/
- /food-and-drink-web-design/
- /contact/
Frequently asked questions
What does a website like this cost?
Our packages are £1,000 for a complete site and £1,500 for everything. Hosting and care is £200 a year. A project like Love Meal Prep, with e-commerce, tiered pricing and a delivery radius, sits above the standard packages and is quoted on scope — but the starting point is the £1,000 complete build.
How long does it take?
Two to three weeks from approved design to live, for a site of this size. The build itself is six to seven working days. The rest is review rounds and waiting on photography, which is almost always what sets the date rather than the development.
Do you work in Lancashire?
Yes. We work with businesses across Preston, Leyland, Chorley, Blackburn and the wider North West, and with clients throughout the UK. Nothing about this build required being in the room.
Can I see the site before I commit to anything?
Yes. We build the homepage first for £100, fully refundable against the project if you go ahead. On this project we went further and built the whole ordering journey before quoting, because a shop is easier to judge than to describe.
How does the weekly menu change without a developer?
Every meal is a permanent product with a tick box. Each Friday the client ticks the nine dishes for the coming week and saves — it takes about two minutes, from a phone. Anything unticked drops into a browsable archive rather than disappearing, so the site never looks thin in a quiet week and the page keeps its search history. Nothing is deployed, nothing is edited in code.
Why WooCommerce rather than Shopify?
Because of one requirement: the client needed every order in a list they own, with names, addresses and payment method, exportable to a spreadsheet for the delivery route and the marketing list. WooCommerce gives that on day one and keeps the data on their own hosting. Shopify would have been faster to stand up but could not do the tiered pricing, the protein variants or the delivery radius without paid apps or custom work, and it puts a platform between the business and its own data.