Uncategorised

Same hotel. Same room type. Same number of guests. One weekend apart. The listing on the left is €2,540 per night; the one on the right is €168 at the Raddison Hotel in Dublin City centre. Whatever combination of demand, events, occupancy forecasts, and algorithmic enthusiasm produced the higher figure, it raises a bigger question than whether one room was overpriced on one particular weekend.

It asks whether dynamic pricing, as currently practised, still has any meaningful ethical boundary.

The standard defence

The argument is familiar:

• Supply tightens, demand increases, prices rise
• Hotels, airlines, taxis, and ticketing platforms all use this logic
• It’s presented as neutral, efficient, even inevitable
• The market moves; prices follow.

But that description hides something important. Dynamic pricing isn’t simply a mirror reflecting reality. It’s a choice about how aggressively a business responds to scarcity. And like any choice, it can be made with restraint — or without it.

Where the discomfort starts

Most people don’t object to prices changing. They object to prices becoming unmoored from any ordinary sense of proportion.

A moderate increase feels annoying but understandable
A 15x markup on the same room one weekend later feels different — it doesn’t suggest healthy market responsiveness, it suggests a business has decided that urgency, limited alternatives, and customer need are opportunities to be fully exploited

The defenders of this kind of pricing tend to retreat into narrow economic logic: if someone will pay it, the price is justified. But willingness isn’t the same thing as fairness.

A person may pay because they’re stranded, under pressure, attending an important family event, or left with no viable alternative. The transaction may be voluntary in theory while feeling coercive in practice.

Markets are very good at discovering what people can be made to pay. They’re less good at determining what ought to be charged.

The real issue: indifference

Ethical business behaviour has always required more than technical market efficiency. It requires judgement — recognising that the most profitable option isn’t always the most legitimate one. Reputation, trust, and basic decency should impose limits that an algorithm never will on its own.

And that’s the real problem with dynamic pricing in its most extreme form. It’s not merely that it’s expensive — it’s that it’s indifferent.

No person has to stand over the number and defend it. No one has to say, publicly, that a hotel room available for €168 next weekend is worth €2,540 this weekend because the software says demand is high enough. The machine produces the number, and the business takes cover behind the language of “optimisation.”

Customers aren’t fooled by this arrangement. They may not know the formula, but they know the feeling: this company charged the maximum it believed the situation would bear.

That may be smart revenue management. It may also be a slow erosion of trust.

So where does that leave us?

Dynamic pricing isn’t going away. Nor should it — there are sensible and defensible uses for it. But businesses that rely on it should stop pretending that every market-clearing price is automatically a morally respectable one.

A society that accepts this logic without question eventually ends up treating urgency as a luxury good.

And that’s a far more troubling price than anything on a hotel website.

There’s a pattern I keep seeing in product teams: we aim for the “right” version of something, and in doing so, we never actually ship the useful version.

Nobody wakes up intending to slow things down. It happens gradually:

• We add one more abstraction “because we’ll need it later,”
• We align the design system,
• We make it extensible from day one,
• We wait for the other team to catch up, and
• Suddenly the customer has… nothing.

So this is a post about resisting that pull and a few principles you can use when you feel the work drifting away from real users.

---

1. Perfect is usually optimized for us, not for customers

When teams say “let’s do it properly,” they’re almost always talking about internal satisfaction: elegant code, unified UI, one way of doing things, future-proofing.

Customers do not care.

Customers care about:

• Can I do the thing?
• Are the numbers right?
• Is it faster than the way I do it today?

If the answer to those three is “not yet, we’re still designing the framework,” that’s a smell. That’s when “perfect” has won on the inside and “useful” has lost on the outside.

Principle: if the work looks impressive in a demo to your colleagues but invisible to a customer, you’re optimizing the wrong audience.

---

2. Momentum > completeness

A lot of products get stuck because they try to do two hard things at once:

• Replace or clean up the old way, and
• Introduce a better, new way.

