Customise It, Then Keep It Patchable: Running a Licensed Platform After Launch

Buying a licensed SaaS script is a reasonable way to start a product. The trouble usually arrives after launch, when the vendor ships an update and the customised copy running in production can no longer take it. On two licensed Laravel platforms we deployed for clients (a multi-user portfolio and CV builder, and a multi-tenant course marketplace), the work that mattered most for the long run was making each platform patchable after it went live.

The trap: a customised copy that can never be updated

Most licensed platforms are customised the fastest way possible: edit the vendor's files until the product looks and behaves the way the business needs. It works on day one.

On the day the vendor releases a security fix, there is a problem. Applying the update overwrites the customisations. Not applying it leaves a known vulnerability in production. Teams in this position often stop updating altogether, and the platform slowly becomes a legacy system that nobody wants to touch.

A self-update path

On the portfolio builder, we added a self-update controller and refactored the platform's service provider so that applying updates became a defined operation rather than a manual reinstall. On the course marketplace, we added a self-update mechanism and brought the platform up to a newer version before doing anything else.

The principle is the same in both: the platform should have one known, repeatable way to receive updates, and that path should be part of the deployment, not an afterthought discovered during an emergency.

A good update path does a few things:

• Applies the new version in a predictable order.
• Runs any pending database migrations.
• Clears caches that would otherwise serve stale configuration.
• Can be run again safely if something interrupts it.

Keep customisations where updates cannot reach them

A self-update mechanism only helps if the update does not wipe out your changes. That depends on where customisations live.

The rule we follow is to change vendor files only when there is no alternative, and to put everything else in clearly separated places: configuration, environment variables, service providers, views and assets that the platform loads rather than ships. When a vendor file must change, it is a documented, deliberate edit that someone can re-apply after an update.

The storage work on these platforms followed the same idea. Moving files to object storage went through one helper or one URL generator, so there was one piece of code to re-check after an update rather than every controller. We describe that in our object storage playbook.

Fix the small things that users hit

Deployment work on a licensed platform is also where the rough edges show. On the portfolio builder, we corrected the CV download path through several iterations until it behaved reliably from object storage, and fixed a localisation fallback on profile views. We also enforced HTTPS across the platform.

None of these is glamorous. All of them are the difference between a platform that technically runs and one a client can put in front of customers.

Working alongside the client's own contributors

The portfolio builder was delivered in a shared workflow with the client's own contributors working in the same codebase. That setup works well when a few things are agreed up front:

• One source of truth. A single repository and branch strategy that everyone uses, rather than copies that drift.
• Clear ownership of areas. Who changes vendor code, who changes customisations, who deploys.
• Reviewable changes. Small, described commits, so either side can understand what changed and why.

A shared workflow is also a good sign for the client. It means they are not locked into any one developer, including us.

Before you customise a licensed platform

• Confirm how the vendor ships updates and how often.
• Decide where customisations will live before writing any.
• Build or configure a repeatable update path, and test it once before launch.
• Record every unavoidable vendor-file edit.
• Upgrade to the current version before large changes such as storage migrations.
• Agree the repository workflow with anyone else who will contribute.

For the broader question of whether to build on a licensed script at all, see what we check before building on a licensed script. The anonymised project write-ups are for the portfolio builder and the course marketplace.