Edge Case

Specs used to describe only the path where everything goes well. "Click the invite link and you join the team" felt like a complete description of a screen, and nine screens out of ten built that way worked fine. The tenth was the problem. What happens when the person clicking is already on the team, when the person who sent the link has left the company and their account is gone, or when two people click the same link at the same second — none of that was written down anywhere.

What nobody writes down doesn't disappear. It lands on the engineer's desk. Writing the code means reaching that exact branch, and with nobody around to ask, the engineer decides alone. One screen silently ignores it, another throws an error, a third processes it twice. That is usually why the same situation behaves differently on every screen of the same product.

Then the answer arrives as a support ticket. Someone writes in to say that clicking an invite created two teams, and only after opening the code does anyone realize the case was never decided. If the quick fix goes unwritten again, the same argument comes back around in six months at the same spot.

Edge case is the name given to that blank. Once the blank has a name, someone can ask "have you gone through the edge cases?" in a planning meeting, and a question that can be asked is a question that can be answered before the code exists.

Edge cases surface by walking back through the normal flow one step at a time and pushing an extreme value into each step. It isn't a task that waits for inspiration; the sweep has a fixed shape, and the values you push in come from three axes.

1. Both ends of a quantity — try zero and try the maximum. What does the dashboard of a team with no members show? If a team shrinks its seats to eight while nine people are already inside, who gets removed?
2. The edge of a time window — try the instant that lands exactly on a cutoff. Someone who cancels on the billing date itself, someone who pays at 11:59 p.m. on the last day of a free trial.
3. The same thing twice — take something assumed to happen once and make it happen twice. A payment button pressed twice in a row, or two people deleting the same document at the same moment.

Not everything found this way is worth handling, so a filter comes next. Two questions decide it: left alone, does money or data end up inconsistent, and is the person who hits it inconvenienced enough to contact support? If either is true, the case gets decided now, however rare it is.

This is where the relationship with business rules becomes visible. A business rule is a condition the domain requires — "paid seat count can never fall below the number of people actually in the workspace" — and breaking it means the money stops adding up. An edge case is a point where that condition wobbles. With the rules written first, the places worth inspecting announce themselves; hunting for boundaries without them leaves you no yardstick for deciding what counts as a problem.

The word travels through three places: writing down what to build, checking that it got built, and deciding what the product does when the flow breaks.

1. Spec document — the document that describes screens and behavior in enough detail to implement. After the normal flow, it carries a separate "exceptions" block where each boundary gets its own line. A spec with that block empty is a spec that is half written.
2. Acceptance criteria — the conditions for calling a piece of work done. Edge cases turn into checkable items here. "Reducing seats below the current headcount blocks the save and shows an explanatory message" is something a quality assurance (QA) engineer can click through and verify.
3. Exception policy — what the product actually does once the flow breaks. Without the list from the step before, there is nothing to write this document about.

"That's an edge case, so let's leave it out of this sprint and look at it later."

A rare situation gets deferred. Deferred is not the same as nonexistent, so the sentence only works if it comes with a decision about where the case gets recorded.

"Send me the edge cases and I'll turn them straight into test cases."

The list of boundaries becomes a list of checks. Without that list, testing covers the happy path and nothing else.

"This isn't an edge case. Twelve percent of our customers land here."

A number overturning the judgment that something is rare.

At Pagedeck the word ran through every meeting about the seat-reduction feature. Mia opened the draft spec and walked the flow step by step with Theo. What happens when the number is set to zero, who gets removed when it drops below the current headcount, and which side wins when another admin is inviting someone at the exact moment the count shrinks. Twelve cases came out, five of them broke the billing math, and those five got a decided behavior on the spot.

Sofia filtered the other seven. Digging through support history showed that two had already come in from real customers; the remaining five went into the exceptions block of the spec and stayed unbuilt this round.

The most common call is that rare means it can wait. Three people in a thousand doesn't feel urgent, and it is the first line item cut when a deadline tightens. But those three people don't quietly move on — they file a ticket or stop paying. Three tickets a month means support time, plus an engineer opening the code each time, accumulating for as long as the gap stays open. Thirty minutes of work during the build turns into several days spread across a year.

Treating it as a synonym for bug is the other frequent slip. Both surface in unexpected situations, so they look alike. A bug is behavior that doesn't match what was decided; an edge case is a situation nobody decided about. The distinction matters because the repair differs. Fixing a bug means changing code, while an undecided situation needs someone to settle what the correct behavior even is before any code changes. Blur the two and an item closed as "fixed" carries behavior nobody ever agreed to.