X-Vendor

The original problem came from a friend in Nigeria who runs Deo Super Food & Event Services, public-facing brand Chef Deo. Her street-food operation relied on local POS terminals, cash payments, handwritten or fragmented ledger tracking and manual reconciliation at the end of the day.

It also ran in an environment with unreliable electricity and no practical receipt printer — the two assumptions most commercial POS products quietly depend on.

The problem was not simply “build a POS”. The business needed a reliable way to run the day and then understand it afterwards.

• Capture orders quickly at the point of sale.
• Reconcile sales and ledger records.
• Work around inconsistent electricity and printer availability.
• Give the owner visibility into business performance.
• Support discounts and repeat-customer loyalty.
• Give customers a receipt without introducing printer dependency.
• Eventually support multiple staff and multiple outlets.

Primary users are the business owner and the sales staff working the terminal. Secondary users arrived as the product grew.

• Primary — business owner / founder: reconciles the day, needs to trust the numbers off site.
• Primary — street-food sales staff / terminal users: fast order entry while customers queue.
• Secondary — customers receiving digital receipts on their own phone.
• Secondary — future external business owners using X-Vendor for their own operation.
• Secondary — multi-outlet operators needing business-level oversight across locations.

This was founder-led contextual discovery: I learned how the business actually operated before deciding what to build. I watched trading hours rather than interviewing after close, because the behaviour that matters — shortcuts, mis-keys, interruptions — only appears under pressure.

I mapped the end-to-end workflow from order taken to day reconciled, marking each point where information was lost. Most loss happened at two moments: when an item was sold without being written down, and when a discount was given verbally.

• Live observation of ordering, payment and end-of-day reconciliation.
• Workflow map of the manual ledger process with information-loss points marked.
• Review of existing POS tools against the vendor's real constraints (cost, hardware, connectivity).

The constraints defined the product more than the feature list did.

• Unreliable power — the app has to survive being closed mid-shift and resumed without data loss.
• No printer — receipts must be delivered without hardware.
• Tablet-first — one shared device, gloved or wet hands, glare, large tap targets.
• Low technical confidence — no training budget, no manual, no support desk.
• Cost sensitivity — the subscription has to be obviously cheaper than the problem.

Each decision traces back to a constraint rather than to a feature request.

• QR receipts instead of printed slips — removes hardware cost entirely and gives the customer a durable record.
• Sales and ledger as one model, not two — the ledger is a view over transactions, so it cannot drift from reality.
• Discounts as a first-class, logged action rather than an untracked price override, closing the biggest information-loss point.
• Loyalty tied to the customer's receipt rather than a physical card, reusing a mechanism the customer already has.
• Staff workflows with per-user attribution so the owner can reconcile a shift, not just a day.
• AI insights framed as plain-language observations on the vendor's own data — never predictions presented as fact.
• Multi-tenant from the schema up, so a second outlet is configuration rather than a rebuild.

The first release did one job: replace the paper ledger without making the seller slower. Anything that did not serve that was deferred, even where it was commercially attractive.

• Must — sales entry, item catalogue, daily ledger view, QR receipt.
• Should — dashboard, discounts, staff accounts and attribution.
• Could — loyalty, AI insights, multi-outlet comparison.
• Won't (first release) — inventory forecasting, integrated payments, accounting export.

I used an AI-assisted product development workflow: I defined the problem, users, workflows, requirements and feature priorities, then used Lovable to accelerate implementation. I reviewed the generated product, tested critical workflows, directed changes and iterated based on real operating needs.

My contribution is product judgement and technical direction, not line-by-line authorship. Where the generated implementation was wrong — data model shortcuts, unhandled offline states, unclear error paths — I caught it in review and testing and specified the fix.

• Write the requirement and acceptance criteria before any generation.
• Direct the AI tool to implement one scoped slice at a time.
• Review the result against the acceptance criteria and the data model.
• Test on the actual device class the product runs on.
• Iterate with vendor feedback and re-specify rather than patching blindly.

A single web application, installable on a tablet, talks to a shared backend where every record carries a tenant identifier. Outlets sit beneath a tenant, so an owner with two locations sees both without any duplication of accounts or catalogue.

Receipts are generated as a link encoded into a QR code — the customer scans and reads it on their own phone, so no printing hardware exists in the loop. Subscription tier is a property of the tenant and gates which features render.

Validation to date is qualitative. I am deliberately not publishing user counts, revenue, order volume, retention or time-saving figures until they are instrumented and substantiated.

• The founder's real operational need drove the original build.
• The product was used in the context it was designed for.
• Customers noticed the application, and some business owners expressed interest in using something similar.
• That external interest is what led to the decision to evolve the architecture into a multi-tenant SaaS.

What this project demanded of me as a product person, rather than what the product contains.

Context can matter more than copying standard POS patterns — the reference designs assumed infrastructure this business did not have.

Infrastructure constraints drove better product decisions. Removing the printer was a constraint before it was a feature.

A focused MVP revealed a larger market opportunity: solving one business's problem properly is what attracted others.

Product architecture has to evolve when the target customer changes from one business to many.

AI-assisted development speeds up delivery, but product judgement, validation and ownership remain human responsibilities.

The roadmap follows the questions vendors keep asking that the product cannot yet answer.

• Structured evidence capture: instrumented usage so outcomes can be reported with confidence.
• Stock and wastage tracking tied to the existing item catalogue.
• Cross-outlet comparison views for multi-location tenants.
• Formalised onboarding so a new tenant can self-serve without a walkthrough.