Maintenance & Support.
Someone responsible when it breaks at 2am.
Drema maintains and supports software in production, including systems we did not build. The engagement covers monitoring and incident response, security patching, dependency currency and a steady allocation for improvement — because software that is only ever patched reactively decays until a rewrite becomes the only option.
Someone responsible when it breaks at 2am.
What usually
goes wrong.
The product launched and the team moved on. Dependencies are two years behind with known vulnerabilities, nobody is watching the error rate, the person who understood the deployment has left, and every incident becomes an improvised emergency.
Everything that ships
with this work.
Not a menu to choose from. Each piece is here because leaving it out is what makes this kind of project fail six months later.
Monitoring and alerting
Uptime, error rate and performance watched continuously, with alerts routed to people who can act.
Incident response
Defined severity levels, response times and a named responsible engineer, under an agreed SLA.
Security patching
Tracking advisories for your dependencies and patching on a risk-based schedule.
Dependency currency
Regular, small upgrades so you never face a multi-year jump across breaking changes.
Bug fixing
A triaged queue with agreed prioritisation, so reported issues do not simply accumulate.
Improvement allocation
A reserved share of each month for performance, technical debt and small enhancements.
The order matters more
than the tools.
Most of what separates a project that lands from one that stalls is sequence. This is the order we work in, and why each step comes where it does.
- 01
Take over safely
Documenting the system, access, deployment and known issues before assuming responsibility for it.
- 02
Establish visibility
Monitoring and alerting first, because you cannot support what you cannot observe.
- 03
Stabilise
Address the highest-risk security and reliability issues found during handover.
- 04
Operate
Ongoing monitoring, incident response and patching under the agreed SLA.
- 05
Improve
Use the reserved allocation to reduce the causes of recurring incidents rather than only treating them.
Where this gets
put to work.
The situations this service is built for. If one of these sounds like your problem it is worth a conversation — and if none of them do, say so on the call and we will point you at what would actually fit.
Post-launch continuity
Keeping a product healthy after the build team has moved on.
Inherited systems
Taking on software built by an agency or a departed developer.
Security upkeep
Staying current with vulnerability advisories rather than discovering them in an audit.
Out-of-hours cover
Response outside your team's working hours for systems that cannot wait until morning.
Have a use case that is not on this list? That is usually the interesting one.
Chosen to fit,
not to impress.
We pick tools that suit the problem and that your team can maintain after we hand over — never to pad a capability list.
Questions we
get asked.
Straight answers, including the ones that talk you out of work we would otherwise be paid for.
Will you maintain software you did not build?
Yes, and it is a large part of this work. We start with a handover audit covering architecture, access, deployment and known risks, so we are not accepting responsibility for a system we do not understand.
What response times do you offer?
It depends on the tier. A critical production outage carries a short response commitment; a cosmetic bug is scheduled into the normal queue. We agree severity definitions and response times explicitly rather than leaving urgent undefined.
How is this priced?
Usually a monthly retainer sized to the system's complexity and the response times you need, including a reserved allocation for improvement work. Purely reactive, hourly support tends to be more expensive over a year and leaves the underlying causes untouched.
What if there are no incidents in a month?
The retainer still buys monitoring, patching, dependency updates and improvement work, which is largely why the quiet months are quiet. If the system is genuinely stable and needs less, we would rather resize the arrangement than bill for nothing.
Do you handle security vulnerabilities?
Yes. We track advisories for your dependencies and patch on a risk-based schedule, urgently for actively exploited issues. Keeping dependencies close to current is also what prevents an emergency upgrade turning into a rewrite.
Can you take over from our previous developer?
Yes, including when the handover is imperfect or the previous team is unavailable. We reconstruct understanding from the code, infrastructure and the people using the system, and document it as we go.
Talk it through with a founder.
Bring the actual problem. You will get a straight answer on whether maintenance & support is the right approach
— including when it is not.
