Skip to content
SUPPORT SYSTEM
Maintenance & Support

Software does not stay finished

Frameworks release, dependencies get security advisories, browsers change and traffic grows. We keep the application healthy through all of it — with a support system your team can raise a ticket in and follow.

What happens to software nobody maintains

It keeps working, for a while. Then a dependency gets a security advisory nobody is watching for. A framework version reaches end of life and the upgrade path gets longer every month it is postponed. A browser changes a default and a form stops submitting on one platform. Traffic grows and a query that was fine at a thousand rows is not fine at a million. None of these are emergencies on the day they start. All of them are emergencies eventually, and by then the fix is a project rather than an afternoon. A maintenance agreement is what turns that into routine work: monitored uptime and errors, security patches applied on a schedule, dependency upgrades done in small steps while they are still small, and a monthly report saying what changed. Requests come through the Vertex Arc Support System, so a ticket has a reference, a status and a history rather than living in somebody's inbox.

Key benefits

What this changes for your business.

Security advisories acted on

Dependencies are watched, and a published vulnerability becomes a scheduled patch rather than a news story you missed.

Upgrades while they are small

One framework version at a time, on a schedule, instead of a four-version jump that turns into a rewrite.

Problems found before customers find them

Uptime, error rate and performance monitored, with alerts routed to somebody who can act on them.

Requests with a reference and a status

Every request goes through the support system, so nothing depends on remembering which email thread it was in.

What we deliver

The things you actually receive.

  • Monitoring and alerting

    Uptime, error tracking and performance, with a threshold agreed rather than a default nobody chose.

  • Security patching

    Advisories reviewed and applied on a defined cadence, with an out-of-band path for anything critical.

  • Dependency and framework upgrades

    Small, tested steps with a changelog, so upgrading never becomes a project of its own.

  • Bug fixes with a response window

    A defined priority scale and response times, written into the agreement rather than implied.

  • Ongoing feature development

    A monthly allocation for the small improvements that would otherwise never be scheduled.

  • Backup verification

    A restore actually performed on a schedule, so the recovery plan is something you have tested.

  • Monthly report

    What was patched, what broke, what is trending and what we recommend next.

Core capabilities

The engineering disciplines this service draws on.

Uptime & error monitoring
Security patching
Dependency upgrades
Ticketed support
Performance monitoring
Backup verification
Regression testing
Monthly reporting
Roadmap advisory

Technologies we use

The stack we would reach for, and what each part is for.

Laravel

A mature PHP framework for secure, maintainable server-rendered applications and APIs, with authentication, queues and testing built in.

PHP

The language behind a large share of the web, and a fast, strictly typed one since PHP 8.

Docker

Containers, so the application a developer runs locally and the one running in production are the same artefact.

GitHub Actions

The pipeline that runs the tests, builds the artefact and deploys it — on every commit, in the same order, every time.

AWS

Cloud infrastructure with managed databases, storage and networking, so capacity follows demand instead of a purchase order.

Playwright

Browser tests that click through the real application, which is the only way to know a flow still works end to end.

Industries we serve

Sectors where this service tends to fit well.

  • SaaS
  • E-Commerce
  • Professional Services
  • Healthcare
  • Education
  • Logistics

Our delivery process

How an engagement runs, from first conversation to ongoing support.

  1. Discovery

    We work out what the software has to do, who uses it, and which constraints are real. The output is a written scope, not a proposal.

  2. Architecture

    Data model, boundaries, integrations and infrastructure decided and agreed before anybody writes application code.

  3. Design

    Flows and interface, including the empty, error and permission states that decide how the product actually feels.

  4. Development

    Built in reviewable increments against a conventional structure, with tests around the parts that would be expensive to break.

  5. QA & security

    Functional testing, performance checks, and a review of authentication, authorisation and dependency risk before launch.

  6. Launch

    Deployment, monitoring, and a period of close attention while real traffic finds what staging did not.

  7. Continuous improvement

    Patches, upgrades and new work through the support system, so the product keeps being maintained rather than quietly ageing.

Use cases

What this looks like as a finished product.

Taking over somebody else’s codebase

An audit first: what it does, what state it is in and what has to be fixed before it can be safely maintained.

Keeping a launched product healthy

Ongoing patching, upgrades and monitoring for a product that is live and cannot afford a surprise.

Covering a small in-house team

Backup for a one-developer team: holiday cover, second opinion and the work they do not have time for.

Why Vertex Arc

A real support system, not an inbox

Tickets with references, statuses, attachments and a history both sides can read.

We maintain software we did not write

Taking over an inherited codebase is normal work here, and it starts with an honest audit.

Response times in writing

Priority levels and response windows are part of the agreement, so expectations are shared rather than assumed.

No lock-in

You keep the repository and the infrastructure. A maintenance agreement is a service, not a hostage arrangement.

Frequently asked questions

Will you maintain an application you did not build?
Yes, after an audit. We review the code, the dependencies, the infrastructure and the tests, and give you a written assessment of what needs doing before an ongoing agreement makes sense. Sometimes the honest answer is that a specific part should be rebuilt first.
How are requests raised and tracked?
Through the Vertex Arc Support System. Your team signs in, opens a ticket against a project, attaches whatever helps, and follows the replies and status changes in one thread with a reference number.
What is not included?
A maintenance agreement covers keeping the existing system healthy and small improvements. A new module, a redesign or a platform migration is scoped as its own project — priced separately so the monthly fee stays predictable.