• Enhancements

Custom module: when there is no ready-made solution for your task

The development of a custom module for an online store is necessary when there is no solution for your task in the market - or it is there, but it does not do the right thing. We write extensions using the standard mechanisms of the platform: events and modifiers, without any modification in the core files. The amount depends not on the description of the task, but on how many places in the store the module should intervene. Therefore, first a free analysis, then a deadline and an estimate.

See how it works
Price
after a free audit
Guarantee
30 days after project sign-off
Term of works
5-30 working days, depending on the number of intervention points
Price
after a free audit
Guarantee
30
days after project sign-off
Term of works
5-30
working days, depending on the number of intervention points
Editing in the kernel
null — platform events and OCMOD modifiers
Before the estimate
analysis of the problem, 2-4 working days, free of charge
Weekenders
are given to you together with the documentation
Shutdown
the module is removed without consequences for the store
Guarantee
30
calendar days for completed work
Process steps

Transparent stages with approval at every step

Total duration:5–30 days

  1. Problem analysis and technical description

    1-4 working days

    We listen to the problem in your words, check whether it is closed by a ready-made solution, and divide it into points of intervention. The output is a document based on which the estimate is calculated and the work is accepted.

  2. Test site and map of interventions

    1-2 working days

    We raise a copy of the combat site with the same extensions. There is also a list of places where the module adds its behavior, and a list of extensions that already work in these places.

  3. development

    1-15 working days

    We write the module with platform events and modifiers, put it in Git. Settings in the admin, error handling, and the action log appear together with the main logic, rather than being added at the end.

  4. Checking scripts and compatibility

    1-6 working days

    We run the module on real scenarios of the store and see how it lives next to the installed extensions. We check the shutdown as a separate item: the store should work even without the module.

  5. Installation, documentation, transfer

    1-3 working days

    We put on the combat site in the agreed window, give the sources, documentation and access to the repository. We go through the settings with your person on a live example.

Technologies & integrations

What we build on and what it connects to

Stack

  • OpenCart 4.x is a branch under development; set by default
  • OpenCart 3.x — when the module needs to live next to extensions that do not yet have builds under 4.x
  • Platform events instead of kernel edits — the module undergoes updates; limit: there are not enough events for every place, and we talk about such places before the start
  • Modifiers OCMOD — change markup without changing files; limit: two modifiers per template are fighting, so the intervention map is drawn before the code
  • PHP and MySQL are a native pair of the platform, we do not add unnecessary dependencies
  • Git is a history of changes and the ability to roll back; the repository is yours
  • A test site as a copy of a combat one - conflicts are visible before launch
  • Logging to a separate table or file—without logging, troubleshooting a crash becomes a guesswork

Integrations

  • API of payment providers
  • Carrier API
  • 1C / BAS
  • KeyCRM
  • XML feeds
  • SMTP
  • SMS gateways
  • Telegram
  • Google Tag Manager
  • GA4
What's included

Complete list of work and what you get as a result

  • The technical description of the task, agreed before the start: it says both what the module does and what it deliberately does not do - this document then closes the dispute about the limits of work
  • Implementation by platform events and modifiers, without editing core files — so that the store can be updated further and not frozen on an unsupported version
  • Configuring the module in the admin: the behavior is changed by your manager, not by the developer on a separate account
  • Checking compatibility with already installed extensions on copies of the combat site - conflicts are visible before launch, and not months later, when no one will associate them with the module anymore
  • Error handling and clear messages instead of a silent failure: the buyer sees what went wrong, the manager sees the same in the admin
  • Logging of module actions in a separate table or file - when something happens, analysis starts with the log, not with guesswork
  • Code in Git with a clear structure and comments: the history of changes remains with you and allows you to roll back
  • Documentation: what it does, how it is configured, where to look for problems - so that the module can be picked up by another developer
  • Installation on a combat site with the ability to disable the module without consequences for the store
  • The source transfer to you is your module, not ours, and we do not sell licenses for it
  • Terms: payment by stages, warranty period of 30 calendar days for completed works
When this service isn't right

What's not included — so there are no surprises at delivery

  • Compatibility with future major versions of the platform is honestly impossible to promise
  • Licenses and support of third-party modules with which ours interacts
  • Continuous support after the warranty period is a separate service with separate conditions
  • Tasks that are closed by standard settings: you will hear about this in the debriefing, before the bill
  • Hosting, domain, acquiring
