Why we take payment after the demo and how it protects the client

The problem with prepayment

Prepayment protects the developer. The client, meanwhile, pays for a promise. They do not know whether the team can do what it promised, whether it understood the task and whether it will finish the job.

Many know the worst case. The money is gone, deadlines slip, the developer replies less and less often. Getting a prepayment back is hard even with a contract, and starting over means a smaller budget and lost months.

How it works with us

1. 1 We discuss the task. No spec needed, we ask the questions.
2. 2 We name the price and timeline and fix them before work starts. Everything we discussed is included.
3. 3 We build a demo. About 40% of the functionality works in it. It is not a mockup or pictures but live code you can open and try.
4. 4 You look at the demo and pay. Then we finish the rest.
5. 5 We launch and hand over the code and access. For a month after launch we fix small things for free, as long as they add no new features.

Why 40%

Showing less is pointless. A 10% demo is usually an interface with no logic, and it says nothing about whether the team can handle the hardest part. By 40% the foundation is ready: the data, the main flows, the integration with the most awkward external service. A demo like that shows the project is real.

Doing more before payment does not pay off either. If we took projects to 80% for free, every refusal would cost us almost the whole job. That risk would have to be built into the price for every client.

An example demo

Take a booking bot for a salon. The full project includes bookings, reminders, staff schedules, an admin panel, export to a sheet and prepayment.

At the demo the client gets a working bot in Telegram. You can pick a service and a specialist, see the free time and book. The booking is saved to the database, and the taken slot disappears from the list. There is no admin panel yet, no reminders or prepayment, and the texts are drafts.

That is enough to see the main thing. Booking works, the flow matches how the salon runs, and the staff and services are set up right. If something is off, it shows at once, and this is the cheapest stage to fix it.

Who assesses the percentage

We assess the complexity and the progress ourselves. We split the project into parts when we calculate the price, and the demo shows which of them are done. If the client feels it falls short of 40%, we go through it together and show what the interface does not: server logic, the database, integrations. In a bot or a scraper most of the work has no interface at all.

Changes to the demo are not part of the 40%. If after the demo you want to change a flow, we check whether it was in the agreement. If it was, we do it. If not, we estimate it as a separate change.

What the client gets

• Money does not go for a promise. You pay for a working part of the product.
• You see whether you were understood. A demo shows mismatches words hide: the wrong order of steps, extra fields, a forgotten role. Fixing them at 40% is cheaper than at 100%.
• You can walk away. If the demo does not suit you, you pay nothing.
• The price does not drift. It is fixed before work starts and stays the same after the demo, unless the task changes.
• The code is yours. After launch we hand over the source and access to the server, the bot and the admin panel. The project is not tied to us, and any developer can maintain it.

What we get

The scheme is risky for the developer, and we know it. So we pick tasks carefully and say at once if we are unsure of the result. In return we do not have to sell ourselves with promises and presentations. A working demo convinces better, and a client who has seen one argues less about details and talks more about the actual work.

There is a less obvious benefit too. A 40% demo forces us to do the hardest part in the first days instead of leaving it for the end. Projects that postpone the hard part are the ones that most often miss deadlines.

Where the scheme does not apply

• Research and reverse engineering. The result is unknown in advance, and 40% of such a project is hard to show. We discuss terms separately and sometimes work by the hour: $25 per hour.
• Small tasks of a few hours. A demo makes no sense for them, payment is hourly: $20 per hour.
• External costs. You pay for the server, paid APIs and licences yourself, in your own name. That is not our work but third-party bills, and this way the access is yours from the start.

Websites, bots, automation and scraping follow the payment-after-demo scheme. Prices for this work start from $125 for a bot and $190 for a landing page.

To see what the result looks like, open the projects section. The demo brands are made up, the code and features are real.