Every website project begins with enthusiasm and ends, too often, with a backlog nobody can finish. Stakeholders add features, designers add variations, marketers add trackers, and the launch date drifts. Behind most of this drift sits a handful of beliefs about what a good web project must include. This article tests six of them and argues for a more disciplined habit: writing down which inputs, requests and trends the project will ignore, so the team’s limited attention lands on the pages and flows that decide whether the site works.<\/p>\n
The evidence for this habit is mostly structural. Attention does not scale with team size, and every new item on a list competes with every old one. Teams that record what they are leaving out tend to make clearer trade-offs than teams that only track what they are adding. Here are the myths that get in the way.<\/p>\n
Feature checklists copied from other sites are a reliable source of scope growth. Live chat, pop-ups, mega menus, animated counters: each one has a cost in build time, page weight and maintenance. The fact check is simple. Ask what each feature is for, which visitor action it supports, and who will look after it six months from now. Features with no clear answer belong on the ignore list for launch. Planning guidance such as the step-by-step approach to preparing a business site before development begins<\/a> makes the same point from the other direction: scope is decided before the build, not discovered during it.<\/p>\n Many project managers say yes to avoid friction. The result is a backlog of half-promises. Declining with a stated reason is more respectful than agreeing and then quietly never delivering. A short entry such as “not in this release, revisit after launch review” gives the requester a date, which is more useful than a vague yes. The evidence from daily practice is that people accept a clear no much more readily than a long silence.<\/p>\n Publishing volume is not the same as search strength. A site padded with thin pages gives visitors more places to get lost and gives the maintainers more content to keep accurate. A better approach is to decide which pages truly serve visitors and let the rest go unwritten. The structural overview in a guide to the pages a company website really needs<\/a> is a useful anchor when deciding what to skip, because it frames the question around necessity.<\/p>\n Testing is valuable, but testing everything is a form of procrastination. If a button colour or a headline variation could not plausibly change a decision, it does not deserve a slot. Teams can write a rule: no test unless we can describe, before running it, what we would do with each outcome. Variations that fail this rule are ignored by default. That keeps experimentation focused on changes with a chance of mattering, such as the layout choices discussed in the article about homepage design and the first impression it leaves<\/a>.<\/p>\n Content management and marketing platforms release updates constantly, and commentary about each one is endless. Most of it does not affect most sites. The sensible alternative is to name the two or three sources you will follow for changes that touch your stack, and treat the rest as optional reading. Security notices for the software you actually run are in; speculation about features you have not adopted is out.<\/p>\n This is the most reasonable worry, and the answer is a review point rather than a refusal to list. Keep a holding area for items that were skipped, and revisit it at fixed moments such as the end of each sprint or a month after launch. Anything that keeps resurfacing, because customers or analytics keep pointing at it, earns a place. Anything that never resurfaces confirms the decision. In effect, the list is a hypothesis with an expiry date.<\/p>\n Behind each belief sits the habit of treating adding as safe and subtracting as risky. In practice the reverse is often true: every unnecessary addition carries upkeep, introduces more places for defects and takes review time from the parts that matter. A visible not-to-do list changes the default. Instead of asking “why not add this?”, the team asks “what are we giving up if we do?”<\/p>\nMyth 2: “Ignoring a request is the same as disrespecting the requester”<\/h2>\n
Myth 3: “More pages mean more visibility”<\/h2>\n
Myth 4: “Every design variation deserves a test”<\/h2>\n
Myth 5: “Staying current means following every platform change”<\/h2>\n
Myth 6: “An ignore list will make the team miss something important”<\/h2>\n
Why subtraction feels riskier than it is<\/h2>\n
How to build the list for a web project<\/h2>\n
\n
A note on research habits<\/h2>\n