Why Our Food Marketplace Asks for a Quote Before It Takes Payment

Food delivery apps are built for one kind of order: one person, a fixed menu, a fixed price, a card payment and food in half an hour. For that order, the model is excellent. For most of the food that gets bought for groups, it does not fit at all.

Think about how those orders really happen. A church needs plates for a Sunday event. A family is planning a birthday. An office wants lunch for the whole team on Thursday. A school has an open day. The numbers are not final yet, the date matters more than the speed, and the seller needs to know whether they can do it before anybody commits to a price. Today that conversation usually happens in scattered messages and phone calls — which works, until the quantities are misremembered, the price changes, or nobody can find what was agreed.

RekaDijo is the food marketplace we built for those orders, with Kimberley as its first market. It is quotation-first.

How a quotation works

A buyer finds a seller by searching, browsing food categories, or looking at a map of sellers near their address. From the seller's menu they build a request: the dishes, the quantities, the type of event, the date, and whether they will collect or want delivery.

The seller reviews the request and responds. They can accept it as it stands, revise the prices or quantities, or decline. If it has been revised, the buyer reviews the new version and accepts or declines in turn. Only after the buyer accepts does payment enter the picture, and from there the order is scheduled and fulfilled like any other.

Everyday orders still matter, so sellers can also switch on instant ordering. The same shop page then offers both: Order now for a plate today, and Quote for forty plates on Saturday. One marketplace, two ways to buy, chosen seller by seller.

The rule we would not bend: no payment before agreement

The most important decision in the product is a rule, not a screen. Nobody can pay for a quotation they have not accepted.

That sounds obvious, and it is surprisingly easy to get almost right. A team can hide the pay button until a quotation is accepted and call the job done. But a hidden button is not the same thing as an unreachable payment. So the rule lives in the data itself: until the buyer accepts, a quotation has no payment recorded against it and no order exists at all. Our end-to-end tests check exactly that, rather than checking whether a button happens to be visible.

That protects trust in both directions. Buyers are never charged for something they were still discussing. Sellers are never paid for a job they had not agreed to take on.

Designed for small food businesses

The sellers RekaDijo is for are home cooks, braai spots, kota and takeaway shops, bakers and small caterers — not restaurant chains with operations teams. The product had to meet them where they are:

• Branches. A seller can run more than one location, each with its own address, opening hours and lead time.
• Photographs of their own food. Onboarding asks sellers for a photo of what they cook, and for a short description of it that screen readers can read aloud. A marketplace full of stock photos tells a buyer nothing about what will arrive.
• Verification. A new business stays pending until an admin approves it, and the identity documents used for verification are stored privately, completely outside the public website.
• Drivers. Drivers have their own page to apply, and an unverified driver is never assigned somebody's order.

The onboarding itself is three short steps — your business, where you cook and how you sell — because the easiest way to lose a small business owner is a long form on a small screen.

Deploying it without shortcuts

RekaDijo runs on a shared server, so we treated the deployment as part of the product rather than a last step.

The application runs as its own restricted system user under a locked-down service configuration, so a flaw in the app cannot become control of the machine. It only accepts connections from the web server in front of it, never directly from the internet. And rather than handing a build service the keys to log in to the server, the server pulls each new release itself using a read-only key, so nothing in the code repository could be used to take it over. Two critical security advisories affecting the web framework were patched on the day of deployment, before the site was made public.

None of this is visible to a buyer ordering lunch. All of it matters the day something goes wrong.

What is live, and what is waiting

RekaDijo went live on 11 September 2026. The marketplace, the quotation workflow, instant ordering, seller onboarding and dashboards, messaging, maps and driver sign-up are built, and people can sign in with Google or with email.

The one piece deliberately waiting is the live payment gateway. The PayFast integration, and the webhook that confirms payments, are written and tested — including rejecting unsigned or tampered notifications and ignoring a payment notice that arrives twice. What they need now is the business's merchant credentials, and connecting them is configuration rather than a rebuild.

The lesson

The quickest way to build a marketplace is to copy the one everybody already knows. But the shape of a product should come from how people actually buy — and for food bought for groups, that starts with a question, not a checkout. Building around the quotation, and making the no-payment-before-agreement rule impossible to get around, is what makes RekaDijo fit the orders it was made for.

You can explore it at rekadijo.techtursolutions.com. If your business runs on a process that off-the-shelf software keeps getting wrong, tell us about it.