Build or Buy a Delivery Marketplace: A Template Saves the Boring Two-Thirds

Build or buy is almost always argued as a price comparison, and the prices are so far apart that the argument ends immediately. A source-code template is tens of dollars. An agency quote for the same described product is tens of thousands. Put those two numbers next to each other and there is nothing left to discuss, which is the clearest sign that they are not the two numbers that matter.

A template removes the work that is well understood, and none of the work that is hard. Both halves of that matter. The first half is why buying is usually correct. The second is why buying does not shorten the road to a working business by nearly as much as the price difference implies.

Where the months actually go

Take a four-surface delivery marketplace — customer app, rider app, vendor app, admin panel — and write out the work honestly, in engineer-weeks, for a competent team that has built something adjacent before:

                                            engineer-weeks
auth, profiles, saved addresses                     3
catalogue, search, cart                             5
checkout and payment plumbing                       4
order lifecycle across four surfaces                6
rider app: offers, navigation, proof of delivery    5
vendor app: accept, prep times, opening hours       4
admin: CRUD, moderation, reporting                  6
push, receipts, transactional email                 2
                                                 ----
                                                   35

dispatch tuning                                     ?
delivery zone design and iteration                  ?
unit economics: fees, commission, subsidy           ?
support tooling and dispute handling                ?

Thirty-five weeks is roughly eight months of one engineer, or a bit over two months of a team of four, and every line above it is a solved problem. Not easy — solved. There is a known-good shape for a cart, a known-good shape for an order state machine, and no competitive advantage available in either.

The four lines with question marks are not estimates because they are not estimable. They are not features you finish; they are settings you keep changing for as long as the business exists, and their correct values are specific to your city, your couriers and your margins.

The two-thirds a template removes

Everything above the line is what you are buying. That is genuinely most of the build, and the reason buying wins for most people is not the price — it is that those eight months are months in which you learn nothing about your market. You cannot discover that your delivery radius is too wide by writing an address form.

The second thing you are buying is the integration work between surfaces, which is where homegrown builds lose time they did not budget. A cart is easy. A cart whose state is consistent with a rider app, a vendor tablet and an admin panel that can all mutate the same order is the part that produces the bugs, and it is the part a working template has already resolved one way or another.

The third it does not

Dispatch is the clearest example. Assigning orders to riders looks like a one-line problem and is a matching problem, and the difference shows up as delivery times rather than as a crash. No template ships with the right batch window or the right idle bonus for your market, because those numbers do not exist independently of it.

Zones are the same. The polygon a template gives you is an empty shape, and drawing the right one takes a person with local knowledge plus several weeks of completed-delivery data to correct them with. Unit economics are the same again: what you charge for delivery, what commission a vendor accepts and how much of the first is subsidised by the second is the actual business model, and it arrives as a spreadsheet argument rather than a pull request.

What these four have in common is that a template ships each of them as a mechanism with no correct setting in it:

knob                     template ships    the value comes from
dispatch batch window    a constant        your acceptance data
rider idle bonus         off               retention in the quiet zones
zone polygons            empty             someone who knows the city
delivery fee             flat              margin at each basket size
commission rate          flat percentage   what vendors will actually sign

Nothing in the right-hand column exists before you are trading. That is the whole reason the hard third cannot be bought — not because vendors withhold it, but because it is a description of your market rather than of the software.

Running costs belong in this third too, and they are not a fixed property of the stack you bought. The running-costs post prices a thousand-order month properly; the short version is that the fixed floor is a few hundred pounds a year, and the variable part swings by two orders of magnitude depending on how you stream rider location. That is a decision about your code, not about your vendor, and buying a template neither makes nor prevents it.

What buying actually costs

Be honest about the other side. You inherit a codebase you did not write, in someone else's idiom, with their naming and their architectural choices already made. The first substantial feature you add takes longer than it would in code you wrote, and the second takes about as long as normal. That gap is real and it is the price of the thirty-five weeks.

You also inherit their dependency choices. If the template is built on a backend you would not have picked, you are either living with it or paying to replace a load-bearing part of something you bought precisely to avoid building. Read what the backend is before you read the feature list, because features can be added and a backend cannot easily be swapped.

And support has a shape. Six months of author support means answers about how the project is put together — not someone building your roadmap. A template is a starting codebase, not a supplier relationship, and treating it as the latter is the most common way buyers end up disappointed by something that worked exactly as described.

When building from scratch is the right call

Three situations, and only three. The first is when the hard third is the product — if your entire proposition is a dispatch algorithm nobody else has, the thirty-five weeks of surrounding app is table stakes you still need, but you cannot buy the part that matters and building around it may be cleaner than retrofitting.

The second is a genuinely unusual domain model. Delivery templates assume a basket of items from a vendor, delivered by a courier, paid for at checkout. If your business is scheduled multi-day rentals or route-based recurring drops, you will spend longer fighting the assumptions than you would have spent making your own.

The third is regulatory. Pharmacy, alcohol, controlled goods and anything requiring identity checks at the door impose requirements that touch every surface. Bolting those onto a codebase that never anticipated them is worse than designing for them from the first commit.

What to decide first

Do not start from the price. Start by writing down the four question-mark lines for your own business and asking whether you have answers. If you do not — and almost nobody does before launch — then the thirty-five weeks above them is not the thing standing between you and a business, and paying to skip it is the cheapest decision available.

If you do have answers, and they are unusual enough that no existing codebase expresses them, you have found the one case where building is the shorter path. That case exists. It is much rarer than the number of people who believe they are in it.