Who it's for

Situations where this service delivers results

Scenario 1 of 4

There are five similar modules on the market, and none of them do what they should

You have already bought two, tweaked the settings, and each covers two-thirds of the task. Then the fork: keep both and put up with the fact that they fight for the same place in the template, or order one extension exactly for your process. Analysis is needed precisely to understand in which of these two states you are now.

We'll review your situation in a free audit
Your own module against fitting the purchased one

How this option differs from the alternative

Purchased module from the market plus modification for yourselfOur approach
What doeswhat the author intended; your task is partially closedexactly what is written in the technical description
Platform updatedepends on the author; the abandoned module keeps the store on the old versionit depends on you: the code is yours, you can fix it at any time
Excessive behaviorfunctions that you don't need but are executed on every requestit is not there - they wrote under one process
Analysis of the failuresilent failure; at best — the author's forumactivity log and clear messages
Moneycheap at the entrance, then a license, fitting and time to bypass other people's restrictionshigher amount at the start, zero further licenses
Free audit

Free analysis of the task for the module

Half of the requests for a custom module are closed with an existing solution or customization - and to be honest, it's better for both before paying. Analysis is needed precisely in order to separate these cases.

What we measure

  1. Is there a ready-made solution?We check whether the task is closed by the standard tools of the platform or by an existing extension. If so, we will say so, even if it means that there is nothing to order from us.
  2. Intervention pointsIn how many places of the platform should the module change something: card, catalog, cart, checkout, admin, data exchange. This is the main component of the estimate.
  3. Conflicts with existing modulesDoes the task not overlap with what is already standing. Two extensions running the same place is the source of months of bugs.
  4. Code state aroundHow many edits have already been made in the core. For reference: in the wholesale store we measured, the site map was generated by a third-party module, which at standard addresses returned either an empty body or a line about its own shutdown - the working map was located at a non-standard address and was kept only by an entry in robots.txt.
  5. Who will accompany itDo you need the ability to hand off a module to another developer? This affects the requirements for documentation and the way of implementation.
  6. Task lifetimeIs it a one-time need or a feature that will live on for years. It is often cheaper to solve one-off problems differently than with a module.

What you get

  • Technical description of the problem in the form in which it can be implemented and verified.
  • The answer is whether there is a ready-made solution and why it is suitable or not suitable.
  • Evaluation of the development with a breakdown by intervention points.
  • Conversation for 30–40 minutes on the document.

Timeline: 2-4 working days

Why is it free

Because the most expensive mistake here is to order a module where the setting was insufficient. A few days of analysis is cheaper than development, which turned out to be unnecessary.

What's next

After analysis - amount and term, contract, account, act. Code and documentation are delivered to you with the works.

Short form: your contact and site URL

Did not find your case?

Describe how it works on your side — we will tell you whether “A custom module for a specific task” fits and what it means in your situation. No brief and no call: one question, one answer.

Contract and paperwork

We work officially

Contract, act and invoice — for every project, not just large ones.

Trusted by6 brands

Trusted by: Kvant Energy, GYPSUN, Naturel Cosmetics, Pancer Protection, LUGI, BeeTech

