The case against surge pricing
Surge solves a coordination problem cleverly. It also passes the cost of that problem from the platform to the customer at the moment they can least afford it. Here's why Helpward doesn't.
Surge pricing is an elegant solution. When demand spikes and supply doesn't move, prices rise; some demand evaporates; supply gets pulled in by the higher rate; equilibrium is restored. It's the textbook market-clearing mechanism, working as designed.
The argument against surge isn't that it's economically wrong. It's that the conditions under which it triggers tend to coincide with the moments customers are most vulnerable. Storm warnings. Concert end times. Bar close on New Year's Eve. These are exactly the moments where someone needs the service, and exactly the moments where dynamic pricing extracts the most. The mechanism is value-neutral; the timing isn't.
What surge is actually fixing
Surge is fixing a coordination problem on the platform's side. The platform can't reliably know who's available to work right now; the workers can't reliably know where demand will be; the platform's response is to use price as the signal that brings both sides into alignment.
Price is a fast signal — it works immediately. It's also a regressive one. A surge multiplier hits a customer at 11pm in a snowstorm equally regardless of their ability to absorb it. The mechanism doesn't distinguish between a customer who can shrug at 2.5x pricing and one who'll forgo the booking and walk home in the cold. The mechanism doesn't try to distinguish.
What we do instead
- Pre-position incentives for helpers. We pay a flat top-up for helpers who go online during forecasted demand windows — weather alerts, major event end times. The cost is borne by Helpward, not surfaced to customers as a higher booking price.
- Honest ETA badges. When supply is genuinely thin, the live ETA on our service cards shows it. 'Starts at 11pm' is a more honest signal than '2x surge in effect' — customers can decide whether to wait or to look elsewhere.
- Service-specific supply ramps. We over-recruit for services that show seasonal demand spikes (driving services in winter, errand-runners around the holidays). The marginal cost is real but bearable as a sustained operating expense.
- Cap on busy-day cancellation penalties. When supply is thin and helpers cancel because they were overcommitted, we waive the typical penalty. We'd rather hold the helper's enthusiasm for the platform than enforce a fee that suggests the platform's contract supersedes the helper's life.
What we accept as the trade-off
These choices have a cost. Without surge, Helpward's response time during demand spikes is worse than competitors who do surge. We can see it in the operational metrics; we'll publish it in the quarterly transparency report at /safety/transparency-report. We don't think this is a hidden cost — we think it's the cost of the position.
Some customers will book us during normal hours and book a competitor during a storm because the competitor can dispatch faster at the cost of a multiplier. That's a reasonable decision the customer can make. Our pitch isn't 'we're the fastest in every condition'; it's 'we won't extract from you at the moment you're most vulnerable, and the operational choices that make that promise true are visible'.
Is this sustainable?
We don't know yet. The honest answer is that no on-demand marketplace has run at scale without surge as a release valve, so we can't point to a 10-year case study and say 'yes, the economics hold'. What we can say is that the operational costs of running without surge are bounded — pre-positioning incentives and over-recruitment are line items with knowable budgets — and that the trust signal from running without surge has measurable value in the parts of the booking funnel we can observe.
We'll know in a year. The transparency report will surface the data either way — if it turns out that running without surge isn't sustainable at our scale, we'll say so and revise the position publicly. The position itself isn't the point; the willingness to defend it with operational mechanics rather than press releases is.
- Founding storyWhy we built HelpwardThe on-demand economy already exists. We didn't need another marketplace — we needed a marketplace that earned the booking instead of optimising for it.
- Trust & SafetyHow we vet every helperThe end-to-end path from application to approved: identity verification, background checks, adjudication policy, and the human review that runs through all of it.