Over the past two months, our five-person team at Foodmartex has built catalogue-grounded AI ordering, expanded rewards and gift fulfilment, introduced more vendor delivery capabilities, and extended rider tipping across five service types. My biggest takeaway as CTO and backend engineer: the exciting feature gets attention; the correctness behind it earns trust.
First, make sure ice cream doesn’t become rice
“Hello Sarah. I need ice cream.”
That sentence now has a place in our backend tests.
The expected behaviour sounds obvious: find ice cream from an eligible restaurant. If none is available, say so.
But search systems can see similarities where hungry people see completely different meals. A loose match can turn an ice cream request into a rice recommendation. A friendly greeting can accidentally become part of the product search.
It is a small technical problem with a very human consequence: someone asks for dessert, and the app misunderstands them.
That captures much of our recent work at Foodmartex.
We are a team of five, building a food-tech company with strong roots in Ile-Ife, Osun State, Nigeria. Our ambitions extend beyond one city, but the experience has to make sense in the everyday situations around us: deciding what to eat, buying groceries, arranging deliveries, and getting errands done.
Over the past two months, my work as CTO and backend engineer has centred on one question:
How do we turn more of those everyday intentions into dependable digital experiences?
The answer involved AI. It also involved transactions, reward lifecycles, delivery subsidies, and quite a few tests.
The journey: connecting the experience around an order
Foodmartex already had foundations for ordering and delivery. This period was about connecting more of what happens before, during, and after those transactions.
Before an order: can someone describe what they want and find the right products?
During checkout: can we apply an incentive consistently, even when requests overlap?
After a reward win: can we follow the promise through to fulfilment?
After delivery: can the customer thank the rider across different services?
Here are five areas where that work took us.
1. AI ordering that stays grounded in real products
A conversational shopping assistant has an appealing promise: describe what you need, review the options, and move towards checkout.
The difficult part is preserving meaning along the way.
“I want fried rice and chicken” usually means a prepared meal.
“I need ingredients for fried rice” means groceries.
“Add the 5 kg bag” should preserve both the selected product and its measurement.
Those distinctions shaped our AI-assisted ordering work.
How we approached it
The assistant works with catalogue results, and the backend validates proposed cart actions against those results.
That includes checking the selected product, supported quantities, and extra options. Recommendations become pending actions that require confirmation before changing the cart.
Confirmation also checks that the recommendation remains valid. If a price changes or an item becomes unavailable, the system requires a fresh recommendation.
For shopping lists, we added support for validating multiple lines and confirming them together. If a line becomes invalid during confirmation, the transaction can roll back the batch rather than leave an unexpected partial result.
What this makes possible
Customers can explore products conversationally while the backend remains responsible for prices and cart state.
That separation is especially useful when someone says “add it,” switches from restaurant meals to groceries, or returns to an earlier recommendation.
A model can suggest dinner. Your backend must prove what goes into the cart.
For foodies and explorers, the opportunity is easier discovery. For engineers, the challenge is keeping conversation flexible while making committed actions precise.
2. Rewards that continue beyond the winning animation
A reward wheel looks simple: spin, see a result, celebrate.
The engineering continues after the animation stops.
Has the reward been recorded? Is the gift available? Can the customer claim it? Which order should carry it? What happens if that order is cancelled?
During this period, we expanded the rewards experience with guest spins, earned bonus spins for qualifying orders and referrals, reminders, and gift fulfilment across supported service orders.
How we approached it
Guest spins include duplicate protection, campaign controls, and verified claiming.
Physical gifts have a separate fulfilment lifecycle covering availability, expiry, attachment to an eligible order, handover, customer receipt, and missing-gift resolution.
We also preserve fulfilment history when a missing gift needs administrative resolution or reissue.
These details matter because winning, claiming, and receiving are different events. A customer can attach a valid reward to an order before its deadline and still need the delivery process to finish afterward.
What this makes possible
Rewards can become an operationally traceable part of the experience.
The customer sees a prize. The team needs enough context to answer, “What happened to my gift?”
That is the difference between building an engaging interaction and building a promise the business can follow through on.
3. Free delivery with an honest account of the cost
“Free delivery” is two words sitting on top of several financial decisions.
Who qualifies? Is there a minimum order amount? When is the benefit considered used? What happens if someone starts more than one checkout?
We added a first-delivery benefit and refined how it is reserved and consumed. We also introduced per-vendor free-delivery controls.
How we approached it
The first-delivery benefit has an explicit lifecycle: reservation, consumption after successful payment, and release when appropriate.
Eligibility is evaluated against the configured rules, including the minimum order amount. Order summaries can explain whether the customer meets that threshold.
The delivery calculation also preserves the underlying delivery cost while allocating what the customer and platform pay.
We expanded financial-health calculations to include reward costs and delivery subsidies, too.
What this makes possible
Customers can receive an incentive while the business retains a meaningful view of its expense.
That matters when evaluating whether an offer makes sense beyond its initial appeal.
“Free” describes the customer’s charge. Someone still carries the cost.
For anyone building commerce software, this is a useful design question: will your promotion still be understandable when the campaign ends and the accounting begins?
4. More control for vendors and clearer order communication
Customer experience depends on the workflows supporting it.
A polished checkout cannot compensate for a vendor who lacks the right controls or a customer who cannot tell whether an order has progressed.
Our recent work included vendor parcel delivery, configurable automatic order acceptance, and additional order-confirmation notifications.
How we approached it
Vendor parcel delivery supports delivery estimation and creation using the vendor’s pickup details and wallet.
The workflow includes access controls, current-quote validation, and cancellation tracking.
Order settings also give vendors control over automatic acceptance. That makes acceptance behaviour an explicit operational choice.
We added customer order-confirmation notifications across multiple order types and refined notification channels for paid vendor orders.
What this makes possible
Vendors gain another way to use delivery infrastructure beyond a standard food order.
Configurable acceptance can accommodate different working practices, while confirmation messages help customers understand where their order stands.
These are practical details for businesses fitting a platform into an already busy day.
They also reflect something local product development keeps teaching us: useful software has to work with the people running the operation.
5. Saying thank you across five service types
Riders connect the digital order to the physical delivery.
We extended tipping across restaurant, market, pharmacy, laundry, and parcel orders.
That is five service types, each with its own delivery details, behind one familiar customer intention: “Thank you.”
How we approached it
The backend verifies that a customer can tip the order, that delivery is complete, and that the tip is associated with the appropriate rider.
That last point matters for services such as laundry, where the return delivery has its own rider relationship.
Wallet and provider-funded tips include payment checks and duplicate protection. We also tested cross-service edge cases to ensure every tip stays associated with the correct order and rider.
What this makes possible
Customers gain a consistent way to express appreciation across more services.
The visible interaction is small. The financial responsibility behind it is significant: the correct amount should reach the correct recipient once.
A repeated request should produce a predictable outcome.
What challenged us and what we learned
The most useful lessons came from the places where apparently straightforward behaviour became ambiguous.
Search needed tighter boundaries between prepared meals and ingredients. Conversation handling needed to preserve selected products when customers referred back to earlier messages.
We also corrected inconsistencies in cart totals and summaries a reminder that explaining a price deserves the same attention as collecting payment.
Three lessons stand out.
Intent needs evidence
A plausible AI response is insufficient grounds for changing a cart.
The system needs a valid product, supported quantity, current quote, and customer confirmation.
Natural language can start the workflow. Application rules have to carry it through.
Lifecycles deserve early attention
Rewards, benefits, payments, and gifts all have intermediate states.
“Used” and “unused” rarely capture enough.
Naming those states forces useful questions: what can happen next, who can trigger it, and what happens when the process stops halfway?
Retries are part of the product
Networks fail. Customers tap again. Payment events repeat.
A dependable backend gives repetition a defined outcome.
Our automated tests cover boundaries such as expired recommendations, changed quotes, insufficient balances, invalid reward claims, duplicate confirmations, and ownership violations.
Those scenarios rarely appear in launch screenshots. They help determine whether the screenshot’s promise survives everyday use.
What’s next: make the experience clearer, then measure it
The next direction I want us to pursue is making these connected experiences easier to use and easier to evaluate.
That means improving discovery, learning where conversational ordering helps or creates confusion, and giving operations clearer visibility into reward and delivery exceptions.
It also means measuring the outcomes that deserve a future engineering post: completed checkouts, useful AI recommendations, fulfilled rewards, and sustainable incentive costs.
Ile-Ife gives us a concrete community to build for and learn from.
The ambition is to turn that local understanding into software that can serve people in many more places.
Build the feature. Earn the trust.
Two months of engineering has connected AI ordering, rewards, delivery benefits, vendor tools, and rider appreciation.
The thread running through them is trust: understanding the request, preserving the price, respecting ownership, and making repeated actions safe.
That is the Foodmartex we are building.
If you are in Ile-Ife, follow Foodmartex and tell us which everyday food or delivery problem you want solved. If you build commerce software, share the edge case that changed how your team designs a feature.
What looks like a tiny feature in your product but hides the most engineering underneath?
