The worst moment in a custom software project often comes after the launch. The vendor says it is done, you get a link to a repository, and the people who understood the system start on their next client. Nobody on your side wrote the code. Nobody is sure how to deploy it. Then something breaks on a Tuesday and you find out what you really bought.
This rarely comes up in a sale, because nobody wants to discuss the end of a relationship at the start of it. Before you sign is still the cheapest time to settle it.
This post walks through how the end of a build works with us: what stays with you, the three support phases after launch, and what the guarantee does not cover. It also lists the ownership questions to get answered in writing by any vendor, with our own answers.
We work inside your GitHub, Jira and CI/CD from day one. After launch, every build includes hypercare, then a guarantee period for defects in the delivered scope, then optional SLA-based support. The guarantee covers defects. It does not cover new features or changes to what was agreed. On ownership we follow standard practice: code written for you is assigned to you on payment, and the accounts and keys stay in your name. Make sure your agreement says so in plain words.
A repository is not a handover
A repository holds the code. A running product is also the cloud accounts it lives in, the credentials it uses, the third-party services it depends on, the deployment process, and the reasons things were built the way they were. A custom software handover has to cover all of it.
ProPayHR’s PBJ Navigator shows why. It connects to its clients’ time and attendance systems and census data, pulls staffing hours and resident census every day, and fires alerts when staffing thresholds or submission deadlines are at risk. Give someone only the source code of a system like that and you have given them a fraction of what keeps it running. The ProPayHR case study has the detail.
What stays with you
The working environment. We work inside your GitHub, Jira and CI/CD from day one. Your repo, your workflow, your standards. That removes the riskiest version of a handover, the final-day transfer nobody has rehearsed, because the work was happening in your tools all along.
The planning work. Discovery produces a requirements document, a clickable prototype, a technical architecture and a module by module estimate. Everything it produces is yours, whether you continue with us or with someone else.
The documentation. Every task moves through six phases, and the last one is documentation. It gets written as the work happens, task by task, instead of in a hurry during the final week. What it should contain is worth seeing before you sign, so ask for an example.
A codebase you can keep building on. An MVP is built on scalable architecture from day one, so future development continues on the same codebase instead of a rewrite. HeartMed’s system, for instance, is built to integrate with PointClickCare’s API next, on the same infrastructure that captures its revenue today.
“When the engagement ends, everything stays exactly where it belongs: with you.”
That is what our service page says. A web page is not a contract, which is why the questions further down exist.
The three phases after launch
Every build includes the first two. The third is your choice.
Production monitoring, rapid incident response, performance tuning and direct engineering support. This is when real users find what testing did not, and you can reach engineers directly.
Defects in the delivered scope are fixed at no charge.
Optional. Long-term SLA-based support, maintenance, optimization and operational stability. If you have your own team, our engineers can also embed with them through our outstaff model.
Get the length of the first two as dates in your agreement, with us or with anyone else. When you do, check that the window takes in at least one full cycle of whatever the product does: a month-end close, a billing run, a quarterly filing. A problem that only shows up at quarter end will not appear in a window that closes before it.
What the guarantee does not cover
The guarantee has two limits in its own wording. It covers defects, and it covers the delivered scope.
Something inside the delivered scope does not work the way that scope says it should. Fixed at no charge during the guarantee period.
New features.
Changes to what was agreed.
Long-term maintenance and optimization, which is Phase 3.
Anything raised after the period ends.
Say the written scope includes an invoice export to CSV. If the export drops rows, that is a defect. If you later decide you also want it as a PDF, that is a new request. Neither is a judgment call, because the scope document says what was promised.
This is why the written spec keeps earning its keep after launch. A guarantee on delivered scope is only as clear as the document that defines the scope. Without one, every bug report turns into an argument about whether it is a bug.
Some cases are honestly grey, and the wording above does not settle them. Settle these before you sign, with any vendor:
What to get in writing
These are the questions we would want any buyer to put to any vendor, us included. Each answer belongs in the agreement, not in a sales email.
| Question | Why it matters | A clear answer looks like |
|---|---|---|
| Who owns the code? | In the US, copyright starts with whoever created the work, and a transfer is not valid unless it is in a signed writing. Paying the invoice does not do it on its own. | A clause that assigns the rights and says when that happens |
| What does the vendor keep? | Vendors often reuse their own libraries and tooling. Those may be licensed to you and not assigned. | A named list, with license terms that survive the end of the contract |
| Who holds the keys? | Cloud accounts, production credentials, domains, DNS, third-party API keys and app store accounts can end up in a vendor’s name without anyone deciding it. | Every item listed, with a named account owner on your side |
| When does vendor access end? | Accounts that outlive the engagement are a security risk nobody is watching. | A date, and who rotates the credentials afterward |
| Can someone else run it? | Documentation only its author can follow does not protect you. | A named person on your side can build and deploy from the documents alone |
| When does each support phase end? | A period with no end date is hard to enforce. | Calendar dates for hypercare and the guarantee |
The copyright point comes from 17 U.S.C. sections 201 and 204, and the U.S. Copyright Office’s Circular 30 explains the limited cases where a commissioned work is a work made for hire. This is general information, not legal advice. Have your own counsel read the clause.
We follow standard practice on all six. Your agreement is the final word, so read it against this list.
Who owns the code? You do. Code written for you is assigned to you on payment.
What do we keep? Only general-purpose tools and libraries that were not written for you. Anything like that in your product is licensed to you on terms that outlast the engagement.
Who holds the keys? You. Cloud accounts, domains, production credentials and third-party services sit in your name, and we work through the access you grant.
When does our access end? When the engagement does. Access is removed and credentials are rotated at handover.
Can someone else run it? That is what the documentation is for, and the test below is how you check.
When does each support phase end? On calendar dates in your agreement, sized to the build.
A handover test you can run before support winds down
You do not have to take anyone’s word for it, ours included. Before hypercare ends, have someone who did not work on the build try these:
Whatever fails is your to-do list for the rest of the support window. Failing at this stage is cheap, since the people who can fix it are still on the phone.
Frequently asked questions
Who owns the code when the build is finished?
You do. We work inside your repo, and when the engagement ends, everything stays with you. We follow standard practice: code written for you is assigned to you on payment. Make sure the agreement says it in plain words.
Is ongoing support required?
No. Every build includes hypercare and a guarantee period. Ongoing SLA-based support is optional.
How long do hypercare and the guarantee last?
It depends on the size of the build, so both go into your agreement as calendar dates.
Can we move the product to another team later?
Everything Discovery produces is yours, and the work sits in your own GitHub, Jira and CI/CD. Run the handover test above with that team before you rely on it.
If you are already holding a repository
If a previous vendor has already handed you a codebase and nobody impartial has reviewed it, start with the free technical audit. It is a scored review across seven areas, including architecture, test coverage and scalability, and you get a written findings report with prioritized recommendations and severity levels. It takes one to five days and costs nothing.
Take the free technical audit of your existing product, or book a call about a new build.
Service details come from the Touch Support Software Development page. ProPayHR and HeartMed details are as published. The invoice export is an illustration, not a client finding.
