Who Runs Your Software After the Build?

Perspective · 25 October 2026

Your webshop still takes orders, but the person who built it is no longer available. A payment provider changes its interface. Who checks the impact, makes the change and stays responsible after it goes live?

That is an illustrative situation, not an anonymised client story. It separates two responsibilities that can be agreed together but should not be confused: delivering software and maintaining it afterwards.

First Establish What Needs an Owner

A webshop, a custom admin panel and a spreadsheet workflow need different kinds of attention. Consider these examples as patterns to examine, not claims about named engagements or how common they are:

• An older webshop: check platform support, payment integrations, updates, backups and the route for testing changes before they reach checkout.
• An internal tool: establish where the code lives, how it is deployed, which business rules it implements and who can authorise a change.
• A spreadsheet workflow: identify who edits which copy and what other systems depend on it. Keeping the sheet and improving its integration may be an option; replacing it is not automatically the first step.

An agency may already offer ongoing support. A freelancer or internal engineer may do it well. The question is not which kind of supplier built the software, but whether responsibility, access and scope are explicit now.

Maintenance or Rebuild Is a Technical Decision

A takeover starts by finding out whether the existing software can be maintained responsibly. Missing access, unsupported dependencies or a platform that no longer fits the process can change the answer.

A rebuild may be appropriate. It also needs a plan for migration, continuity during the switch and ongoing maintenance afterwards. Keeping the current system may avoid some migration work, but it is not necessarily cheaper or safer. We cannot make that comparison without examining the system and the required scope.

The same applies to standard products. If an off-the-shelf service meets the need, adopting it can be a better choice than maintaining custom code. Management should not preserve a system merely because it exists.

Where Agents Help, and Where They Do Not

AI-assisted development can help trace a code path, explain a configuration, draft a change or write a test. Those are useful parts of taking over unfamiliar software. They are not evidence that an agent understands a whole project or can safely maintain any legacy system.

Context limits, unavailable source code, undocumented dependencies and restricted access all affect what it can establish. A plausible explanation needs checking against the implementation and the running behaviour. Proposed changes need review and testing in the appropriate environment.

We do not claim a fixed reduction in onboarding time or maintenance cost from that tooling. Nor does it provide human backup or round-the-clock cover. A person remains responsible for the engineering decisions; agents assist with the work rather than taking over that responsibility.

What SFLOW Offers to Manage

Our offer is maintenance of agreed business applications, not devices or general office IT. The software stays yours. Issues and changes are visible through the portal so you can follow the agreed work from report to delivery.

Scope and capacity depend on the applications we take on and the management tier. Requests are prioritised; joining the list does not mean unlimited work starts immediately. Third-party dependencies can constrain what can be delivered.

Agent triage helps classify incoming reports. Triage is not resolution. It does not mean every issue is fixed immediately or that every change has the same urgency. The approach page explains the management options.

What we deliver stays our responsibility. If something doesn’t work as agreed, we put it right. One accountable contact does not imply a second human operator is always available.

What We Need From You

We need authorised access to the relevant code, hosting and systems. If a vendor controls a necessary API or deployment step, we need to establish that dependency before committing to the work. We cannot promise a delivery date or fixed price for work gated by a third party's decisions.

Someone in your business must set priorities and accept business trade-offs. That does not mean you need to supply your own technical oversight. SFLOW supplies engineering accountability for the agreed scope; you decide what the business needs the software to do.

Management starts with a paid Software Health Scan, not an open-ended free takeover assessment. It examines the running software for bugs, security risks and overdue maintenance, and produces prioritised findings. The scan's scope and price are agreed first. Afterwards you decide whether to proceed with fixes or management; there is no obligation to continue.

If the software needs replacement, a standard product fits better, or the necessary access is unavailable, that should be clear before a management commitment. The purpose of the first step is to establish what can responsibly be taken on.

See the Health Scan, management scope and pricing.