GM Vertex
02 / Capabilities

What we build

GM Vertex Limited develops software to order. Each project begins with a specific operational problem, and the resulting application is shaped to that problem — its data, its users and the way the work moves through an organisation.

001Custom web applicationsApplications delivered through the browser, built for a defined set of users and tasks. Accounts, permissions, data entry, search and reporting are designed for the job in front of them rather than added as generic features.
002Business workflow toolsSoftware that carries a process from one step to the next — requests, approvals, handovers, scheduling and status tracking — so the current state of any item is visible without asking someone.
003Information management systemsStructured storage for the records an organisation depends on, with sensible categories, controlled editing, history and the ability to find things again quickly.
004Customer-facing digital applicationsInterfaces used by the people an organisation serves: bookings, submissions, account areas, forms and self-service pages, designed to be usable without instruction.
005Internal administration toolsBack-office screens for staff — managing content, users, settings and day-to-day records — often the part of a system that decides whether the rest of it gets used properly.
006Productivity softwareSmaller, focused applications that remove repetitive effort: checklists, trackers, generators, converters and utilities that fit into an existing routine.
007Bespoke software enhancementsWork on software that already exists — extending functionality, reworking awkward areas, improving performance or connecting it to another system in use.
Adapted, not packaged

No fixed product to fit into

We do not sell a single platform and then adjust a client’s processes around it. Every project is scoped from the requirements we are given, which means the finished software contains what the organisation needs and leaves out what it does not.

In practice that usually means fewer screens, fewer settings and fewer unused features than an off-the-shelf package — while the parts that matter to a particular business get proper attention. Where an existing tool already does part of the job well, we say so, and build only the gap.

The measure of a build is whether the people who asked for it use it after the first month.

How we work through it

Consistent practices on every build

These apply to a two-week utility and a multi-month system alike. They are the parts of the work that keep software maintainable once it is in daily use.

  • Requirements written down before code is written
  • Data structures designed around real records, not assumptions
  • Interfaces tested on the devices people actually use
  • Access levels matched to roles within the organisation
  • Documentation handed over with the software
  • A clear route for changes after delivery
See the five project stagesDiscuss a Project