Included in a typical proposal
- Onboarding labour described in the proposal.
- Investigation and changes within the allowance or hours.
- Release notes for production changes we make.
SOFTWARE DEVELOPMENT
Software maintenance
in Dubai & the UAE.
Keep an application supported as its users and dependencies change. Define the supported system, coverage and change process before work begins.
WHAT THIS SERVICE IS
A plain explanation of the work.
Software maintenance is looking after an application after it is in use: investigating faults, applying small changes, keeping dependencies in a supportable state, and documenting releases. It requires a defined system, access to the repo and environments, and a way to decide severity. It is not a second product team hiding in a monthly fee.
Onboarding is real work. An undocumented application takes longer to touch safely. The first period may be heavier for that reason; the proposal should say so rather than pretend month one is identical to month six.
Security patches, certificate renewals and a dependency that went end-of-life are maintenance when they are in coverage. A new module is a project. Arguments about which is which are cheaper if the backlog has a written rule.
A CLEAR PICTURE
A labelled diagram, not a decoration.
-
Onboard until we can deploy a no-op
If we cannot, stop and re-scope.
-
Triage with your named owner
Severity is a business call as well as a technical one.
-
Change on a branch, test, release
Even when the change is small.
-
Keep the runbook honest
Or the next incident starts from folklore.
WHO IT IS FOR
The situations this page is written for.
Teams whose developer left, product owners who need a bounded change capacity, and businesses running an internal tool that still has users. Also companies that built with ITZ and want a care arrangement instead of on-demand panic.
- Owners who can grant repo, host and error-log access.
- Products with a named person who can accept a release.
- Applications that still have a staging environment, or that will fund one.
- Managers who can live with a response window written in the proposal.
TYPICAL SCOPE
What a proposal usually names.
01
Application onboarding
Repo, environments, secrets, architecture notes, and a smoke test we will repeat. If we cannot run it, we cannot maintain it. That finding comes early.
02
Issue investigation
Reproduce, classify, and fix within coverage. Third-party outages are identified as such. We do not rewrite a vendor’s API in an afternoon because it blinked.
03
Maintenance changes
Small improvements and patches with tests that match the risk. Visual redesigns and new integrations consume a project budget unless the proposal’s change allowance explicitly includes them.
04
Release documentation
What changed, how to roll back, and any runbook updates. Production access follows your rules. A Friday-evening deploy is a choice you make.
HOW THE WORK RUNS
The sequence we follow once the brief is clear.
-
Onboard until we can deploy a no-op
If we cannot, stop and re-scope.
-
Triage with your named owner
Severity is a business call as well as a technical one.
-
Change on a branch, test, release
Even when the change is small.
-
Keep the runbook honest
Or the next incident starts from folklore.
INCLUDED AND QUOTED SEPARATELY
Labour versus things that sit on their own line.
Quoted separately
- New products, new mobile apps, new tenants.
- Hosting invoices unless we operate the host under contract.
- Data recovery beyond a restore you already have backups for.
- Around-the-clock on-call unless that roster is bought.
AFTER HANDOVER
What you should hold when the work is done.
You can take the application elsewhere. Access we hold is listed. A final dependency report is a reasonable end-of-term artefact.
If you pause maintenance, say when the last patch was. Restarting after a long freeze may need a project to catch up.
PRACTICAL NOTES
Details that usually affect the proposal.
Secrets rotation, certificate dates and dependency alerts need a calendar. If nobody owns them, they become incidents. We can hold the calendar in the allowance. We cannot invent a person in your company who accepts a Friday deploy. Name that person in onboarding.
Error volume is a signal. A noisy log that everyone ignores is worse than a quiet log with one alert. Part of onboarding is deciding which events a person should see. That decision is written down so it does not reset every time a new engineer joins the care arrangement.
PLANNING THE WORK
Questions worth asking.
Is this a ticket portal with a one-hour response?
Only if the proposal writes those hours and channels. This page does not invent a response-time table.
Can you maintain software you did not build?
Yes, after onboarding. Some codebases are not safe to touch without a rewrite; we will say that rather than bill quietly forever.
Who decides what is a bug versus a feature?
Your product owner, with our technical note. Ambiguity is normal; the written rule in the agreement is the tie-break.
CONNECTED SERVICES
Explore the next piece.
LET’S BUILD WHAT’S NEXT
Your next step starts
with a conversation.
Tell us what you want to improve, build or simplify. We’ll help you define a practical way forward.
Discuss your project