Meeting Notes — Structured Summary

Client: Hassan (managing a local building-materials store, Bolton area)
Topic: Walk-through of current EPOS system and where the business is breaking down
Goal: Give Ilya enough context to produce a blueprint for either fixing the existing system or replacing it

1. Business context

• Local building-materials shop on a relatively main road in Bolton — significant passing vehicle and footfall traffic.
• Business has been operating ~12–15 years, well-known in the area by reputation/brand.
• Customer base: tradespeople, builders, DIY locals.
• Hassan has been managing the business for roughly 6–7 weeks — still learning some of the internals.
• Owners' likely 5-year goal: scale the business so it can be sold at a strong valuation. Hassan wants to drive that growth, not just maintain the status quo.

2. Current EPOS system

• Vendor: Magnum EPOS Limited (based in Bolton).
• Developers: Based in India. Magnum sells the same templated EPOS system to multiple businesses; only the product catalogue changes per client.
• Licensing model: Per-license fee. No developer documentation. Locked-down — Hassan can't get the source or extend it.
• Hassan's view: It's a "ready-made templated suit" that doesn't really fit this business. A lot of features exist in the UI but aren't trained or actually used.

3. Hardware they own

Important for the build-vs-replace decision. Hardware was purchased outright from a person called Nadeem (separate from the EPOS vendor):

• 2× touchscreen tills (Windows-based PCs)
• 2× keyboards
• 1× scanner (old — likely to be replaced)
• 2× cash drawers / till trays
• 2× small thermal receipt printers (old, sometimes take ~1 minute to print — needs replacing)
• 1× larger A4 printer connected to the system

Implication: Tills are essentially Windows PCs. Any new system that runs in a browser (Chrome / Firefox / etc.) can use this existing hardware. That saves significant capital cost vs. buying new EPOS hardware (~£1,200–£1,500 per till).

4. Problems identified (grouped by impact)

4.1 Till shortcut buttons no longer work

• Previously there were ~12 shortcut buttons on the till for fast products (e.g. timber 3×2, 2m length).
• Problem: the shortcut buttons did not decrement stock. Sales via shortcuts didn't sync to the stock manager.
• "Fix" so far: shortcuts were removed entirely. Staff now type product names into a search field, which does deduct stock — but it's slower per transaction.
• Hassan asked Magnum to fix the shortcut→stock link. Their quote: £80,000 to restructure the EPOS. Hassan (correctly) sees this as absurd.
• Cost to the business: small per sale, but compounds across the day and frustrates staff used to shortcuts.

4.2 Stock manager is fundamentally inaccurate

• ~11,500 products in the system.
• Most products have no stock level, no cost, no supplier, no minimum/maximum levels.
• Because parts of stock data are wrong, staff have given up maintaining it for the rest — "if one thing's broken, why bother with the rest."
• Plan in progress: Staff coming in after hours, starting this week, to manually count and enter stock for the first time.
• Ilya raised: AI may be able to speed up parts of stock management — to be explored.

4.3 Some products don't have factory barcodes

• Packaged products (boxed nails, screws, etc.) come with barcodes.
• Loose products do NOT — examples:
  • Timber sold by length (e.g. 3×2 at 2m).
  • Screws / nails sold by the kilo — customer says "I need a kilo of these screws," staff weigh and price.
• Internal codes are assigned by staff for these.
• The new system needs a robust way to handle weight-based and length-based pricing alongside barcoded items.

4.4 No date stamps on price changes

• Supplier prices change constantly. Retail prices also need inflation adjustments.
• Currently: no record of when a product's cost price or retail price was last changed.
• Needed: a date field per price update, so they can filter "anything not price-checked in the last 2 years" and review only those.

4.5 Credit accounts are completely out of sync

The most operationally painful problem after stock.

• Tradespeople have credit limits — they take stock, pay later.
• Process today: staff tick off paid invoices on a physical receipt but don't update the till system. So the system still shows the customer owing money they've already paid.
• Hassan has had to zero out all credit balances because the data was unusable.
• Required behaviour for the new/fixed system:
  • Easy "pay off credit" flow (must be fast, or staff will skip it).
  • Part payments: customer with £1,000 debt can pay £500 — system shows £500 remaining.
  • Split tender on debt repayment: e.g. £250 cash + £250 card on one credit-repayment transaction.
  • Credit limit enforcement at point of sale: when a customer at their credit limit is rung up again, the till must block further credit and force payment for the new sale.
  • Reporting view: "all customers currently in credit, with balances."

4.6 No staff accountability on sales

• All staff use shared tills with no individual login.
• When a discrepancy or refund shows up, Hassan can't trace who did it without interviewing everyone.
• Two possible fixes discussed:
  • (a) Add a third till and assign 1 till = 1 staff member (3 staff at counter).
  • (b) Per-user login on each till — every transaction tied to a staff member (the "supermarket" model).
