Custom functionality, built as a proper add-on.
So that what you paid for is still there after the next upgrade.
CS-Cart will let you change almost anything, including things you shouldn't touch. The quickest route to a new feature is usually to edit the core or the parent theme directly, and it works: the feature appears, the site runs, everyone's happy.
Then the upgrade comes, and the work is gone.
Free CS-Cart health check for new clients outside Japan
A written review of where your store actually stands: whether the core has been modified, how risky your next upgrade looks, and what I'd fix first. No charge, and no obligation to hire me afterwards.
Go ahead with the work and you also get $500 off the quoted price, in exchange for a testimonial I can publish once it's finished.
Five spots to start with. I may close this sooner, or open a few more. This page will say which. Testimonials are written after the work is finished, and published with a note that the client received a launch discount.
Why it matters where the code lives
An add-on is the mechanism CS-Cart gives you for adding functionality without modifying the parts an upgrade replaces. Same feature, different place to put it.
Written into the core or parent theme
- Works on the day it's built
- Wiped or broken at upgrade time
- Recovery means working out what was changed, often without documentation
- So upgrades get postponed, and the store falls behind
Built as an add-on
- Works on the day it's built
- Still there after the upgrade
- Can be disabled or removed without unpicking the rest of the site
- Legible to whoever looks at it next, including a different developer
The difference isn't visible on launch day. It shows up the first time you upgrade.
That's what makes it easy to get wrong, and why so many CS-Cart sites end up unable to move forward. More on that in Why CS-Cart.
What I can build
If CS-Cart doesn't do it and you need it to, that's usually an add-on.
- Features specific to how your business actually operates
- Changes to how existing CS-Cart functionality behaves
- Admin-side tools for the people working in the store daily
- Integrations with external services and APIs
- Automating steps your team currently does by hand
- Adjustments to storefront behaviour that go beyond the theme
* Not everything needs to be an add-on. Part of the job is saying which approach actually fits, rather than defaulting to the largest one.
Existing add-ons and existing damage
Changing an add-on you already have
Modifying or extending an add-on that's already installed is normal work, whoever wrote it. I'll look at how it was built first, and tell you honestly if changing it is a worse idea than replacing it.
Getting customizations back out of the core
If your site already has changes written into core files or the parent theme, they can usually be moved into an add-on instead.
The work is less about writing the add-on and more about finding what was changed and why, since that's rarely written down anywhere. It's worth doing before an upgrade rather than during one.
If you're not sure which situation you're in, that's a fine thing to ask about. Working it out is part of the job.
How I work on these
- What you need it to do. Described in business terms is fine; you don't need to specify it technically.
- How it should be built. I check what CS-Cart already provides, whether an add-on is the right answer, and what it would touch.
- Scope and estimate, agreed before anything starts.
- Built and installed, with the upgrade path in mind rather than just today's behaviour.
- Yours afterwards. It runs on your server and you're not tied to me to keep using it.
* Pricing depends on the requirement, so I quote per request. You'll have the number before work starts.
FAQ
Why build an add-on instead of just editing the code?
Because edits written over core files or the parent theme are wiped or broken when you upgrade.
An add-on is the mechanism CS-Cart provides for adding functionality without touching what the upgrade replaces, so your customization is still there afterwards.
Can you fix customizations already written into the core?
Yes, and it's common work. Moving existing changes out of core files and into an add-on is usually possible.
The first step is finding what was changed and why, since undocumented edits are normally the reason an upgrade feels risky in the first place.
Can you modify an add-on somebody else wrote?
Usually, if the code is available on your installation. I'll look at how it was built before changing anything, and say honestly if modifying it is a worse idea than replacing it.
Is my requirement too small for an add-on?
Small requirements are normal here. If it's small enough that an add-on would be overkill, I'll say so and suggest what fits instead.
For one-off fixes and minor changes, Quick Fix is probably the better starting point.
Do I own the add-on afterwards?
Yes. It's built for your store and installed on your server, and you're not tied to me to keep using it.
Will it survive future CS-Cart versions?
That's the point of building it this way, and it's far more likely than with core edits. But no honest answer here is an absolute guarantee: a large enough change in CS-Cart itself can affect anything built on top of it.
What I can say is that it's built to be upgradeable, and that when something does need adjusting, it'll be a contained job rather than an excavation.
Got a requirement CS-Cart doesn't cover?
Describe what you need it to do, in whatever terms make sense to you. I'll come back within 24 hours on whether an add-on is the right answer and what it would involve.