How to accept a software project and what the client receives
Accepting a software project means confirming that the product works in production on your real scenarios and receiving everything you need to own it independently: the source code and the rights to it, a description of how the product is built and released, access, failure alerts and backups. The scope of the handover and the acceptance procedure are best written into the contract before work starts. It is also easier to accept the product in parts rather than in one delivery at the end.
What acceptance is and why to plan it early
Software project acceptance is the point at which the client checks the result and confirms they received what was agreed. In practice it is not a single signature but a set of checks: the product works, the data is in place, you hold the access, and the team that continues the work can understand the code without its author.
The most common mistake is to think about acceptance on the last day. That is when it turns out the source code sits in a developer’s personal account, the server is registered to the contractor, and there are no instructions for releasing a new version. Fixing this after launch takes longer and costs more than agreeing on it at the start.
So acceptance criteria belong in the requirements document: which scenarios must work, on which devices and platforms, and what counts as done. The guide how to prepare a software requirements document explains how to write them.
What the client receives
The handover depends on the project, but the core set is the same for a Telegram bot, an AI agent or an app. At JEEKSSHIRE 24 the client receives the following, as described on our custom software development page:
- a working product in production — not a demo on a developer’s laptop, but a version real people use;
- the source code and the rights to it;
- a description of how the product is built and how to release it: what the system consists of, where everything lives, how to build and deploy a new version;
- configured failure alerts and backups.
The handover terms — what exactly, when and in what form — are set in the contract before work begins. After that come support and further development as agreed.
What is handed over and why it matters
Each item in the handover closes a specific risk. Use the table to make sure nothing is missing:
| What is handed over | Why the client needs it |
|---|---|
| Working product in production | Shows the result is live: it can be checked on real scenarios and real users |
| Source code | Lets you fix, extend and move the product without depending on a single vendor |
| Rights to the code | Gives legal certainty that you can use the product: change it, sell it, transfer it |
| Architecture and release documentation | A new team or developer gets up to speed faster and does not break what works |
| Access to servers and services | The infrastructure stays under your control, not in someone else’s account |
| Failure alerts | You learn about a problem before your customers do |
| Backups | Data can be restored after a mistake, an outage or a failed update |
Source code handover and code ownership
Source code without the rights to it is only half a handover. You can physically hold the code yet have no right to change it or reuse it in another product. That is why the contract should state clearly who receives the rights to the work, when, and to what extent.
At JEEKSSHIRE 24 the code belongs to the client: together with the product we hand over the source code, the rights to it and a description of how the product is built and released. The terms are fixed in the contract before work begins.
Third-party components deserve a separate conversation: libraries, fonts, paid services and external APIs. You use them under their own licences, which is normal, but it is better to know in advance what is custom-built and what is plugged in. The legal wording is a question for a lawyer: rules on transferring rights differ between countries, and the contract should be reviewed by someone who knows the law that applies to you.
It is more convenient to receive the code as a repository with its change history rather than as an archive. The history shows what changed and why, which helps the next team.
Access and secrets: kept out of the code
Secrets are database passwords, keys for payment and email services, bot tokens and API keys. They should live outside the code and outside the repository: in environment settings on the server or in a dedicated secrets store. If a key ends up in the code, everyone with a copy of the repository has it, and it stays in the change history.
At JEEKSSHIRE 24, keeping secrets out of the code and out of the repository is not a separate step before delivery but a requirement for every change. Our own products are built the same way.
What to check about access
- the domain, hosting, cloud, app store and payment accounts are registered to the client or transferred to them;
- you have admin access to everything the product depends on;
- there are no passwords or keys in the repository;
- after the handover, any keys that outsiders have seen are replaced with new ones;
- there is a list of which service does what and where its configuration lives.
Pre-release checks: a red gate means no release
Before every deployment the product should pass automated checks: the build, the linter (which checks the code for errors and a consistent style) and the tests. If even one check fails, the gate is red and there is no release, however urgent it may be.
This matters to the client both at acceptance and afterwards. At acceptance you receive not just the code but a safe way to ship new versions: the checks are documented and run with one command. After acceptance, any team that develops the product works by the same rules and will not deploy a broken build.
During acceptance, ask to see a release in action: run the checks, see the green result and the deployment. It takes little time and immediately shows how reproducible the process is without its author.
Accepting in parts instead of one final delivery
A large product is better accepted in parts than in a single sign-off at the end. The work is split into pieces that can be shown and checked separately. You see working parts as the project moves and can change priorities between them.
This is how JEEKSSHIRE 24 works: the first version with the main scenario ships earlier, and the rest follows in later releases. As rough guides from our page: a Telegram bot or a small automation usually takes one to several weeks, the first version of an AI agent takes several weeks, and a standalone app takes several months or more. Read more about timing in how long app development takes, and about the first version in MVP development: where to start.
For each part, agree in advance what counts as done: which scenarios work, which data you test on, and who accepts on the client side. Then final acceptance becomes a formality, because the essentials have already been checked.
Software project acceptance checklist
Use the list below as a starting point and adapt it to your product:
- Compare the result with the contract and the requirements: do all scenarios from the acceptance criteria work?
- Walk through the main scenarios yourself in production, on the real devices and platforms the product was built for.
- If the product is multilingual, check every language, including right-to-left layout for Arabic.
- Receive the source code as a repository with its change history and make sure you, not only the vendor, have access to it.
- Check that the rights to the code pass to you as the contract states.
- Receive the description of how the product is built and how to release it.
- Ask to see a new version being released: build, lint and tests are green, and the deployment goes through.
- Check access: the domain, servers, cloud, app stores and payment services are in your name.
- Make sure there are no secrets in the code or the repository and that compromised keys have been replaced.
- Check failure alerts: who receives them and how quickly.
- Check backups: where they are stored, how often they run and how to restore from them.
- Agree on the support arrangement after launch.
Support after launch
Launch is not the end of a project. The product needs updates, fixes and further development: operating systems change, app store rules change, external services change, and so do your processes. Without a support arrangement agreed in advance, the first breakdown turns into an urgent search for someone willing to dig into unfamiliar code.
At JEEKSSHIRE 24 we set up monitoring, failure alerts and backups so that you hear about a problem from us rather than from your customers, and we agree on a support arrangement. The same team runs its own products in production — Wallet and Legal — so monitoring and updates are routine work for us, not an afterthought.
If you want to discuss a project and how it will be accepted, describe the task in your own words in the request form; a finished requirements document is not required. Answers to other common questions are on the Answers page.
User acceptance testing (UAT): who checks and how
User acceptance testing (UAT) is a check of the product through the eyes of the people who will work with it. The development team tests the code and the flows before deployment, while UAT answers a different question: does the product solve the client's problem in real work?
For this check to be useful, it is prepared in advance:
- Assign testers on the client's side: the people who will use the product every day, not only the project lead.
- Build a list of scenarios from the acceptance criteria: what the user does and what result is expected.
- Prepare the environment and data: a test build or a separate copy of the system with examples close to real ones.
- Test the product on the devices and platforms it was built for, including every interface language.
- Record the result for each scenario: passed, failed, and what exactly went wrong.
For mobile and desktop apps, UAT usually takes place on test builds before app store publishing. This is part of mobile app development: the client checks the build on their own devices, and only the accepted version goes to the store.
Feedback, sign-off and closing a phase
After testing you are left with a list of issues. To keep acceptance from turning into an endless loop of edits, the issues are sorted:
- A defect: the product does not meet an agreed acceptance criterion. It is fixed within the phase.
- A new request: what you would like to change was not part of the agreement. It is estimated and planned separately.
- A blocking issue: the product cannot be used until it is fixed. A non-blocking one can be fixed in the next release by agreement.
When there are no blocking defects left, the phase is closed with an acceptance certificate: a document in which both sides confirm that the work was done as agreed. If the project runs in parts, a certificate is signed for each part. The certificate also records which non-blocking issues are carried over to the next release.
What happens to bugs found after acceptance is best written into the contract in advance: who fixes them, in what timeframe and on what terms further work continues. This is usually part of software support after launch.
Frequently asked questions
Who owns the code after development?
That depends on the contract. At JEEKSSHIRE 24 the code belongs to the client: the source code, the rights to it and a description of how the product is built and released are handed over together with the product.
What should a software handover include?
A working product in production, the source code and the rights to it, architecture and release documentation, access, configured failure alerts and backups. It is best to fix the scope in the contract before work starts.
Can a project be accepted in parts?
Yes, and it is more convenient. The work is split into parts that can be shown and checked separately, so you see a working result along the way instead of one delivery at the end.
Where should passwords and keys be stored?
Outside the code and outside the repository: in environment settings on the server or in a secrets store. Keys that outsiders have seen should be replaced after the handover.
What if the tests fail before a release?
Do not release. If the build, lint or tests are red, there is no release however urgent it is: the cause is fixed first, then the version is deployed.
Do I need a lawyer for a development contract?
It is advisable. The transfer of rights to code and the acceptance terms are governed by the law of a specific country, so the contract wording is best reviewed by a lawyer.
What is a definition of done?
It is a list of conditions, shared by the team and the client, under which a task counts as finished: the feature meets its acceptance criteria, checks have passed and changes are documented. It removes disputes about what done means.
What is an acceptance certificate and when is it signed?
It is a document in which both sides confirm that the work of a phase was completed as agreed. It is signed after testing, once no blocking defects remain.
Who fixes bugs found after acceptance?
The contract defines this. Usually the procedure for fixes and further maintenance is agreed before work starts, so there is no ambiguity after launch.