Assumptions aren’t bad. Invisible ones are.

We all make assumptions… in life, in business, and in software engineering. Without them, nothing would ever ship.

In web development, assumptions shape architecture, APIs, UX design, performance, and even security. There is nothing inherently wrong with making them.

The danger is not realizing you’ve made them.

Here are some common assumptions on:

• The Device: "No one will use this on mobile, or a tablet (or a smart toaster)."
• The Scale: "The app will only be used in this country, in this one language."
• The Happy Path: "Users will only ever use the feature as intended."
• The Source: "The requirements were written by someone who truly understands the business."
• The Infrastructure: "The database write will always succeed."
• The Intent: "The user wants the software to work properly.”

That last one sounds silly until you remember that not every actor that interacts with your systems is friendly, legitimate, or even human.

Assumptions are necessary.

You can’t build software for everyone, everywhere, all at once.

Engineering requires constraints. It requires intentionally choosing what not to support

So what’s the problem?

❌ Assume the network never fails? You skip the retries and fallbacks.
❌ Assume the database is invincible? You ignore write failures or do not create backups.
❌ Assume users are logical or well-intentioned? You miss the edge cases that crash the UI or don’t properly configure the permission system.

When reality hits, your system breaks.

So what do we do?

✅ Make assumptions explicit: if it matters, document it.
✅ Challenge requirements: Your job isn’t to blindly implement features. Understand the real goal and propose better solutions when necessary.
✅ Design for failure: Networks fail. Disks fail. Humans fail. Plan for it.
✅ Revisit assumptions regularly: as your system evolves, so too do your assumptions.

Assumptions aren’t evil; unacknowledged ones are. As the Zen of Python says, explicit is better than implicit.