Skip to content
SUPPORT SYSTEM
Performance & Security

Find what is actually slow, then fix it

We measure before we change anything. Core Web Vitals, database queries, cache behaviour, dependency risk and application-level security — assessed, prioritised by impact, then fixed, with before-and-after numbers.

Measure, prioritise, then change

Performance work goes wrong when it starts with a guess. Somebody adds a cache, somebody else compresses the images, and three weeks later the page is still slow because the actual problem was a query running once per row in a loop. So we start with measurement: real user metrics where they exist, profiling where they do not, and a query log from production rather than from a development database with a hundred rows in it. That produces a ranked list where each item has an estimated impact and an estimated cost, and you decide what is worth doing. Security work follows the same shape. A review of authentication, authorisation, session handling, input validation, file handling, dependency advisories and the security headers a browser will actually enforce — reported with severity, reproduction and a fix, not a scanner's raw output pasted into a document. What we do not do is promise you are secure afterwards. We can tell you what we found, what we fixed and what we recommend next. Anybody promising more than that is selling something.

Key benefits

What this changes for your business.

Numbers before and after

Every engagement starts with a baseline and ends with the same measurement repeated, so the improvement is a fact.

Fixes ranked by impact

You get a prioritised list with estimated effort, so the cheap high-impact items are done first.

Findings you can act on

Each issue comes with a severity, a reproduction and a proposed fix — not a scanner report you have to interpret.

Cheaper to run

Query and caching work usually reduces the infrastructure bill as well as the load time.

What we deliver

The things you actually receive.

  • Performance audit

    Core Web Vitals, server response time, asset budgets and the queries behind the slowest pages.

  • Database optimisation

    Indexing, N+1 elimination, query rewriting and the schema changes that make a slow report fast.

  • Caching strategy

    What to cache, where, for how long and how it is invalidated — the last part being the one that is usually missing.

  • Application security review

    Authentication, authorisation, sessions, input handling, file uploads and business-logic flaws.

  • Dependency and supply-chain review

    Known advisories, unmaintained packages and the upgrade path out of them.

  • Security headers and transport

    CSP, HSTS, cookie flags and TLS configuration, tested against what browsers actually enforce.

  • Remediation, not just a report

    We fix what we found, in priority order, and re-measure at the end.

Core capabilities

The engineering disciplines this service draws on.

Core Web Vitals
Query & index tuning
Caching & CDN
Frontend asset budgets
Authentication review
Authorisation & access control
Dependency advisories
Security headers & CSP
Load & capacity testing
Regression test coverage

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.

Redis

An in-memory store used for caching, queues and rate limiting — the difference between a page that waits on the database and one that does not.

PostgreSQL

A relational database with strong support for JSON, full-text search and geospatial data, for models that outgrow plain tables.

MySQL

A widely deployed relational database — a safe, well-understood default for transactional business data.

Docker

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

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.

  • E-Commerce
  • FinTech
  • SaaS
  • Media & Publishing
  • Healthcare
  • Education

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.

A site that got slow as it grew

Pages that were fast at launch and are not now — usually queries, usually fixable in days rather than weeks.

A security review before a deal

A customer or investor asks for one. We produce an assessment with findings, severity and remediation status.

Getting ready for a traffic peak

Load testing and capacity planning before a campaign, rather than an incident report after it.

Why Vertex Arc

We measure first

No change is made on a hunch. The baseline is recorded before the first line is touched.

Findings in plain language

The report is written to be read by the person who has to approve the budget, not only by an engineer.

No guarantees we cannot keep

We do not promise compliance, certification or that you will not be breached. We tell you what we found and fixed.

We fix, not just report

An audit that ends with a PDF has moved the problem, not solved it. Remediation is part of the engagement.

Frequently asked questions

How long does an audit take?
A performance or security audit of a typical business application is one to two weeks, including the report. Remediation is scoped separately once you have seen the prioritised list, so you are not committing to fixes before knowing what they are.
Is this a penetration test?
No. This is a code and configuration review by engineers who read the application, which finds a different class of problem — business-logic and authorisation flaws that a black-box scan does not reach. If you need a formal penetration test for a certification, that is a specialist firm and we will say so.
Can you improve performance without rewriting our application?
Usually, yes. Most large wins come from indexes, query changes, caching and asset handling — none of which require restructuring the code. Where a rewrite is genuinely the only route, we say that and scope it separately.