Terms fixed in writing8 points

  • Contract, act and 30-day warranty

    Every project gets a written contract: scope, deadlines, amount, acceptance procedure. After delivery — act and invoice, then 30 calendar days of warranty.

  • Sole proprietor & bank transfer

    The contractor is a registered sole proprietor. Payment by invoice with closing documents.

  • Rights & access — yours

    Code, design and materials transfer to you after full payment. Domain, hosting, repository and analytics are registered to you.

  • Client portal instead of email chains

    During the project you get access to a portal: contracts, invoices, acts and project status in one place.

  • Sites in nine countries

    Our sites run in nine countries: besides Ukraine — Poland, Germany, Austria, England, Norway, Bulgaria, Moldova and Spain.

  • Verifiable numbers

    Every case in the portfolio comes with a link to a live site and a technical measurement.

  • Audit first, then pricing

    There is no price list on the site intentionally: the scope of the same work differs multiples between clients.

  • We say "no" when unsure

    If the task isn't ours or the deadline is unrealistic — we tell you upfront.

  • Contract, act and 30-day warranty

    Every project gets a written contract: scope, deadlines, amount, acceptance procedure. After delivery — act and invoice, then 30 calendar days of warranty.

  • Sole proprietor & bank transfer

    The contractor is a registered sole proprietor. Payment by invoice with closing documents.

  • Rights & access — yours

    Code, design and materials transfer to you after full payment. Domain, hosting, repository and analytics are registered to you.

  • Client portal instead of email chains

    During the project you get access to a portal: contracts, invoices, acts and project status in one place.

  • Sites in nine countries

    Our sites run in nine countries: besides Ukraine — Poland, Germany, Austria, England, Norway, Bulgaria, Moldova and Spain.

  • Verifiable numbers

    Every case in the portfolio comes with a link to a live site and a technical measurement.

  • Audit first, then pricing

    There is no price list on the site intentionally: the scope of the same work differs multiples between clients.

  • We say "no" when unsure

    If the task isn't ours or the deadline is unrealistic — we tell you upfront.

We sign NDAs on request. After completing the work, we delete our access to your services ourselves.

What affects the price

Why two seemingly identical tasks are priced differently

  • Number of intervention pointsThe main component of the estimate. Add a field to the card — one place. Calculate delivery according to your own formula - card, basket, checkout, admin, printed forms and exchange with the carrier. Labor intensity varies by an order of magnitude.
  • Does the module touch moneyAn extension that changes the price, discount, or order amount requires checking the scenarios: guest and registered, coupon on top of discount, return, partial payment. Most of the time here is spent on testing, not writing code.
  • Exchange with an external systemIf the module goes to someone else's API, everything that is done in case of silence of the other party is added to the work: queue, replays, log, store behavior when there is no response at all. Documentation of the external system is required at the start — without it, the evaluation will be a fiction.
  • Code state aroundThe store, where the kernel has already been adjusted by hand, is more expensive: we first check each point of intervention for what has already been changed there. This is visible in the analysis and enters the estimate as a separate line, and does not appear in the middle of the works.
  • How much to take to the admin officeEvery setting you can change yourself is form, validation, and verification. More expensive at the start, cheaper in operation. Carrying out everything in a row is also a mistake.
  • Platform versionThe OpenCart four rewrote the event system, and the code under 3.x does not move there verbatim. You are planning to update the version - you need to take this into account before development, not after.
Cases

Tasks and results in numbers — all metrics measured by us

wholesale store of underwear, catalog of over 13,000 items

Task
Check the technical condition of a large wholesale catalog - first of all, how the third-party extensions responsible for the sitemap and markup behave.
Solution
Bypassing standard sitemap and robots.txt addresses, measuring response and document weight, parsing structured data and comparing the number of pages.
Result
13,428 pages of products and 161 categories — 13,590 addresses in the site map, of which there is only 1 duplicate. TTFB 289ms, full load 455.1ms: third fastest response among 16 sites measured. Payment methods are listed in structured data with a separate field acceptedPaymentMethod — a rarity for this platform. Defect found by measurement: the standard sitemap address returns 200 with an empty body, the second standard address returns a text string about the generator being disabled, and the working map lies at a non-standard address and is held only by an entry in robots.txt.

a store of automatic irrigation systems with a small technical nomenclature

Task
Collect a catalog in which elbows, couplings and tees differ only in diameter and type of thread: without deep nesting and a filter, the buyer cannot find the desired part.
Solution
The catalog was expanded to 4 nesting levels, so that the fittings were divided by the type of connection and thread; the facet filter module works in categories. Added quick card view, one-click ordering, reviews, callback and messenger widgets.
Result
300 products in 40 categories at 4 nesting levels — the number was confirmed by two independent methods, the discrepancy is 0%. TTFB main 235 ms (median of 5 measurements), full HTML 262 ms; main weight is 143.6 KB uncompressed and 22.5 KB in brotli. There are 6 delivery methods from 2 carriers and 3 payment methods in the checkout. The same measurement showed that there is not a single analytics counter on the site — that is, the effect of any improvement here cannot yet be measured.
What we need from you