Doing both simultaneously sounds responsible, but in practice it doubles the surface area, doubles decisions, and makes it harder to declare anything “done.”

It’s almost always better to pick one axis:

• either: “We’re cleaning up what exists, no new scope.”
• or: “We’re adding net-new value, we’ll redo the old thing later.”

Trying to do both is how you end up with PM notes like “blocked on design direction” for weeks.

Principle: reduce simultaneity. Ship on one dimension at a time.

---

3. The hidden tax of “doing it right”

“Let’s do it right” sounds mature, but it has a hidden cost:

• It introduces new dependencies (on platform, on design systems, on other teams),
• It raises the minimum viable release to something non-minimal,
• It makes it harder to test with real users because nothing is small anymore.
• What people call “right” is often just “more coordinated.”

Coordination is good. But coordination is not value.

Principle: don’t let “future-proof” outvote “presently useful.”

---

4. Ship the observable thing first

You can’t learn from a Figma file. You can’t learn from an architecture diagram. You can only learn from something a real person used, even briefly.

So a good forcing question is:

“What is the smallest version of this work that a real user can see and tell us something about?”

It’s not:

• “What’s the smallest version that makes the system elegant”, or
• “What’s the smallest version that supports every extension”, or
• “What’s the smallest version that marketing can make a full launch page for.”

Just: can someone use it and react?

Principle: if you can’t put it in front of 3 users this week, it’s too big.

---

5. Defer platformization

Teams love to build for “everyone who might use this later.” That’s how you end up with general-purpose, no-purpose features.

There’s a better order:

• Build the thing for you (your current use case),
• Let it prove itself,
• Then harden it for others.

This feels backwards to some people and you may hear some shouting: “We’ll have to refactor!” But, refactoring a working, used feature is always easier than resurrecting an unused, overbuilt one.

Principle: make it useful, then make it reusable.

---

6. Say what you’re not doing

A lot of scope creep is just unspoken anxiety.

• Design worries: “Will we have to redo this for mobile?”
• Engineering worries: “Will this scale when we add X?”
• Product worries: “Will partners be angry we didn’t make it extensible?”

If you don’t name the boundaries, people will quietly build for the biggest possible future.

So write it down, for example:

• This version is web-first.
• This version is for internal data only.
• This version is not extensible.
• This version is about visibility, not automation.
• This version is for 1–2 key personas.

When you do that, it becomes much easier to ship something small without everyone feeling like they failed the imaginary final state.

Principle: constraints make shipping emotionally safe.

---

7. Lead with the commercial / outcome story

One more thing that helps: tie the smaller, shippable version to an outcome that leadership cares about.

Examples:

• “Shipping this thin slice unblocks real-user feedback in the same quarter.”
• “Getting this out gives us retention / activation data we can’t get from mocks.”
• “A narrow v1 reduces migration/support until we know merchants actually want it.”

When there’s a clear business reason to ship small, it’s much harder for “let’s just make it perfect” to win the argument.

Principle: small releases need a big why.

---

8. How to spot you’re drifting into perfectionism

You can almost diagnose it from meetings:

• “Let’s wait until the component library is ready.”
• “Let’s not show it to users until we can tell the whole story.”
• “Let’s solve this for all products / all regions / all payment methods.”
• “Let’s figure out the long-term IA first.”
• “Let’s make it consistent with the future experience.”

None of those are bad sentences. But if they appear before anyone has seen a working version, you’re in danger territory.

Principle: if future concerns show up before present value, you’re drifting.

---

9. The stance

If I had to compress this into one stance, it’s this:

Shipping is how we find out. Perfect is how we postpone finding out.

You don’t discover reality by thinking harder. You discover it by putting something small, slightly embarrassing, slightly incomplete in front of the people you’re actually building for.

If it lands, great, you’ve earned the right to make it nicer.
If it doesn’t, great, you found out early and have not over invested.

Either way, you’ve learned from real world feedback, from your customers who pay to use your product.