Website for PowerMeals
Replace a highly customised WordPress/WooCommerce system for a meal delivery service with a high-performance adaptable platform.
Innovations
- Reimplemented an algorithm originally defined in Excel with recursive iteration upon all the possible meals by the number of desired meals which whilst logical was costly, not being particularly capable with such techniques I reduced it to simply iterating all meals (typically around 50, before excluding those not matching diet) for a max n loops, adding similar/identical meals only on later loops to emphasise variety, thus decreasing variety with each iteration, yet also handling diet protein distributions (easy in the case of carnivore, harder in the case of flexitarian). This generally completes in few iterations, and in rare cases where diet is restricted not many more. When necessary it will flag an account as having an overly restrictive diet that could not be automatically allocated an adequate variety of meals.
- Introduced the ability to no longer require an 'active' account (subscription) to place an order, and therefore also changed copywriting and terminology to be more explanatory e.g. retired 'subscription' in favour of 'recurring deliveries' that could then be switched off. When off, orders are only created and allocated on-demand, not as part of the batch processing.
- Deprecated the (unsustainable and gamable) use of a payment grace for the first order on signup if payment wasn't settled.
- Introduced the 'flexitarian' diet with a data structure for proteins on each diet permitting percentages to be set for each being used in automated allocations. (Would also permit each customer to set their own, but not implemented.)
- Simplified ingredient and exclusion handling, utilising inheritence, categories and inverted diet flags (e.g. not-vegan, not-vege) on each ingredient.
- Improved meal cards with subtitles, and label/sticker overlays.
- Replaced the basic printing of postal service labels as only permitted in WooCommerce, with a bespoke system including generation of the Odoo stock picking barcode printed on the same delivery label, greatly simplifying the pick+pack process. (This was phased, early releases instead used sorted printed picking lists and labels, to which a short weekly internal consignment identifier was added, i.e. every consignment could be uniquely identified within a given week even if delayed, and the number generally being 3–4 digits making it easier to match by eye, versus previously attempting with an entire recipient name.)
- Bundled SKUs, e.g. buy a group of items at a discount, with all products items ised individually.
- Implemented receipts instead of 'invoices'.
- Simplified customer and order references, where customers are given a short alpha-numeric code, and orders simply use their date, e.g. 241201-AB (PNR).
- Improved formatting of localised values e.g. Swiss prices, and dates.
- Far easier customer lookup in the backoffice, with default selected search allowing instant typing or paste of name/tel/email.
- Use of the Moonstalk stack with the OpenResty and Tarantool application servers.
- The entire platform went from multiple second waits in the Wordpress backoffice to simply see orders, to sub 10ms render times across all pages including complex backoffice queries.
- Lightweight json payloads in each language comprising the weekly menu and ingredients for the client-side application.
- Many pre-cached data (e.g. products per menu) generated in the webserver avoiding the need to query the database, or generated as a cache on a schedule in the database and loaded by the web server.
- When the scheduled batch processing fails (regrettably not infrequent due to Odoo issues) it can simply be re-run manually.
- Statistics on most daily operations to ensure smooth running, with a daily recap and individual signups requiring review posted to the Slack channel.
- Emphemeral datasets in records discarded when no longer required, by segmenting the orders into current and archive, where current orders contain production details that are not relevent to keep after production. (Whilst not needed at the time, it significantly improves performance should the dataset grow.)
Features
- Fully translated and localised for Switzerland in English, German and French.
- Weekly menus comprising changing meal and extras SKUs.
- Client-side basket checkout for selecting, filtering and pricing.
- Menu and product data also utilised in dedicated non-customer menu pages, with a basic CMS for managing categories.
- Dedicated 'trial' package checkout having set delivery charges.
- Customer dietary preferences include filtering.
- Coupons (discount value) with a variety of use scenarios, plus vouchers (cash-credit value), and gifts (rewards) to be claimed upon passing thresholds.
- Flexible holiday rescheduling for closure days (albeit not implemented fully abstractly).
- Utilising fairly standard scheduled early morning batch processing for credit card payments, initially using Stripe, then replaced with a Swiss payment gateway, and other methods; also downloads postal service waybills for labels, amongst other functions.
- One grace order when automated payment settlement fails. (Improved customer retention.)
- Integrated HubSpot for CRM, with many recurring API updates syncing customer state changes, such as activating or deactivating recurring orders, which is then used for automated emails.
- Implemented sending orders to the hosted Odoo service for ERP and production, including carrying out order confirmation; further integrations planned.
- Migrated data from multiple millions of Wordpress SQL rows, many duplicated or deprecated, and actually only representating less than 10,000 records after migration (Demonstrating the impracticalty and high overheads of WordPress/WooCommerce as a platform.)
- Included training the frontend dev (JS/PHP) in basic framework, Lua and Tarantool usage.
- Included the initial layout/CSS, subsequently handed over to a frontend dev, and new designer, but thus loosing the nuanced/clean typesetting I'd applied in favour of micro-animations and such like; usability input ongoing.
Links
