EN中文MY
Free diagnostic

This belongs to Stage 6Partnership

Ongoing Partnership

The system went live and everyone relaxed. Three months later a small problem has nobody to fix it. Six months in, a new feature is needed and whoever built it cannot be reached. A year on, someone suggests rebuilding the whole thing. You may have been through this cycle already.

When something breaks the original builder is unreachable, and a small change takes weeks. An ongoing relationship keeps the technology a compounding asset rather than a project that depreciates.

Rebuilding costs more than a second development fee. You go through requirements again, retrain the team again, take the launch risk again — and this time with slightly less trust in anyone technical. The more concrete loss is the intervening period: the system stands still while the business moves, and the gap widens every month.

The root cause is the structure of project delivery itself: delivery ends the engagement, so nobody's interest is tied to the system's long-term health. The developer's responsibility completes on handover day, and every change after that is a fresh piece of business. Nobody has to act in bad faith for this to end with nobody owning the system. The business changes, the system does not, and after two years the gap leaves only a rebuild.

Two lines after launchBusiness needs keep rising. A system delivered as a project stops moving on launch day, and the gap widens year by year until only a rebuild is left. A system under continuous improvement moves with the business.NEEDTIMELAUNCHThe business keeps movingA system that ended at deliveryREBUILDContinuous improvement keeps the lower line tracking the upper one.Small changes as they are needed, not a rebuild every second year.
A system whose engagement ends at delivery starts diverging from the business on launch day.

How the work runs

  1. Somebody is watching

    Monitoring, backups, security updates, performance. Most incidents give warning first, and someone watching catches them in time. Without that, you find out when a customer tells you.

  2. Problems have somewhere to go

    When something breaks you know who to contact and roughly how long a reply takes. That sounds basic. It is also the single thing most often missing after a project-based handover.

  3. It changes as the business changes

    A new branch, a new product line, a change of accounting software — the system adjusts alongside, instead of waiting until the gap forces a rebuild. Continuous small changes cost far less across years than one large reconstruction.

  4. Periodic reviews of direction

    Sitting down periodically to look at what is used, what is not, what is worth doing next, and what built earlier can now be removed. Including the conclusion that a part of this no longer needs us.

What changes for the business

The system does not quietly decay
Updates get applied, problems get fixed, and backups actually restore. The last one is widely assumed and discovered to be untrue at the worst moment.
Changes are additions, not restarts
Because somebody stays familiar with it, adding something does not start with two weeks of relearning the codebase. That is the most concrete cost advantage of a continuing relationship.
Technical decisions have a second head
Whether to switch a vendor, whether a quote is reasonable, whether a new tool is worth trying — questions you can ask before deciding, instead of carrying alone.
A predictable cost
A monthly retainer or an annual agreement, rather than a quotation every time something breaks. A predictable cost is easier to plan around than a low one.

What's included

  • Maintenance & Monitoring
  • Hosting & Domain Management
  • Technical Support
  • Continuous ImprovementRegular reviews of what comes next — and what still shouldn't

Ongoing

This offering is the ongoing mode: a monthly retainer or annual agreement rather than a one-off delivery.

This one is quoted individually

Website packages publish a floor because their scope is bounded. This does not, because the range is too wide for a figure to mean anything — a number in the middle deters the small project and over-promises on the large one. A free diagnostic settles the scope first, and the quotation follows from it.

See the published package prices, and why this is not one of them

When this isn't the right thing yet

Not yet: rebuilding to chase new technology. Change should be driven by what the business needs, not by what is currently fashionable.

Common questions

Can you take over a system you did not build?
Usually, but we look first. An audit comes before an answer: the state of the code, whether documentation exists, whether its dependencies are still maintained, whether there are obvious security problems. Some systems are worth taking over and continuing. Some we will honestly recommend replacing. Either way you get the reasoning, not just a yes.
How is this different from a warranty?
A warranty fixes what broke, within the scope originally delivered. A partnership includes that, but its point is different: keeping the system moving with the business. One holds things as they were; the other keeps them useful. That is also why the pricing shape differs.
Can I stop at any time?
Yes, and everything remains yours when you do: domain, hosting, code, data. We do not keep clients by making leaving difficult. A relationship that has to be held together by lock-in was not going to last anyway.
We are small. Do we need ongoing maintenance?
If your site is a company profile that rarely changes, basic hosting and updates may be enough and we will say so rather than sell more. But once a system holds customer data, transactions or logins, maintenance stops being optional — the cost of skipping security updates is not the repair bill, it is the trust.