Start here.
Before launch, agree who helps users, keeps the app running, pays for its services, and approves changes. Ask for a written plan you can use when something goes wrong, including how to recover information and reach the right person. Keep the business accounts and handover information accessible to the people responsible.
- Name a business contact as well as a technical contact; someone needs to judge how a problem affects customers.
- Ask what support covers, when help is available, and what happens outside those hours.
- Treat launch as the start of an operating plan, with room for fixes and decisions about future work.
Who gets the first call when someone needs help?
Imagine a small business launching an app for customers to book meeting rooms. This is an invented planning example. A customer says their booking is missing. The person answering needs somewhere to send the report and a way to find out what happens next.
Decide who receives customer questions and who can investigate the software. Those may be different people. Your team may be best placed to explain booking rules, while the supplier investigates a booking that was not saved.
Agree the contact method, hours of cover, and what makes a problem urgent. A customer unable to book anything is a different situation from a request to change some wording. Ask what happens if the usual contact is unavailable.
Distinguish a response from a fix. “We will reply within the agreed period” does not tell you when the app will work again. Ask how the supplier will keep you informed and what information your team should include in a report.
Which bills and responsibilities continue?
Ask for a list of the services the app depends on, in words you understand. These might include the place it runs, its web address, email delivery, file storage, or a booking tool it connects to. You do not need to learn the setup; you need to know who is responsible for each part.
For each service, record who holds the account, who pays, when a renewal is due, and where billing or service notices arrive. Ask which charges are included in your agreement and which your business pays separately.
If a bill can change with usage, ask what drives it and how you would notice a change. For the booking example, more confirmation emails might affect a service allowance. That is a question to check for the chosen service, not an assumption about its price.
Choose a business owner for these details. A payment-card change or an important notice should have a clear route to someone who can act.
What would the business do if the app stopped working?
Talk through a specific interruption before launch. If the booking page is unavailable tomorrow morning, how will staff check existing reservations, take urgent enquiries, and tell customers what to do? Write down a temporary way of working that your team can manage.
Ask what information is backed up, how often, where responsibility sits, and what recovery has actually been tested. A copy of some records does not by itself show that the whole booking service can be brought back. Ask the supplier to explain what a recovery check established and what it left untested.
Discuss what work could be missing after recovery and who would reconcile it. In our example, staff might need to check bookings taken since the last recoverable copy against the enquiries they handled. The answer depends on the actual system and the interruption.
Agree who decides when to pause bookings or tell customers about a problem. The technical team can investigate; your business still needs someone to make service decisions.
What is a fix, and what is new work?
Ask your supplier to explain what the ongoing arrangement covers. Helping a user, correcting a fault, keeping the software up to date, and adding a new capability are different jobs. A general promise of “maintenance” may leave the boundary unclear.
Use a few examples from your own app and get the answers written down. The table below is a discussion aid for our fictional booking app. It does not set a universal rule about what a supplier must include.
For work outside the agreement, decide how a proposed change becomes an approved job. Ask for the cost, effect on timing, and any new running responsibilities before someone starts. Name the person in your business who can approve it.
| Situation | Question to settle | Business input needed |
|---|---|---|
| A customer cannot sign in | Who checks access problems, and where should the report go? | Who can confirm the customer’s identity and intended access |
| A saved booking disappears | How will a suspected fault be investigated and progress reported? | Enough permitted details to find the booking and understand its effect |
| Room availability is wrong | Is this a record correction, a software fault, or both? | Who maintains room information and checks the corrected result |
| You want recurring bookings | How is additional work described, priced, and approved? | The booking rules and the person who can authorise the change |
Could another person take over later?
Ask what your business will receive at handover and what another maintainer would need. That may include the software files, setup instructions, a list of services, and a clear way to arrange the necessary access. Ask the supplier to explain any restrictions in your actual agreement.
Confirm which important accounts your business controls and which the supplier manages for you. Make sure account recovery and important notices do not depend on one person’s private email address. Arrange access through the agreed secure method rather than passing passwords around in a document.
Ask what would happen if the supplier or your own main contact became unavailable. Who could explain the system, locate the relevant information, and arrange a handover? You are looking for a workable route, not a promise that changing suppliers would be effortless.
What should you review once people are using it?
Set a first review date before launching. Bring the questions users asked, problems that remain open, and any extra work staff have taken on. In the booking example, repeated calls about confirmation emails may reveal confusing wording, a delivery problem, or an unclear booking rule.
Decide which issues prevent people finishing their task, which are useful improvements, and which can wait. Give each agreed action an owner and a way to check the result. Keep new feature requests alongside the work needed to keep today’s service dependable.
Revisit the running bills, support arrangement, and recovery plan when the app or business changes. Adding another location, another person with access, or a new connected service can change who needs to do what.
A useful launch ends with more than a working screen. Your team should know whom to contact, what it is responsible for, and how the next decision will be made.
Ask for a one-page plan you can actually use.
Keep this beside the launch checklist and make sure the people named in it have agreed to their part. Review it when a supplier, service, or business contact changes.
- People
- Who takes customer reports, who investigates, and how each person can be reached.
- Services and bills
- Which accounts keep the app running, who pays, and where important notices go.
- Recovery
- What can be recovered, how that has been checked, and how the business would work while waiting.
- Changes and handover
- Who approves extra work and where another maintainer would find the necessary instructions and access.
A couple of common questions.
Does a support agreement mean every future change is included?
Ask for the boundary in writing. Support might cover help and investigation while additional features need a separate agreement. Use examples from your app to establish the actual coverage, how extra work is estimated, and who can approve it.
Do I need someone technical on my own team?
You need someone in the business who can explain the effect on customers or staff and make decisions. Technical investigation can sit with a supplier if that is your arrangement. Make sure both sides know their responsibilities and how they will work together.