• Hassan leans towards (b) eventually, because it also unlocks sales-based staff incentives.

4.7 Receipt printers are slow

• Old thermal printers; can take ~1 minute to print a receipt — unacceptable for trade customers.
• Ilya flagged: receipt-printer choice matters because thermal printers vary in speed, reliability, and codec / driver compatibility.
• Ilya to research recommended models when the time comes.

4.8 Reporting is weak and untrained

• The system has Z reading / X reading per till (end-of-day cash-up).
• Today's report shows e.g. cash £1,757, card £349, VAT breakdown — useful as far as it goes.
• Most reports are either inaccurate (because stock is wrong) or not trained / not used.
• Hassan can't pull a meaningful product report with all fields — exports are missing barcode, stock-on-hand, etc. depending on which report you choose.

4.9 Payment terminals don't integrate with the EPOS

• Current payment processor: DNA Payments — does not integrate with Magnum EPOS. Staff are typing amounts manually into the card machine → fraud/typo risk + extra time.
• Dojo Payments does integrate with Magnum. Charges are broadly similar to DNA.
• Decision pending: switch to Dojo now (quick win, stays with Magnum), or wait for the wider ecosystem change.

4.10 Export / migration risk

• Magnum's product export only gives partial fields per report.
• For migration to a new system, they need a single export covering every field per product.
• Hassan will push the Magnum vendor for a fuller export.

5. Vision — what "good" looks like

5.1 Operational

• Accurate stock at all times, kept accurate by good process + good UI.
• Per-staff transaction logging for accountability and incentives.
• Fast credit-repayment flow with part payments and split tender.
• Credit limit enforcement at point of sale.
• Price-change history with dates for every product.
• Receipt printing that's near-instant.

5.2 Reporting

• Daily Z/X readings per till that actually reconcile.
• Per-staff sales reports.
• "Customers in credit" report with balances.
• "Products with stale prices" filter.
• Stock-ordering suggestions (re-order based on min levels).

5.3 Customer-facing (next phase, after EPOS is sorted)

• Web app (not a brochure site) — product-heavy, search-first.
• Phone-number login with 4-digit OTP via SMS/WhatsApp — no password to remember.
• Click & collect — order online, walk in and pick up.
• Possibly later: delivery.

5.4 Future-proofing

• Architecture that supports multiple branches from one central management system.
• Central system tells each branch what to order based on its own stock.
• Cross-platform — must work on Windows, Mac, Linux as long as there's a browser.
• Must integrate cleanly with bookkeeping, payment providers, etc.

6. The two strategic options on the table

Option A — Stay with Magnum, fix what's fixable

• Manually rebuild the stock data (already in motion).
• Retrain staff on existing flows.
• Switch payments to Dojo so the card machine integrates with the till.
• Replace receipt printers.
• Add a third till and/or per-user logins.
• Workable, but: long-winded, capped ceiling, can't really support a serious web app or multi-branch growth.
• Hassan's own words: "workable… just hard work."

Option B — Build a new system from scratch (Ilya's preferred direction)

• New web-based EPOS, runs on existing Windows tills via browser.
• New database designed around this business (products with weight/length pricing, credit accounts, multi-branch readiness, integration points).
• Phone-OTP customer login and click-&-collect web app on top of the same database.
• Future-proof for multi-branch.
• Constraint: Has to come in at a cost the owners will sign off on. £80,000 (the Magnum number) is a non-starter.

7. Commercial framing

• Retainer model, not licensing. Whatever Ilya builds, the client owns it — full documentation, full keys. "I build your house, you live in it."
• Ilya keeps the right to reuse the codebase as a template for other businesses. Hassan is fine with this — "if it works for me and you can utilize it for somebody else, we are happy."
• Pricing approach:
  1. First map current problems and what each one is already costing the business.
  2. Quote the MVP only — not the full long-term roadmap.
  3. Future phases get priced separately, once the MVP decision is made.
• Some problems will have no clean monetary value — those get discussed qualitatively.

8. Decisions made in the meeting

1. Hassan will not pay Magnum £80,000 to restructure the EPOS.
2. Stock will be manually counted and entered as the baseline — this is unavoidable.
3. Hassan will speak to the Magnum vendor and request a full product export.
4. Ilya will produce a blueprint document within ~4 days.
5. Hassan will then present the blueprint to the business owners and decide go/no-go.
6. Either way, the agency relationship continues — Hassan has separate packaging-business work coming.

The EPOS isn't the problem — the problem is that everything in this shop (stock, credit, prices, staff accountability, the website you don't yet have) is downstream of a system that was never built for you. The MVP is a clean database with the till and credit flow on top of it; everything else — web app, click & collect, multi-branch — plugs into that same database when the time comes.