Skip to content
ShipSureAgency

Discipline 03 — Improve

Launch isn't the end.

Most businesses do not need software delivered and abandoned. They need a system that keeps up with them — and someone who is responsible for it when it does not.

The shape of it

A cycle, not a project with an end date.

Every stage after launch feeds the next one. This is the part of a system's life where most of its value is actually realised, and it is the part most projects skip.

  1. 01

    Build

    The system gets designed and written.

  2. 02

    Launch

    It goes live, with the people who use it ready for it.

  3. 03

    Secure

    Access, data and dependencies reviewed against real use.

  4. 04

    Improve

    Bugs, friction and the things nobody predicted.

  5. 05

    Expand

    The next part of the business it should cover.

And round again — for as long as it is useful

Why it matters

Software that nobody maintains doesn't stay still.

It gets slowly further from the company using it. The business changes — a new service line, a different approval, twice the volume, a rule that used to be an exception — and the system does not.

Meanwhile the ground underneath it moves. Libraries accumulate published vulnerabilities. Platforms deprecate the APIs it depends on. Certificates expire. None of that announces itself.

Eighteen months later the workarounds are back, and the business is having the same conversation it had before the project — except now there is a system to rewrite as well. The monthly cost of keeping software current is a fraction of the cost of replacing it.

The arrangement

What you're actually paying for each month.

Typically £1,000 to £5,000 a month, scaled to how much the system matters and how fast it needs to move. The number is agreed in advance and reviewed openly, not indexed to how busy we happen to be.

Maintenance
Bugs fixed, small changes made, questions answered — by someone who already knows the system rather than someone reading it for the first time.
Security upkeep
Dependencies updated on a schedule, patches applied, access reviewed as people join and leave. This is the work that quietly does not happen when nobody owns it.
Monitoring and response
Errors and downtime reported to us automatically, with an agreed response when something is actually broken.
New development
An agreed amount of engineering time each month for the features, reports and integrations the business turns out to need.
A regular conversation
A call about what changed, what is next, and — often the most valuable part — what is not worth building.

Ownership

Everything we build is yours, including the ability to leave.

  • You own the code. In your repository, under your account, from the first commit rather than on completion.
  • You own the infrastructure. Hosting and services are in your accounts, billed to you, with us as a user we can be removed from.
  • You own the data. Exportable in a usable form, whenever you ask, without it being a project.
  • Handover is written before it is needed. Architecture, access and how to run it — documented for a developer who has never met us.

This is not generosity. A supplier who is hard to leave stops having to earn the relationship, and that is the point at which the software starts getting worse.

Reasonable questions

The things people ask before signing up to a monthly cost.

What if we have a quiet month?

A quiet month still contains dependency updates, monitoring, backups and the review that keeps them meaningful. Where there is genuinely nothing to do we would rather bank the development time than invent work, and we will tell you if the arrangement has stopped earning its place.

Are we locked in?

No. You own the code, the data and the infrastructure, and the documentation is written for somebody who has never met us. A monthly arrangement that can be ended is the only kind worth having — it means we have to keep being worth it.

What if we hire our own developer?

Then you should, and we will hand over properly. Plenty of businesses use us until an internal team makes sense; some keep us afterwards for the security and infrastructure work a small team should not have to carry alone.

Can you take over software somebody else built?

Yes, and it is a common way to start. It begins with a review of what is there and an honest answer about whether it is worth keeping — occasionally it is not, and that is worth knowing before you spend another year on it.

Start here

Already have software nobody is looking after?

That is one of the most common reasons businesses get in touch, and it is a straightforward thing to fix. Tell us what exists and we will tell you what state it is in.