Reworking and Improving an Existing Website or Online Store

Yes. It's a distinct kind of work, and we do it all the time. It starts with an inventory rather than code: what access exists, which platform version is running, and how much of the scope was actually completed. Sometimes after the review we advise against further work, and that's an answer too, one you don't pay for.

By the cost of the next step. If every new feature means rewriting the ones next to it, and modules can't be updated without things breaking, it's no longer rework. The exact line only shows up once we've looked at the code, which is why the first review is free: getting this decision right matters more than the cost of the work itself.

In most cases, yes, but it depends on what exactly was lost. Hosting and domain access can be restored through the registrar and provider in the owner's name, meaning yours. Access to someone else's repository can't be recovered, so in that case we work with the code that's on the server. What's been lost becomes clear during the review.

That's exactly why we work on a copy and not on the live site. After every change we run the full scenario: product page, cart, checkout, payment, shipping label. The 30-calendar-day warranty covers precisely this: if something stops working because of our change, we fix it free of charge.

Anywhere from a day or two for a single module to several weeks for taking over a neglected project. The difference comes from the state of the code underneath the feature, more than from the feature itself: the same task in a tidy store and in a site with a dozen homemade patches are different amounts of work. We give a timeline after the review.

Yes, but it's a separate job, not a side effect of other changes. The risk isn't the update itself. Homemade edits by previous developers are often made directly in the core, and they disappear after an update. So we first check what's been changed there, and only then plan the move.

We can, but that's a separate agreement: one-time rework and ongoing support are different things with different scopes. It's equally fine if your own developer takes it from here. Everything we did stays in your repository with a description of the changes, so whoever comes next doesn't have to start by untangling someone else's code.

OpenCart is our main platform, but we also take on rework for WordPress and WooCommerce. We don't have separate pages about Joomla or other engines, so we decide after a diagnostic: if the version still receives updates and the core hasn't been rewritten from the inside, rework is possible. If the platform is so outdated that every edit drags along updates to half the modules, we'll tell you before work starts and compare it with a migration. The diagnostic is free, and you keep its findings.

Less on the feature itself than on the code it has to fit into. The same button on a clean template is a small edit, while on a site where previous developers changed core files and modules without any notes, it's a separate job with its own testing. The platform version, whether there's a test copy, and how much needs checking after the change also matter: in a store, that always means the scenario from product page to payment. We don't publish prices for the same reason. We give an estimate after the diagnostic, broken down by task, and fix it in the contract.