The product opportunity

A commerce experience is more than a catalogue. Buyers need a clear route from finding a product to placing an order and understanding delivery. Vendors need a dependable way to present products, receive new orders and act on them. TradeFlow brings those connected responsibilities into one product journey.

Designing for two distinct users

I kept the buyer and vendor entry paths distinct. Buyers should be able to sign in and go straight to shopping rather than being dropped into merchant tools. Vendors need their own space to manage their storefront, products, delivery settings and incoming orders. That separation makes the next action clearer for each role.

The buyer journey

The buyer shop brings products from different vendors into one browsing experience, supported by vendor search, category filters and product previews. At checkout, the buyer provides location and address details so delivery pricing can use the vendor’s configured service areas. The important decision is to calculate from known coverage rather than show a convenient but potentially incorrect flat fee.

The vendor journey

Vendors configure their storefront and products, define the delivery areas they can serve and set the fees for those areas. Order notifications are persisted so the alert remains available when a vendor returns, instead of disappearing as a temporary pop-up. This makes order awareness part of the fulfilment workflow, not just a momentary interface event.

Key product decisions

I prioritised role clarity, product discovery and dependable order handoffs. Buyers can browse across vendor storefronts instead of navigating a separate shop for every seller. Delivery fees are based on vendor-configured coverage. Unsupported delivery areas are not assigned an invented default charge. Vendor order notifications are persisted so an offline vendor can still find the alert.

Payments, trust and release readiness

Paystack is integrated into the intended payment journey but remains in Test Mode. Before live release, I need to validate successful, failed and pending states, transaction reconciliation, webhook behaviour, duplicate submissions and the customer-facing message for each outcome. A deployed interface is not evidence that live payment processing has been verified.

Delivery and communication beyond the screen

The next layer is to make sure the right person receives the right update at the right time: account welcome messages, order updates, payment status, fulfilment changes and delivery confirmation. Transactional email automation is a roadmap item, with buyer and vendor communication kept distinct and marketing consent handled separately.

How I would measure success

I would establish a reliable baseline before setting targets. Core measures would include product-view-to-order conversion, checkout completion and abandonment, payment success and failure rates, time from order placement to vendor acknowledgement, delivery completion, support contacts per order and repeat buyer or vendor activity. Delivery-fee accuracy and unsupported delivery-area attempts would help test whether the location rules are understandable. These are proposed measures, not reported results.

Current status and next validation

The build is deployed for review, but it is not yet ready to present as a fully released commerce service. Some live screens still display OrderFlow branding, and Paystack remains in Test Mode. The release checklist is to resolve brand consistency, complete end-to-end payment tests, verify order and notification states across buyer and vendor accounts, test delivery-zone edge cases and confirm customer-facing updates before considering live payment processing.

Trade-offs and prioritisation

I prioritised work by how directly it protects a real order: first, make buyer and vendor responsibilities clear; next, calculate delivery only when a vendor has configured coverage; then preserve order alerts so vendors can return to them. Payment automation and transactional email need separate end-to-end checks before they can be treated as release-ready. This sequencing keeps core order handling ahead of secondary convenience features without implying that the product is ready for live transactions.

What this work reinforced

Commerce trust is built in the handoffs. A clean product page cannot compensate for unclear delivery costs, a missed vendor order or an ambiguous payment state. The product needs to make the next step clear for both sides, then give the team evidence to improve the journey after release.

Evidence of progress versus business impact

The deployed build and linked buyer shop make the current product direction inspectable. The documented scope covers distinct buyer and vendor paths, vendor-configured delivery areas, persisted order notifications and a payment journey kept in Test Mode. These are tangible product outputs and design decisions, not proof of live transaction volume or commercial performance.

Evidence available now: deployed interface, buyer-shop link and documented journey. Impact still to validate: successful end-to-end order tests across buyer and vendor accounts, delivery-zone accuracy, vendor acknowledgement time, checkout completion and payment reconciliation. Live-payment and business-impact claims remain out of scope until those checks produce reliable results.