On demand app development and marketplaces that reach liquidity.

A two-sided marketplace is a platform where two distinct groups - typically buyers and sellers, or customers and providers - transact with each other, and the platform earns from facilitating that exchange rather than from owning inventory. EzLicence connects learner drivers with driving instructors. 1MAC connects anaesthesia providers with the facilities that need them. The defining challenge is that neither side turns up for an empty platform, which is why liquidity, not features, decides whether these products live or die.

By deciding which side is genuinely harder to acquire and designing the product so that side gets value on day one, before the other side exists. That often means the first version is not a marketplace at all - it is a single-sided tool that becomes a marketplace once supply is dense enough. We work this out during Scoping and Design, because it changes the product, the go-to-market and the cost. Getting it wrong is the most common reason marketplace builds fail.

On-demand apps add real-time matching and fulfilment to the marketplace pattern: live availability, dispatch or booking logic, tracking, and time-sensitive notifications on both sides. Technically that means scheduling, geolocation, push, and a payment flow that can authorise now and capture later. It is a harder build than a listings marketplace and worth it only when immediacy is genuinely the value.

You need to take money from one side, hold it while the service is delivered, and pay the other side reliably, while handling refunds, disputes and cancellations. That usually means a payment platform supporting split payments and delayed payouts, plus identity verification on the supply side. We do not quote third-party fees here because they change - see the provider's current pricing. What we do is design the money flow before the build, because it constrains everything else.

A focused first version is typically a matter of months, not years, and deliberately narrower than founders expect - usually one category, one city, or one use case, so liquidity is achievable. Scoping and Design comes first and typically runs $35,000 to $65,000. Development follows the scope that phase produces. We would rather ship a narrow marketplace that reaches liquidity than a broad one that never does.

Yes. We took EzLicence from Australia to the United Kingdom, localising the product for a different regulatory and licensing environment rather than simply changing the currency. The technical work is usually smaller than the operational work: pricing, compliance, supply acquisition and support all change. We scope those explicitly because they, not the code, decide whether the expansion works.