Why nobody gives you a straight answer about progress
The update has said eighty percent for three months. The invoices keep arriving on time, the meetings are cordial and well attended, everybody involved sounds busy, and yet that number has not moved since the spring. You are not being paranoid, and in most cases you are not being lied to either. The real problem is that you have been handed a figure you have no way of testing, so the only honest thing you can say about it is that you do not actually know whether it is true.
Sitting underneath that stuck percentage is a distinction almost nobody explains to the person paying the bills. There is activity and there is progress, and from the outside they look identical. Activity is meetings, design revisions, six screens being worked on at once, and small jobs moving across the team's tracking board, which is simply the shared list where every piece of work sits in a column marked to do, doing or done. Progress is narrower and much rarer: one thing a real customer could open and use today that they could not open and use last week. Both cost exactly the same per hour, which is why a project can run at full speed for two months, generate an enormous amount of activity, produce almost no progress, and still sound completely healthy on every call.
It is worth saying plainly that most projects drift at some point. Requirements turn out to be more tangled than anyone realised, a supplier goes quiet, a decision takes three weeks instead of three days. Drift is survivable and it is normal. The expensive part has never been the drift itself, it is finding out about it late, because a project that is four weeks behind in month two can be put right with a single conversation, while the same project discovered in month seven usually costs you a rewrite of the plan, the budget and the launch date all at once.
So here is what this article is for. By the end of it you will be able to judge your own project without knowing what a database is or what any of the tools are called, using five checks you can run in an afternoon and one piece of arithmetic you can do on the back of an envelope. None of the questions are hostile. A good team will be relieved you asked them, because a client who understands the real state of the work is far easier to work with than one who is quietly worrying.
The only evidence that counts is software you can click yourself
Every check in this article rests on one thing, so it is worth defining that thing before anything else. Somewhere there should be a private copy of your system, running on the internet, that only your people and the development team can reach. It is usually called the test site, or staging, and its whole purpose is to let work be tried out before a single customer sees it. If your project does not have one, or nobody can send you the link, stop reading and ask for it today, because the absence of a test site is already a finding: it means nothing has been checked by anyone outside the people writing it.
Once you have that link, one rule replaces every percentage you have ever been given. If you cannot open it on your own phone and use it, it is not done, whatever the report says. Not nearly done, not done apart from a small thing, not done. That sounds harsh and it is not meant unkindly, but it is the only definition that cannot be argued with, and the teams that work to it are usually the ones that hit their dates.
The rhythm that makes the rule workable is a weekly demo, and on custom builds at Linkysoft we run one from the second or third week onward: thirty to forty five minutes in which the client holds the mouse. Not a slide deck being narrated, not a screen recording, not a walkthrough where the developer drives while you watch. You click, you try to break it, you ask why something behaves the way it does. Half the value is in what you discover you did not want, which is far cheaper to find out in week nine than in month six.
The difference this makes is measurable rather than sentimental. Six month builds that run without a weekly clickable demo typically slip twenty five to forty percent, so six months quietly becomes seven and a half to eight and a half. With a weekly demo and a written change log beside it, we usually see that held under ten to fifteen percent, which is the difference between a project that is slightly late and one that has lost a season.
The last piece is agreeing what the word done means, in writing, before it matters. Use four boxes rather than one opinion: built, tested, reviewed by you, and running on the test site. A feature that ticks three of the four is not done, it is nearly done, and nearly done is the state in which projects quietly accumulate months. If you want a sense of everything that actually sits inside a build of this kind, our page on custom web application development sets out the parts that most proposals leave unwritten.
What a real status update contains, and what a vague one hides
A useful status update has three parts and takes about six lines to write. First, what finished since last time and can be clicked, with the link. Second, what is being worked on right now and the date it is expected to become clickable. Third, what is blocked, together with the name of the person who is holding it. That is the entire format. Anything shorter is a mood, and anything longer is usually hiding the second and third parts inside the first.
There is also a vocabulary of softening that is worth learning to hear. Almost, nearly, just polishing, tidying up, waiting on a few things, some integration issues, final touches. None of those words is dishonest and most of the people using them are simply being optimistic, but each one is an invitation to ask one more question, which is always some version of "what exactly is left, and how many days is it?" The strongest warning of all is a sentence with no noun in it, because "we are making good progress on the parts you cannot see" tells you nothing, while "the booking form now saves and sends the confirmation email" tells you everything in the same breath.
Blockers deserve a complete reversal in how you read them. Most owners hear "we are blocked" as bad news when it is usually the healthiest sentence in the whole update, since a team that names its blockers knows precisely where it stands and is asking you to help. A team that never has any blockers across a four month project is not working miracles, it is absorbing the problems silently, and those problems tend to arrive all together at the end.
If you would rather send words than raise a feeling, these three questions do the job and can be copied straight into an email. What can I click on the test site today that I could not click a week ago? What is the single thing most likely to move our launch date, and what would it take to remove it? Which decisions are you waiting on from me, and by when do you need each one? Any honest team answers those in ten minutes, and the quality of the answer will tell you more than the last six status reports put together.
Five checks you can run this week, no technical knowledge needed
None of these require you to understand a single line of code, and together they come to an hour. Run them in order, write down what you find, and you will know more about the true state of your project than most of the people who have been sitting in the meetings.
1. The click test, ten minutes
Open the test site on your own phone, not on the laptop in the meeting room, and complete one full task the way a customer would: register, choose something, pay, receive the confirmation. Go the whole way through. If you cannot finish that journey, the journey is not built, whatever percentage sits beside it on the plan.
2. The change log test, fifteen minutes
Ask for the written list of every change requested since the project started, with the number of days each one added. Scope growing by fifteen to thirty percent over a four month project is completely normal and often healthy, because you learn things as you go and some of those lessons are worth building. What is not healthy is a change being accepted without a written note of the days it cost and the date it moved. If that list does not exist, the schedule cannot be real, because nobody has been adding anything to it.
3. The bug ledger test, ten minutes
Ask for two numbers: how many issues are open today, and how many were open a month ago. You do not need to read the list itself. If today's number is meaningfully lower, the project is converging on a finish. If it is higher, work is being created faster than it is being closed, and the completion date has moved even if nobody has said so.
4. The scope against invoice test, twenty minutes
Put the original list of features down the left of a page and the money spent so far on the right. Count only the features you can click on the test site and be strict about it, because in progress counts as zero for this purpose. This one comparison catches more trouble than any technical audit, and the arithmetic behind it comes up again further down.
5. The two people test, five minutes
Ask two different members of the team, separately and casually, what happens next week. Matching answers mean there is a shared plan that everyone is working to. Two different answers mean the plan lives in one person's head, which is a risk all by itself, because that person will eventually take a holiday.
If the third check is the one that worries you, it is worth understanding what a proper pass before launch actually involves, and our writing on testing and quality checks covers what should be happening in those weeks.
The arithmetic of a schedule that anyone can do
Stop counting percentages, because percentages are opinions. Count items instead, because items are facts. Over the last four weeks, how many things were actually finished and became clickable on the test site? Not started, not nearly there, finished. That number divided by four is your team's real weekly rate, and it does not care what the plan claims.
Here is the worked example, slowly. Suppose the agreed scope is sixty items, which might be screens, features or clearly defined pieces of behaviour, and it matters far less how you cut them than that you cut them the same way every month. Twenty five of the sixty are finished and clickable today. Over the last four weeks, twelve items were finished, so the real rate is three items a week. Thirty five items remain, and thirty five divided by three is a little under twelve weeks. If the plan on your desk says six weeks to launch, that plan is not wrong by a little, it is wrong by double, and the sum that showed it took ninety seconds.
Two corrections make that forecast more honest rather than more gloomy. The first is capacity, because a person described as full time on your project delivers roughly twenty five to thirty useful hours out of a forty hour week once you count meetings, the time developers spend reading and checking each other's work, answering support questions and the cost of switching between tasks. That is not slacking, it is what professional work looks like everywhere, but it does mean a plan built on forty hour weeks is twenty five percent optimistic at the good end of that range and nearly forty percent optimistic at the other, before anything at all goes wrong.
The second correction is the ninety percent trap, and it has numbers behind it. A feature reported at ninety percent usually needs another twenty to forty percent of its original estimate to actually close, because what remains is never the interesting part: it is joining that feature to everything else, handling the awkward cases and testing the result. So a ten day feature sitting at ninety percent has two to four days left in it, not half a day, which means five features at ninety percent are not half a week of work, they are ten to twenty working days, so two to four weeks.
The work you cannot see, and why the screens are only a third of it
The single biggest reason owners misjudge their own projects is that the visible part is the small part. On a typical custom web application the screens you can click account for roughly thirty five percent of the total effort. Another twenty five percent goes into rules, permissions and connections to other services. Testing and fixing takes about eighteen percent, moving your old records into the new system takes around twelve percent, and launch, security and handover account for the last ten percent.
In plain terms, the invisible work is deciding who is allowed to see what and then enforcing it properly, connecting to your payment provider, your delivery company or your accounting package, carrying eleven years of customer records across without losing or duplicating a single one, testing all of it, hardening the system against attack, setting up backups that have been proven to restore, and then the launch itself. None of that photographs well, and all of it has to happen.
The consequence for you is a rule that is both simple and genuinely useful. When the designs are approved and the screens look right, about a third of the job is behind you. So a project that is half spent at the moment the screens land is in perfectly reasonable shape, while a project that is eighty percent spent at that same moment is in trouble, and the trouble is arithmetic rather than anybody's opinion.
The security and hardening share is the part that is never visible in a demo, which is exactly why it is the first thing cut when a schedule tightens. Nobody can click on a permission that was configured correctly or a backup that was tested last Tuesday, and yet those are the pieces that decide whether a bad week turns into a bad year, so our page on security and hardening explains what that slice of the budget is actually buying you.
Where projects actually lose their weeks, and it is rarely the code
When a six month build arrives two months late, the assumption is usually that the developers were slow. The breakdown we see at Linkysoft looks quite different, and it goes roughly like this: two and a half weeks waiting on decisions from the client, two weeks of scope added mid build, a week and a half on third party services such as a payment gateway, a bank or a government portal, a week and a half of testing that was underestimated, and one week of a key person being unavailable.
Look at where the biggest slice sits. A normal project needs twelve to twenty decisions from the buyer: which payment provider, what the refund rule is, who is allowed to approve a discount, what the invoice has to show for the accountant. Most of those waits cost you nothing, because the team simply moves to another piece of work until the answer arrives. The expensive ones are the few decisions that stop whatever comes next, and it takes only two or three of those, each left sitting for a working week, to produce the two and a half weeks in the list above while the development team is doing nothing wrong whatsoever.
We say that directly because it is good news rather than an accusation. A large share of the delay usually sits on the buyer's own desk, and that is the part you control completely. You cannot make anyone write code faster, but you can answer a question in a day instead of a fortnight, and doing so is often worth more weeks than any change to the team would buy you.
The fix costs nothing at all. Keep a written decisions list with a name and a date beside every open item, and review it in the same weekly meeting as the demo. Third party services deserve their own lines on that list, because a bank or a payment provider works to its own timetable, so starting that paperwork in month one rather than month four removes a delay that no amount of effort can shorten afterwards.
Signals that mean something, and noise that does not
Half of what frightens owners is noise, so it helps to know what to ignore. A single missed date on a single feature belongs in that category, and so does an interim screen that looks messy because the design has not been applied to it yet, a developer taking a week of leave, or an admin page that looks rough when nobody outside your office will ever open it. Reacting to any of these costs you credibility with the team and buys you nothing in return.
The signals that genuinely matter are a much shorter list, and it is worth keeping them somewhere you will see them:
- Two demos in a row with nothing new to click.
- Open issues rising three weeks running.
- A sudden proposal to rewrite something from scratch, which is occasionally right and far more often a sign that nobody understands the existing work any more.
- The definition of done quietly moving, so that done starts to mean the developer has finished rather than it works on the test site.
- Silence, which is the loudest signal of the lot, because teams that are ahead of schedule enjoy telling you so.
The bug arithmetic is worth carrying in your head as a rule. In the six weeks before launch a healthy project closes more issues than it opens, three weeks in a row. If the open list rises three weeks in a row instead, the launch date has already moved whether or not anybody has said it out loud, and you are far better off agreeing a new date now than discovering the old one was fiction the week before you meant to go live.
One caution about that list of signals: work you cannot see in a demo is not work that is missing. Hardening, permissions and backups produce nothing to click, so agree in advance which weeks are for the parts you can see and which are for the parts you cannot, and read a little about security work before launch so that a quiet fortnight does not read as a stalled one.
Reading the money against the work delivered
There is a budget check that takes five minutes and needs no accountant. Write down the percentage of the money that has been spent, then the percentage of the agreed features you can actually click on the test site, and set the two numbers side by side. If spend is at seventy percent while clickable work is at forty percent, the remaining thirty percent of the budget has to carry sixty percent of the work, which it will not. That is not a prediction, it is division.
The way to stop that gap opening in the first place is to tie payments to something you can open and use rather than to the calendar. A milestone that says end of month three pays for time, so it is met by definition and tells you nothing. A milestone that says a customer can register, order and pay on the test site pays for progress, and it either happened or it did not. Staging a project that way protects the development team as much as the client, since it forces both sides to agree what a stage contains before anyone starts it, and our case studies show how real builds were broken into paid, working stages of exactly that kind.
One last piece of money catches almost everybody out, which is that the project does not end at launch. Set aside fifteen to twenty percent of the build cost every year for hosting, updates, security patches and the small changes you will inevitably want once real people are using the thing. A system nobody budgets to maintain does not break on a particular date, it simply falls behind, because browsers and phones move on, security patches go unapplied, and the catching up is eventually charged to you as a project rather than absorbed as maintenance.
You have found out you are behind. Now what?
Take the panic out of it first, because there are only four levers and everything else is some combination of them: cut scope, move the date, add money, or stop. Naming all four honestly at the start of the conversation is what turns a difficult meeting into a decision rather than an argument, and it also stops the discussion drifting into blame, which has never delivered a feature.
Adding people is the lever most owners reach for and it is the slowest one there is. A new developer needs the existing team to explain the system, the decisions and the code, so for the first two to four weeks the people who were building spend their time teaching instead, and the project goes slower before it goes faster. On a build with six weeks left in it, adding a person almost always makes the date worse rather than better.
The best answer, most of the time, is a smaller first version. Take the sixty percent of the scope that delivers the actual purpose, put that live three months earlier, and let it start earning while the rest is built. Real users will also tell you within a fortnight which parts of the remaining forty percent they never wanted, and in our experience that is usually a decent chunk of it, so the earlier launch tends to pay for part of the delay by itself.
Whatever you choose, write the reset down. One page is enough: the new date, the new scope, what changed and why it changed, agreed in writing by both sides. Some teams call that page a re baseline, which is only a new starting line to measure from, and it matters because an unwritten reset is not a reset at all, it is simply another silent slip that both sides will remember differently in two months' time.
And if the honest answer is to stop, here are the numbers so that stopping does not feel like failure. Taking over a stalled or abandoned build typically costs forty to seventy percent of what building it fresh would cost, and it needs three to six weeks of paid time before anyone writes a line, purely to understand what already exists. That is the real price of carrying on with something that is not working, which is why stopping a wrong project in month three is almost always cheaper than pushing it to a launch it was never going to survive.
When the smaller and cheaper option is the honest answer
Sometimes the reason a project is not on track is that it should never have started, so it is worth running the comparison out loud. A ready made tool at thirty to eighty dollars a month costs you three hundred and sixty to nine hundred and sixty dollars a year. A custom build usually starts somewhere between eight and twenty five thousand, plus fifteen to twenty percent of that figure every year to keep it healthy. Those two numbers are not close to each other, which means the custom route needs a reason beyond preference.
Three reasons do justify it, and they are worth testing against your own situation honestly. The first is a workflow that no product on the market supports, which is common in specialised trades and much rarer than people assume in ordinary retail or services. The second is data you are required to hold yourself, whether by law, by a client contract or by the nature of what you store. The third is per user fees that grow past the cost of building, which is what happens when a fifty dollar per seat tool meets a team of eighty.
If none of those three applies to you, buy the ready made tool. Linkysoft turns projects away on exactly this basis, because a system that should not have been built is never on track no matter how well it is managed, and we would rather lose the work than hand you something you regret paying for. If your needs are lighter than a full application, a well built site is often the whole answer, and our website design and development work covers that ground for a fraction of the cost, while it is also worth reading around how to set a realistic budget before you commit either way.
If you do build, the rhythm you can start on Monday is short enough to remember. A clickable demo every week, with you holding the mouse. A recount of the remaining items once a month, using the arithmetic from earlier in this article. And once a quarter, one uncomfortable question: is this thing still going to earn more than it costs? Owners who keep those three habits rarely need an article like this one, and if you would like a second opinion on a project you are already worried about, send us the state of it through our contact page and we will tell you plainly what we would do, including the cases where we think you should stop.
