It always starts the same way.

“Can we just do it like this?”

At that moment, it sounds simple.

• A clean idea.
• A neat flow.
• A straight line from A to B.

Then reality shows up.

• We can do it like that. But the system doesn’t store that field.
• We can do it like that. But this platform only lets us use email, not API.
• We can do it like that. But finance needs it to stay inside their old tool.
• We can do it like that. But the only reliable trigger is a weird exported CSV someone downloads by hand every morning.

And honestly, that’s normal.

A lot of automation ideas sound elegant at the whiteboard stage.

Then you meet the actual business.

• One tool is half-configured.
• Another one has no write access.
• A third one is technically replaceable, but politically untouchable.

So the final solution ends up looking a bit strange.

And that’s fine.

Because this is where the interesting part starts.

Not in the ideal version.

In the constraints.

That’s where you stop designing for imagination and start designing for reality.

Sometimes the most useful system is not the cleanest one.

It’s the one that works with the weird setup that already exists.

• An Airtable base with missing fields.
• A CRM where one column does three different jobs.
• A booking flow that only works if someone confirms the payment manually.
• A process that should be automatic, except one step has to stay in WhatsApp because that’s how the team actually operates.

From the outside, that can look messy.

From the inside, that’s the real work.

Anyone can draw a beautiful process when nothing gets in the way.

The interesting question is different:

Can you build something useful when the system is incomplete, limited, slightly irrational, and still held together by habits?

That is usually where the real design starts.