Custom Bagisto package: where the stock logic breaks
The stock Bagisto build covers the basic store scenario, but as soon as non-standard logic appears — custom discount calculation rules, warehouse integration, exchange with an external order system — extending the stock logic by editing the core turns into a ticking time bomb.
The very first platform update overwrites the modified files, and the store either crashes or quietly loses part of its functionality: orders go through, but the discount is not applied.
The second bottleneck is logic duplication. When the same price calculation or delivery condition lives in a controller, a template, and an event handler, any change requires a synchronized edit in three places.
Sooner or later one of them is forgotten — and the store's behavior diverges depending on which page the customer came through.
The third problem is the lack of module isolation.
Without clear boundaries, extending the store's functionality becomes overgrown with hidden dependencies: the discount module knows about the delivery module, that one knows about the logs, and it is no longer possible to disable or replace one block without editing the others.
A custom Bagisto package solves this differently: the logic is moved into a separate package, the core remains untouched, and platform updates proceed without conflicts during upgrades. Let's break down how this is structured and exactly where the stock build starts to get in the way.
What an isolated package delivers: the effect in numbers
A custom Bagisto package is a separate module with its own namespace, configuration, migrations, and routes, connected to the platform as a self-contained unit. Store logic isn't smeared across the core and theme: changes live in a single repository with its own change history.
It's this code isolation that delivers a measurable effect, not "tidy architecture" on its own.
Platform upgrade speed increases many times over. When customization doesn't touch the core, moving to a new Bagisto branch comes down to updating the dependency and running the package tests — instead of manually comparing hundreds of modified files.
An upgrade that used to stretch over weeks now fits into one or two business days, and the production downtime window shrinks to a scheduled release.
Fewer regressions is a direct consequence of module boundaries. A change in discount logic or shipping calculation doesn't affect checkout, because the connections between parts are described by contracts rather than implicit dependencies.
Test coverage of the package shows which scenarios are affected by a change, and the number of unexpected breakages per release drops severalfold.
Support predictability is when a new team or a new engineer joins the project without archaeology.
The package structure reads section by section, the entry point into each function is known, and rolling back to a previous version of the module doesn't require touching the rest of the system. Describe your task — we'll come back with an estimate and a plan for how it fits your store.
Implementation options: package, theme, or core modification
The three approaches differ not in "code purity," but in what happens to your store at the very first platform update. An extension package plugs in on top of the core and does not touch its files — updates install as standard, and your logic stays in a separate layer.
Modifying the core solves the task fastest at the start, but every update turns into a manual comparison of changed files: the more modifications, the higher the risk that the next release will overwrite the customization or break checkout.
A custom theme covers only the presentation — markup, templates, storefront design — and is not suitable when you need to change cart logic, shipping calculation, or synchronization with an accounting system.
| Option | When it fits | Limitations of the approach |
|---|---|---|
| Extension package | New logic is needed: pricing rules, integrations, non-standard shipping calculation, custom sections in the admin panel | Requires designing hook points; some tasks hit the absence of an event in the core |
| Core modification | A one-off urgent fix that cannot be postponed | Updates are installed manually, conflicts grow with each modification, rollback is difficult |
| Custom theme | Storefront changes: markup, templates, design of product cards and cart | Does not change business logic; when core templates change, it requires re-checking |
Compatibility with updates
A package maintains compatibility predictably: a core update and a package update are independent events, and we record which hook points are affected in the new branch.
A core modification offers no such guarantee — with every release you need to check whether your code has overlapped with changes from the platform developers.
Mixed scenario
In practice, the most common combination is: we move logic into a package, the storefront into a theme, and reduce core modifications to zero or a minimum with explicit marking so they are visible during updates.
This arrangement provides standard updates without downtime and a clear rollback to the previous version.
Package implementation stages: from audit to handover
Work on the package proceeds in iterations, but within each iteration the order of stages is fixed: first we understand how the store is currently structured, then we design the changes, and only then do we write code.
This order removes the main risk of custom development — a package that conflicts with already installed extensions or breaks checkout.
- Store audit. We review the current configuration, installed extensions, theme and core customizations, and the points of intervention in checkout and the catalog. We identify what can be extended with built-in tools and what requires overriding — this determines the scope of work before development begins.
- Package blueprint. We design the structure: which entities and tables are added, which events and observers we use, and how the package interacts with existing modules. We agree on the blueprint with you before writing code — changes at this stage cost hours, after release — days.
- Integration setup. We connect the package to external systems: warehouse, payments, shipping, accounting systems. We configure each connection with error handling and retries so that a failure on the service side does not bring down checkout.
- Scenario testing. We run the full customer journey — from adding a product to payment confirmation, including returns, partial cancellations, and operation with multiple warehouses. We separately test behavior when an external service is unavailable.
- Documentation handover. We provide a description of the package architecture, instructions for updating and rolling back, the data schema, and the procedure for typical failures. Your engineers can maintain the package independently, without depending on us.
The stages come with checkpoints: after the audit you see the scope and plan, after the blueprint you approve the architecture, after testing you receive a scenario report. Describe your task — we will come back with an estimate of timelines and scope of work.
Deliverables: what the customer's team receives
We hand over not a "folder with code" but a complete set that your team can use to maintain the package without us. Below is exactly what is included in the handover.
- Package configurations — settings files with a description of each parameter: which values are mandatory, which depend on the environment, and what changes when a new channel or language is connected. We separately flag the places where an edit breaks compatibility with the core.
- Integration diagrams — how the package connects with the catalog, order processing, payment, and inventory accounting: which events it listens to, what data it exposes outward, and where the boundary of responsibility lies between the package and the platform core.
- Update procedures — the sequence of actions when a new core branch is released: what we check before updating, how we roll back, which data migrations are performed and in what order. With the rules under which an update is postponed.
- Instructions for the team — deployment on a clean environment, local launch, typical failures and their symptoms. Designed for a developer who is seeing the project for the first time.
- Module documentation — the purpose of entities, extension points, public methods with usage examples. Plus a decision log: why this structure was chosen and which alternatives were rejected.
- Set of automated tests — coverage of key scenarios: order processing, cart recalculation, stock synchronization. The tests run with a single command and serve as a safety net during modifications.
- List of dependencies — external libraries with an indication of which can be updated freely and which are tied to the package logic and require verification.
We hand over the set on a call with a walkthrough: your engineers ask questions about the code and diagrams, and we demonstrate deployment on a test environment. Describe your task — we will come back with an estimate and a handover plan.
Case study: how an isolated package eliminated regressions
The client is a chain of retail stores on Bagisto with several regional storefronts. Loyalty logic, delivery calculation, and promo rules lived directly in the core and in the storefront theme, so every platform update turned into manually editing dozens of files.
Regressions popped up either in the cart or in checkout, and before every release the team spent a week running scenarios manually.
What it was before
An update took 3-4 days: first edits in the core, then reconciliation with the new version, then a rollback if something broke. Over a quarter, 9-12 production failures were recorded, a third of them in checkout, meaning lost revenue.
Tests covered less than half of the user paths, and changes in the theme affected the calculation logic.
What was changed
All business logic was moved into a separate package: its own services, models, migrations, and events, without edits to the core and theme.
The package is connected as a regular dependency, configuration is done through a settings file, and extension points are handled through events and service substitution. The theme remained only about appearance, the core — only about basic functionality.
What it became
Platform updates were reduced to a few hours: edits in the package do not conflict with the core, and a rollback is simply disabling one dependency.
The number of production failures dropped from 9-12 to 1-2 per quarter, test coverage grew to most of the user paths, and releases began shipping twice as often without late-night fixes.
A separate effect is predictability: a new storefront is set up by copying the package and changing settings, rather than forking the entire store. Loyalty and delivery logic is now the same for all regions, and discrepancies between storefronts are gone.
How is a package different from directly editing the core?
Directly editing the core is when a platform file is changed in place: a line is edited in a controller, model, or template, and everything works right up until the first update.
Formally, the task is solved, but the solution lives inside someone else's code and is not recorded separately anywhere.
On the next update, the platform overwrites the modified files, and the edits disappear — or, worse, conflict with the new version and break scenarios that were already working.
A package is a separate module that connects to the platform and extends it through standard extension points: service providers, events, overriding templates and routes. The core remains untouched, and all the logic resides in an isolated directory with its own namespace.
The difference shows up precisely in maintenance: updating the platform does not affect the package's code, and if a new version changes some interface, one place in the module is fixed rather than hunting down dozens of edits across the entire core.
Isolation has two more practical consequences. The first is predictable rollback: the package is disabled with a single command, and the system returns to its original behavior without restoring from a backup.
The second is portability: the same module can be installed on another project with the same platform, if the logic is not tied to a specific theme or set of edits.
The risk of directly editing the core is not that it will break today, but that the cost of maintenance grows with every update. After several updates, no one remembers which files were touched or why, and any update turns into a manual merge.
A package records changes in one place and makes updates a routine operation rather than a project with an unpredictable outcome.
Common technical concerns when developing a package
Concerns usually come down to four things: version compatibility, data migrations, testing, and updates without downtime. Below is how we address each of them at the architecture level, not with promises.
Will the package work with our version of Bagisto and not break upon update?
We build a custom Bagisto package as a standalone module with explicitly declared dependencies: the range of supported core versions is fixed in the manifest, not "in words." Extension points — events and service providers — are chosen so as not to override the core entirely: during an upgrade, the platform is updated while the package logic remains untouched.
Before each update, we run the package on the target branch in an isolated environment and record a compatibility matrix — you can see in advance which versions are supported and which require rework.
How is data migrated from the old system without loss?
Migrations are idempotent and split into stages: first the structure (tables, indexes, relations), then data transfer in batches with checksum verification, then reconciliation of counts and key fields. Heavy operations are performed in chunks so as not to lock the database.
Each stage has a rollback point: if the reconciliation does not match, we return to the previous state without manually editing tables.
How do you test the package and what about updating without downtime?
We cover critical scenarios with automated tests — checkout, calculation, synchronization, access rights — and run them on every build.
We roll out the update using a traffic-switching scheme: the new version is brought up alongside, tested on production data, and only then does the load shift to it. If a problem occurs, traffic returns to the previous version within minutes, without stopping the store.
If you still have concerns about your stack — describe the task, and we will come back with an estimate and a work plan.
Let's discuss your task and come back with a plan
To make the estimate substantive rather than a "ballpark from the ceiling," we start with an analysis of the task, not with a price list.
It's important for us to understand exactly what the standard functionality doesn't cover: product types, pricing and discount rules, warehouse logic, integrations with the accounting system, storefront requirements.
The more precisely the scenario is described, the fewer assumptions in the work plan and the more honest the timelines.
Next, an engineer analyzes what can be solved through configuration and what requires a separate module. A custom Bagisto package is justified when the logic goes beyond standard solutions and needs to be isolated so that platform updates don't break the customizations.
We define the boundaries of the package, the extension points, and how it will coexist with the core.
What happens after you reach out
- Task analysis. A call with an engineer: which processes need to work, who uses them, what already exists in the system.
- Audit of the current solution. We review the installed version, installed modules, core customizations, and update risks.
- Scope alignment. We separate what is covered by configuration, what by a package, and what we take outside the project boundaries.
- Timeline and phase estimate. We break the work into verifiable steps with a clear result at each one.
- Work plan. We define the sequence, dependencies, acceptance points, and the order of rollout to the production environment.
- Approval and kickoff. After the plan is approved, we assign a responsible engineer and start with the first phase.
If during the analysis it turns out that the task can be solved without custom development, we say so directly — it's cheaper and faster for you. Describe the task in free form: what kind of store it is, which processes aren't covered, what you've already tried. We'll come back with a timeline estimate and a work plan you can use to make a decision.
