Maintaining client apps well comes down to four habits: a clear rule for what each change request costs, one place where requests are logged, a routine for testing and publishing changes safely, and a way to roll back when something goes wrong. Get those right and maintenance becomes the steady, profitable part of the work instead of a stream of interruptions.
Set the scope before the first request
Most maintenance problems start with fuzzy scope. Agree on these in writing when the client signs:
- What the monthly fee includes: hosting, support hours, a number of small and medium changes.
- What counts as small, medium and large.
- How fast you respond, and on which days.
- How requests should reach you.
- What happens when the monthly limit is reached.
A simple definition table helps both sides:
| Size | Examples | Typical handling |
|---|---|---|
| Small | Add a field, rename a label, change a column on a list | Included |
| Medium | New step in the job flow, new quote type, new report | Included up to a monthly limit |
| Large | New area of the business, a second location with its own process | Quoted separately |
For pricing these, see how to price custom apps for clients.
Log every request in one place
Requests arrive by text, email, voicemail and in passing at the end of a call. If they live in five places, some will get lost. Keep a single log per client.
A spreadsheet or a shared document is enough. Track:
| Field | Example |
|---|---|
| Date | March 4 |
| Requested by | Office manager |
| Request | Add "preferred technician" to customers |
| Size | Small |
| Status | Published March 6 |
| Counts toward limit | Yes |
Share the log with the owner. It shows what their monthly fee pays for, which makes renewals easier.
Turn requests into clear changes
Clients describe problems, not solutions. "The guys keep going to the wrong house" is a request. Your job is to find the change that fixes it.
Ask three questions before building anything:
- What happened? Get a specific example.
- Who does it affect? Office, crew or customers.
- What would good look like? "Crew leads see the full address and a map link on each job."
Then make the change. In Alori, you change the app by asking in a sentence, like "Add a gate code field to customers and show it on each job." Keep each request focused on one thing so it is easy to check.
Test on a copy, publish when ready
The client's team uses the app all day. You can't afford to break it mid-morning.
Alori tries every change on a copy of the app first. The client's team keeps using the live app while you work. Nothing changes for them until you publish.
A safe publishing routine:
- Make the change on the copy.
- Check it yourself on a computer and on a phone, using realistic data.
- Show the requester if the change affects how they work. A screenshot or a quick call is enough.
- Publish at a quiet time, like early morning or end of day.
- Tell the team what changed in one or two sentences.
For non-urgent work, batch small changes and publish them on a set day, for example once a week. Staff get fewer surprises, and you spend less time switching between clients.
Use versions as your safety net
Even with testing, a change sometimes causes a problem nobody expected. In Alori you can go back to an earlier version of the app. That means a bad publish is a short inconvenience, not a crisis.
Good habits around versions:
- Publish changes in small batches so it is easy to see which one caused a problem.
- Note in your log what each publish included.
- If something breaks, roll back first, then investigate. The team's work matters more than your fix.
Handle support without getting buried
Support questions are different from change requests. "How do I mark a job done?" doesn't change the app; it means someone needs help.
- Set support hours and share them. Urgent issues during work hours get a fast reply; how-to questions can wait a few hours.
- Keep a short help sheet per client with their most common tasks.
- Notice patterns. If three people ask the same question, the app or the training needs to be clearer. Fix the cause.
- Retrain new staff as part of the service. Hiring is a good moment to check in with the owner.
Keep clients organized
Once you have several clients, organization keeps you sane.
- One project per client. In Alori, one account can hold many projects. Each project is a separate app with its own data and its own team, so client data never mixes.
- The client's staff in their own project only. Invite them to their project and nothing else.
- A weekly review. Go through every client's log once a week. Close what's done, plan what's next.
Say no, or not yet
Not every request should be built. Some would make the app harder to use for everyone else. Some belong to a different project.
When you push back:
- Explain the trade-off in plain words.
- Offer an alternative that solves the underlying problem.
- Put larger ideas on a "later" list and revisit them in the next check-in.
Clients respect an agency that protects the app they rely on.
Make maintenance visible
Owners renew when they can see the value. Once a month, send a short note:
- What changed this month.
- Any issues and how they were handled.
- One suggestion for next month.
That note is also the backbone of recurring revenue for agencies. Clients who see steady improvement stay.
Frequently asked questions
How do I handle a client who sends too many change requests?
Point back to the agreed monthly limit and share the request log so they can see the volume. Offer to move them to a higher service level or quote the extra work. Most clients accept clear rules when they are applied fairly.
How do I avoid breaking a client's app when making changes?
Make changes on a copy first, check them on a computer and a phone, and publish at a quiet time. Alori keeps the live app untouched until you publish. If something still goes wrong, roll back to an earlier version.
How often should I publish updates to a client app?
Urgent fixes go out as soon as they are checked. For everything else, a weekly batch works well for many clients because staff see changes on a predictable day. Pick a rhythm and tell the client.
Should support be included in the monthly fee?
Yes, within set hours and response times. Support is part of what makes the app useful day to day. Spell out what is included so expectations are clear.
Try it with a client project
Set up a project for one client, make a change on the copy and publish it when it is ready. Alori is free to start, with no credit card and no account needed to try. Start now.