We can't start without this — best to prepare in advance

  1. A description of the problem in your own words, with examples of how it should work and what you would consider the correct result.
  2. Access: admin, files, database, test site — or permission to upload it to us.
  3. A list of already installed extensions, including those that you once installed and forgot to disable.
  4. Documentation of external systems with which the module will exchange data and keys to the test circuit.
  5. One person from your side with the right to agree the technical description and accept the job.
If something is missing — let us know, we'll help you gather it or do it as a separate task.
FAQ

Most frequently asked questions — with concrete answers

Maybe the market already has a ready-made module?

Often there is, and we check it as the first step before any money. If the task is closed by an existing extension or a standard setting, we will say so - even if it means that we do not order anything from us. Your own development is justified in three cases: the finished product does not do the right thing, it does too much, or it leads to a dependency on the author that you do not want.

Why does the amount not depend on the task description?

Because "add a field to the card" and "calculate delivery according to your own formula" occupy the same half-tape of the description, and their work is an order of magnitude different. In the first case, the place of intervention is one. In the second - card, basket, checkout, admin, printed forms and exchange with the carrier, and in each of these places you need to check that nothing is broken. During the analysis, we divide the problem into such places, and this distribution becomes the estimate.

Will you edit the platform files?

No, this is a condition from which we do not deviate. The module is implemented by platform events and modifiers. Core tweaks look cheaper during development and get more expensive with each subsequent update, which is why stores sit on unsupported versions for years. If the task cannot be solved without changing the kernel, you will hear about it before the work begins, and not at the time of submission.

What happens when the module breaks?

It should predictably break. Error handling, a clear message instead of a white screen, an action log so you can see what happened. A separate requirement that we set for ourselves: the module must be turned off without consequences for the store. An extension that drops the cart after disabling it is poorly made, no matter how much it costs.

Someone else's site extension is acting weird - is this your problem too?

Yes, and we start with a measure. An example from work: at a lingerie wholesaler, the sitemap was generated by a third-party extension, and at the two default addresses where crawlers and audit tools go first, it returned either an empty body or a line about its own shutdown. The working card was located at a non-standard address and was kept exclusively by an entry in robots.txt. From the outside, the site looked healthy.

I want to use the module to add filters to the catalog — isn't that always for the best?

Not always, and the limit should be mentioned right away. Filters help to get to a position in a large assortment, but they do not increase the demand for a product, and a clear structure of categories works better in a catalog with several hundred items. There is also a technical side: filters generate a combinatorial number of addresses, and if you do not close them with canonicals and robots, you will get thousands of almost identical pages in the index. This is a deterioration, not an improvement, and work with it should be included in the same estimate.

Can the module fix directory search?

Maybe, but it will help only the buyer who already knows the name or article number. For those who are still choosing, categories and filters are needed - these are different paths to the product. And separately: a good search requires neat data in the cards. If the names of the products are filled in badly, no search engine will fix it, and it is more honest to get the names in order first.

How will I see that the module actually works?

From two sides. Technical — a log of the module's actions: you can see what it did, when and with what result. Business - events in analytics, if you have it. Here's a caveat: the counter itself doesn't improve anything, it just gives you an opportunity to see, and blockers, consent mode, and browser cookie restrictions make GA4 a trend indicator, not an accounting truth. In the watering shop that we measured, there was no analytics at all - there you have to set measurements before any finishing touches.

Will the code be mine?

Yes. Worksheets are given to you together with the work, together with the documentation: what it does, how it is configured, where to look in case of problems. A module that can only be supported by its author is a dependency, not a solution, and we don't want to sell that. The repository remains with you, so you can transfer work to another developer at any time.

How long does the work last?

5-30 working days. A simple extension with one point of intervention - about a week with a check. The module that changes the calculation logic and exchanges data with the external system goes to the upper limit, and most of this time is testing scripts, not writing code. We call the deadline after analyzing the problem and fix it together with the amount.

Describe the problem in your own words — even if the wording is still raw.

In response, there is a technical description, breakdown by intervention points, term and amount. If the task closes with a finished extension or setting, you will hear it in the first email.

From measured cases13,428 pages of products and 161 categories

View cases
  • Reply within 2 hours
  • No commitment
  • We work under a contract

There is no price list on the site on purpose: the same work differs several times over between two clients, and a “from” figure explains nothing in that case. First a free audit — we count your pages, duplicates and speed — then we name the sum and the deadline and fix both in the contract.