It is easy to design software for the demo: a fast laptop, a strong connection, an unhurried user clicking exactly where you expect. It is much harder, and much more useful, to design for a tired musician on a cruise ship in the middle of the ocean, on Wi-Fi that drops every few minutes, trying to sort out a document before a deadline they cannot miss. Building for that person changed how I think about building anything.

The conditions are the constraint

The first lesson is that the conditions your software runs in matter more than almost anything on the feature list. At sea, the connection is slow and unreliable. The device is a phone, not a desktop. The person is busy, often stressed, and rarely has a second chance before the ship sails. Those are not edge cases to handle later. They are the main case, and once you accept that, they drive nearly every decision.

An app that assumes a good connection is not “mostly fine with occasional issues” for this user. It is broken, at the exact moments it matters most.

What designing for the worst day forces

• Resilience over cleverness. The upload that survives a dropped connection beats the elegant one that assumes the connection holds.
• Speed as a necessity, not a nicety. When someone has a narrow window and a flaky link, every needless second is a real risk of not finishing.
• Plain, honest communication. A stressed person needs to know exactly what happened and what to do next, in words, not a vague spinner or a cryptic code.
• Forgiveness. People make mistakes when they are tired and rushed. The software should let them recover, not punish them.

The surprise: it helps everyone

Here is the part I did not expect. Designing for the hardest conditions did not produce software that was worse for everyone else. It produced software that was better for everyone. The resilience that saves a musician on bad ship Wi-Fi also quietly saves an office worker whose train goes through a tunnel. The speed that matters desperately at sea is simply pleasant on a fast connection. The clear error message that rescues a stressed person also reassures a calm one.

The worst case turned out to be the best design brief. Aim at the person having the hardest day, and you accidentally take care of everybody having an ordinary one.

The principle I took away

Most software is built for the best case and then patched, reluctantly, towards the worst. I have come to believe it should be the other way around. Decide who your hardest user is — the worst conditions, the most pressure, the least room for error — and build for them first. It is harder. It forces you to confront the unglamorous things, the failures and the edge cases, up front rather than never.

But the result is software with a kind of quiet sturdiness you cannot fake by polishing the happy path. The musician at sea will never know how much thought went into the moment their upload survived a dropped connection. They will just know it worked when they needed it to. That, in the end, is the whole job.