A website project usually starts with optimism. The developer was chosen carefully, the contract was signed, and the work has begun. The early weeks feel productive. Then, somewhere in the middle of the project, things start to feel off — but the client cannot quite say why, or whether the unease is justified.
There are specific signals that indicate a project is going wrong, and most of them appear well before the client realizes the project is in trouble. Recognizing them early is the difference between course-correcting and salvaging.
Communication That Becomes Harder
The first signal is communication that becomes harder to maintain. At the start of the project, the developer responded the same day. By week three, responses take two days. By week six, the developer has gone silent for a week and reappeared with an apology and a vague update. Communication patterns reveal workload patterns. A developer who is not responding has either taken on too much work, is avoiding a difficult conversation, or has lost interest in the project. None of those situations end well without intervention.
Progress That Cannot Be Shown
The second signal is progress that cannot be shown. A reasonable developer can demonstrate work in progress at any point. Even messy, unfinished work is visible. A developer who consistently has nothing to show — “it is on my local environment, I will push it next week” — is either not working on the project or is hiding something about the state of the work. Either reason is concerning.
A Single-Number Quote
The third signal is a quote that mostly comes in the form of a single price. A serious developer breaks down a project into phases, deliverables, and decisions. The breakdown does not have to be exhaustive, but it has to exist. A quote that says only “website build: $X” with no scope behind it sets up disputes later about what was included, because nothing was specified.
Dismissal of Technical Questions
The fourth signal is the developer dismissing the client questions about technical decisions. Some questions deserve technical answers and some deserve simple ones, but the answer should never be “do not worry about it.” A developer who is unwilling to explain platform choices, plugin selections, or hosting decisions is either uncertain about the answers or planning to use those choices to create lock-in that benefits them later.
Changing Scope Without Changing Price
The fifth signal is a rapidly changing scope without rapidly changing prices. Some scope changes are normal. The site grows, the client adds requests, the developer absorbs small additions. But large additions should change the price or the timeline, and a developer who keeps absorbing them silently is either underbidding now in a way that will become a problem later or adjusting the work to compensate by cutting corners that will not be visible until launch.
The Absence of a Written Record
The sixth signal is the absence of a written record. A serious project produces written confirmations of decisions, scope changes, deliverables, and timelines. Verbal agreements that never get documented become disputes later when one party remembers them differently. A developer who resists writing things down is making sure they cannot be held to specific commitments.
Demands for Full Payment Up Front
The seventh signal is requests for full payment before completion. Standard practice is a deposit at the start, milestone payments through the project, and final payment at launch. A developer who wants the entire fee paid up front is either solving a cash-flow problem at the client expense or planning not to finish. Either way, the leverage shifts entirely in the wrong direction once the money is gone.
A Developer Who Does Not Ask Questions
The eighth signal is the developer not asking enough questions. A good developer asks about the audience, the goals, the existing content, the integrations, the maintenance plan. A developer who jumps straight into design without asking these questions is going to deliver a site based on assumptions, and those assumptions are unlikely to match what the business actually needs.
Tooling That Locks You In
The ninth signal is exclusive use of the developer tooling. The site is built in a proprietary platform that only the developer can edit. The credentials are held by the developer. The hosting is on the developer account. Each of these is a small lock-in that, by launch, makes the client completely dependent on the developer. Some of this is reasonable during a project. None of it should be permanent at the end.
Disappearance During Testing
The tenth signal is the developer disappearing during testing. The build felt fast. The launch is approaching. Suddenly, fixing bugs takes a long time, and the developer becomes hard to reach. This pattern is common when the developer interest in the project peaked during the design phase and has now waned during the unglamorous final stretch. The work that finishes a site is less satisfying to do than the work that starts it, and developers who cannot finish well leave clients with sites that almost launched.
Signals From the Client Side
There are also signals that come from the client side that should be addressed honestly. Disagreement among the client team about what the site should be. Decisions made late and revisited often. Content that arrives in pieces. Feedback that contradicts itself across rounds. These are not the developer fault, but they can derail a project even when the developer is doing everything right. A serious developer will name them when they appear, and a serious client will hear it and respond.
What to Do When Red Flags Appear
When red flags appear, the response is not to immediately end the relationship. It is to name what is happening and ask for a direct conversation. Most issues that look like fundamental problems are actually communication problems, scope problems, or capacity problems that can be solved if both sides are willing to address them. The issues that cannot be solved that way are the ones that justify more difficult decisions — bringing in another developer, renegotiating terms, or accepting that the project needs to restart with someone else.
The cost of recognizing a red flag in week four is much smaller than the cost of recognizing it in week twelve. Most failed website projects produced clear warning signs months before they failed. The clients who paid attention saved themselves months of work. The clients who did not are the ones who later say they wish they had said something sooner.