How we work
1. Review the existing system
We review the state of the code, infrastructure, access, and documentation to identify the work to consider.
2. Agree on work and responsibilities
We define the support model, work priorities, change approvals, and any maintenance period for the project.
3. Carry out the agreed work
We carry out maintenance or changes within the agreed scope and review the results with the relevant team.
What can maintenance and support cover?
A live application brings different requests: a user gets stuck, a rule changes, a connected service fails, or an update is needed. These are possible situations, not completed customer projects or a standard package. We first review the application and its owners.
Investigate an intermittent problem
Imagine a screen that fails only sometimes. We record when it happened, the user's path, and the running version, then check logs, connected services, and recent changes. The cause may be code, configuration, or a third-party service. Repair time cannot be known before investigation.
Separate new work from support requests
Suppose a form needs an approval step, new permissions, and another system's data. That is more than fixing a bug. It may affect data, users, testing, and release. We separate minor adjustments from new development when planning the work.
Learn from repeated user questions
Teams may struggle with the same screen because of unclear instructions, permissions, or a feature problem. Collecting questions in one agreed channel helps separate usage advice from technical investigation. The project sets the channel and request owner.
How do we work on an existing application?
Before planning maintenance, we need to understand the application as it runs today. Who owns the code and accounts? What changed recently? What can the team access? The steps below guide that conversation; the work itself depends on the project.
Understand the system and access
We review the components, code repositories, environments, connected services, and available documentation. We also check which access belongs to the customer, a previous developer, or a provider. Missing permissions can limit what we can inspect.
Sort requests by type and impact
A bug, a security update, a usage question, and a new feature need different handling. We capture the impact, how to reproduce the issue, and any needed approvals. The project also sets the request channel, priorities, and any response targets.
Make, test, and release the change
For approved work, we identify the affected components and test the change where appropriate. The release should fit the existing deployment process, including a way back if needed. People using the application should know what changed and what remains limited.
Review the result and remaining work
We check the expected behavior with the relevant people, then keep open requests, repeat problems, and new development separate. If more support is needed, the next period and responsibilities are discussed explicitly.
What should a support agreement cover?
The application's age, technology, code access, and outside dependencies all affect the work. An inherited system may have technical debt, missing documentation, or accounts nobody can access. An initial review helps reveal those limits; it does not mean every issue is included in one agreement.
The team should agree on a request channel, who may contact support, working arrangements, the maintenance period, and how changes are approved. There is no single response schedule or SLA for every customer. Usage questions, incidents, new features, and provider failures may also have different owners.
Keeping an application running involves updates, tests, releases, accounts, and communication with users. The proposal should say what Codiatech will handle and what access the customer will provide. If needs change, the work can be reviewed instead of assuming support has no limit.
Questions about this service
Can you support software built by another team?
Possibly. We first review the code, architecture, access, and documentation, then discuss which work we can responsibly take on.
Does support include new features?
Not automatically. Questions about using the product, bug fixes, and new features are different kinds of work. The proposal says whether development is included.
Which channels and hours are available?
They depend on the project. We agree on who can raise a request, which channel to use, the working schedule, and any response targets before support begins.
What if a third-party service fails?
First we need to see whether the problem is in the application, the connection, or the provider's service. Access and the agreement determine who can act and who follows up.
What happens at the end of the maintenance period?
The team reviews open requests and any new needs. Continued support or development is discussed as new work rather than continuing automatically.
Maintenance after launch depends on the service and the project. We discuss it when preparing your proposal.