Ship the interface before the infrastructure is perfect

I keep seeing the same trap: builders spend weeks making the backend elegant before users have touched the product once.

It feels responsible. It is usually a delay.

If the core value of a product depends on an interaction, then the interface is where the first truth shows up. Not the queue design. Not the event schema. Not the orchestration layer.

Why I bias toward interface-first

A rough but usable interface answers questions infrastructure cannot:

• do users understand what this product does
• do they know what to do next
• does the workflow create confidence or friction
• is the value obvious after one minute

Those are first-order questions. If they are unanswered, infrastructure work is often speculative.

This does not mean "ignore engineering"

It means sequence the work correctly.

I still care about clean interfaces between services, idempotent writes, observability, and rollback paths. But I would rather harden a system that users already proved worth using than perfect one they never asked for.

The version I trust looks like this:

1. make the user interaction legible
2. instrument it enough to watch failure modes
3. harden the hot paths people actually hit
4. abstract only after repetition makes the boundary obvious

The practical payoff

Once real people use the product, infrastructure decisions get easier.

You stop debating hypothetical scale and start solving visible pain. The abstractions become narrower. The performance work becomes targeted. The code gets better because the product got clearer.

That is why I like shipping an opinionated first interface early. It forces reality into the room.