Why Work Should Be Done in Stages

Last week the same message came again. "The person doing the project quit halfway, I am chasing the money I paid, what should I do?" This is not the first time this message has come to me. I have been doing software work for more than twenty years, and I have heard almost every variation of this sentence. Sometimes it is a freelance developer, sometimes a small agency, sometimes "an acquaintance I trusted a lot".

Most of these jobs do not start with bad intentions. There is a good idea, a hastily made agreement, and a single lump-sum payment. Then things go wrong. In this article, instead of looking for a culprit, I want to talk about the shape of the agreement. Because doing the work in stages seriously lowers the risk, regardless of whether the parties trust each other.

One-piece work is a gamble for both sides

The classic scenario works like this. The client hands over a three-month job under a single contract and pays a significant part of the money upfront. The developer works for three months without fully knowing what will happen. Both sides are really doing the same thing: betting on the other side's good intentions.

When things go wrong, the client says "my money is gone" and the developer says "my effort is gone". Both can be right. Because one large payment does not buy whether the work is actually done, it buys the person's intention on that day. Nobody can guarantee that intention will still be there three months later.

What staged work actually means

Splitting the work into four or five pieces. Each piece has its own deliverable, its own price, and its own acceptance criteria. When a stage ends, there is something visible in front of you. The client sees it and approves it, and the payment is made after that. It sounds simple, but in practice it is not done in most projects.

In a web project, the stages might look like this:

• Discovery and technical plan. Screen flow, data model, list of out-of-scope items. No code yet, but the boundary of the work is clear.
• Skeleton. Login, one real screen, and a published test address. The client can click and see it.
• Main flow. Whatever the project's core job is, it works. Payment, order, message, appointment, whichever it is.
• Integration and testing. Payment provider, email, notifications, error scenarios.
• Launch and handover. Server, domain, source code, usage notes. The files are in the client's hands.

The critical point here is this. The output of each stage must be something the client can see with their own eyes and say "okay" or "not okay". A sentence like "analysis is thirty percent complete" is not a stage, it is an excuse. What did I see, what works, what am I approving. Every stage whose answer is unclear turns into an argument later.

What changes on the client's side

The biggest benefit, in my view, shows up in the first stage. Within a few weeks you see how the person across from you works. Do they ask questions, do they explain what they wrote, do they dodge the work, or do they actually deliver? There is a big difference between finding this out three months later and finding it out in the first ten days.

• Money follows the work. Output first, payment after.
• If the scope changes, it becomes a separate stage. Not an argument, but a job with a clear price.
• If the project stops halfway, the loss is limited to the last paid stage.
• The moment the work is finished becomes clear. There is no months-long uncertainty of "it is almost done".

What changes on the expert's side

Staged work does not only protect the client. It also protects the person doing the work. In a one-piece contract, everyone makes the same mistake: adding the cost of uncertainty to the price. The price inflates, and the work stays uncertain.

• You do not need to inflate the price for risk. Each stage's cost is known.
• Cash flow becomes regular. You do not have to wait for a single payment three months later.
• Scope creep is not a negotiation, it becomes a new stage.
• Even if the work stops halfway, the work already done has been paid for.

The most common mistake: confusing installments with stages

Three installments do not mean three stages. An installment is tied to time. Thirty percent at the start, forty percent in the middle, thirty percent at delivery, and so on. This method organizes the payment schedule but does not organize the state of the work. If the work stops halfway, the client may have paid seventy percent and received fifty percent of the work.

There is a simple way to tell them apart. Is the payment tied to a date or to a deliverable? If you say "second payment on the fifteenth", that is an installment. If you say "the login and payment flow works at the test address and is approved", that is a stage. The whole benefit of staged work comes from tying payment to the work seen, not to a date.

Freelance portals are a good start, but not enough alone

Places like Upwork and Fiverr are genuinely useful for finding work. I follow them too. But at the center of those systems is not stages, it is a bidding race. Hundreds of people price the same job. Most of the time the winner is not the one who offers the strongest proof they will do the job best, but the one who gives the lowest price.

On top of that there is the platform commission, ranging from ten to twenty percent. You need to buy credits to place a bid. The profile score also shows how satisfied past clients were at the time, not how someone delivers work. This does not mean these are bad platforms. I only mean this. Portals are good for discovery, but not enough for trust on their own. Stage discipline has to be on your side.

My story

I have been developing mobile and web software for more than twenty years. I worked in corporate projects for years. I was also on the process side and took part in security and quality audits. In recent years my focus has been AI-powered products and platforms I built myself. I saw the same thing in a sensitive project like DoktorAsistan on the health side and in smaller jobs alike. Projects that start well technically sink because of a badly set up business relationship.

When I hear a client's idea for the first time, I usually ask this. "When this work is done, what will you have in your hands?" If the answer is clear, the job is easy. If the answer is "I do not know, you know better", then that needs to be clarified first. The first benefit of staged work starts here. The first stage is often not code but a clear definition.

The agreement matters as much as the technique. That is why I now talk about projects by dividing them into stages from the start. We move forward as the work is seen. Both the client knows what they got and I know what I delivered.

Why I like serbestis.com

This is why I like a place like serbestis.com. They have put stages at the center of the work. Posting a job is free, no commission is taken, and payment is made directly to the expert at each stage. So the platform removes the large single-payment problem from the start. The client does not have to move to the next stage without approving the previous one.

The second thing I like is that experts are verified through LinkedIn. A real name and a real history instead of an anonymous profile. Knowing who will do the job is something that comes before the price.

The third one is this. Serbestis.com also lists experts who work with AI agents. A good developer already uses agents today. Showing this as part of the work, instead of hiding it, makes sense to me. After all, what matters is not which tool it was made with, but whether the work functions.

Of course the platform alone is not magic. The person writing the job post still has to describe it well. The expert still has to do the job well. But on a well-built ground, these two sides find each other more easily.

My profiles are here: Turkish profile and English profile. Both profiles list my services, experience, and the work I have done. If anyone wants to move their project there, I send my staged proposal from there.

Five questions to ask before starting

1. What will be in hand at the end of each stage?
2. Are the acceptance criteria written down, or just in our heads?
3. Will I see and try something working at the end of a stage?
4. Is the payment tied to approval or to a date?
5. If a stage fails, what happens, a fix or an exit?

If the answers to these five questions are clear, the technical side of the project becomes far less scary. Because the subject of the argument stops being "are you good or bad" and becomes "is this stage done or not".

Finally

Working in stages is not distrust of the other party. It is making trust measurable. You start small, see the work, and continue. If it goes well, you will keep going anyway. If it does not, you stop with a small loss. A more humane method for both sides.

If you have a project, you can publish it on serbestis.com for free. Experts bid by dividing the work into stages, and you evaluate each stage separately. If you like, you can also reach me through my profile. Let us talk and divide the work into stages together.

Earlier I wrote about a different side of this subject, why projects fail, in this post. The two posts complement each other.

Cover photo: Jill Burrow, Pexels.