What we do

The site people judge you by. Fast, multilingual, and editable without filing a ticket.

What that involves

Speed is a decision made at the start, not a pass at the end: static pages where the page allows it, images sized and encoded per breakpoint, fonts served from your own domain rather than someone else’s. Both languages are built into the routing instead of bolted on afterwards, and the content model is shaped so an editor can change a heading without opening a template.

Portals, dashboards and tools that do real work in the browser, with accounts, permissions and data behind them.

What that involves

Permissions get modelled before the first screen is drawn, because fitting roles into a finished application means reopening every query that reads data. Validation lives on the server as well as in the form, every list has its empty and error state designed rather than discovered in production, and the data model is documented well enough that the next developer can read it without us in the room.

Catalogue, cart and checkout that hold up under a real product range: multilingual, multi-currency, and fast on a phone.

What that involves

The catalogue is structured around your actual range first: variants, attributes, and the rules that decide what can be bought together. That structure is what search, filtering and stock all read from later. Checkout is measured on a mid-range phone over a slow connection, which is where carts are abandoned, and tax, currency and delivery are written as rules rather than set per product by hand.

Card and local payment providers, couriers, and the sync back to your ERP, so stock and orders agree in both directions.

What that involves

Every call out to a payment provider, courier or ERP is written so it can be repeated safely, because connections drop halfway through and a retry must never charge a card twice or duplicate an order. Cash on delivery and IPS QR are built as first-class paths through checkout rather than something added beside the card form, and courier labels and tracking come back into the order instead of living in a separate tab. Webhooks are queued and replayable, anything that fails surfaces somewhere a person will actually see it, and stock and order state are reconciled in both directions rather than assumed to have arrived.

Android and iOS. Through store review, onto real phones, and maintained after the launch.

What that involves

Built for the network phones actually have: state that survives losing signal mid-action, and requests that resume instead of starting over. Store review requirements, from privacy declarations to permission rationales and data disclosures, are handled as part of the build, so review is a step rather than a rewrite. Releases go out through a pipeline that produces the same binary every time, crash reporting is wired in before launch, and each new OS version is tested against.

Windows, macOS and Linux, for the work that needs the machine rather than the network.

What that involves

Signed installers for each platform, an update channel that does not ask anyone to go hunting for a download, and file handling that puts data where each operating system expects to find it. Where the work needs the machine, whether that is local processing, hardware or large files, it runs on the machine, and the application stays usable with no connection at all.

Internal systems shaped around how your company actually works, rather than the other way around.

What that involves

We sit with the people who do the work before deciding what the screens are, because a system that argues with the process gets worked around within a month of going live. Existing data comes across from the spreadsheets and older systems it lives in now, roles reflect who is actually allowed to do what, and the reports leadership needs are part of the build rather than a request that comes later.

Software that does the repeating work: the intake, the transfers, the reports nobody should still be assembling by hand.

What that involves

The mapping comes first and it gets written down: every step, every exception, and what happens today when something goes wrong. That analysis comes with the work, and it is usually where the real savings turn up. Automation that only handles the clean path creates more work than it removes, so the exceptions get a route of their own, usually to a person, with the case queued and the context attached. Every run is logged, and anything that fails is visible rather than silent.

Getting software that was never meant to talk to agree anyway: ERP, CRM, accounting, and whatever else is already in the building.

What that involves

Each field gets one system that owns it, agreed before any code is written, because two systems each certain they are right is the failure that takes weeks to unpick. Where a system has to report to the state, with invoices to SEF and dispatch notes as that requirement comes into force, the published format and the deadlines in the rules are part of the specification, and a rejected document comes back as a task with the reason attached. Mappings are documented, a transfer can be restarted from any point rather than only from the beginning, and mismatches are reported with enough detail to correct the record instead of being dropped quietly.

The system set up around how you actually sell, with pipelines, fields, permissions and automation to match, so it gets used rather than worked around.

What that involves

A CRM stops being used when it asks for data nobody has yet at that point in the sale, so the pipeline is drawn from how deals actually move before a single field is created. Stages carry entry conditions, automation fires on a stage change rather than on someone remembering, and permissions match who is genuinely allowed to see a deal. Rollout is done with the people who will be in it daily, on their own records and their own numbers, and the reports management asks for are built during the project rather than requested after it.

Moving in from another CRM, from spreadsheets, or between cloud and self-hosted, with the history intact, not just the open deals.

What that involves

The migration is run twice: once onto a test portal, where counts are checked against the source and the people who own the data confirm their own records, and once for real, with a date after which the old system is read-only. Contacts, companies, deals and their history come across together, because a deal with the emails and calls stripped off it is a record nobody trusts. Duplicates are resolved by a rule agreed in advance rather than by whoever happens to be running the import, and anything that genuinely cannot be carried across is written down before the cutover instead of discovered after it.

Connecting the portal to the rest of the building over its REST API: the webshop, the ERP, telephony, and the e-invoicing the tax office expects.

What that involves

Integrations are built as applications against the REST API, holding only the OAuth scopes the job actually needs, so nothing rests on a portal setting somebody can change by accident. Events arrive over webhooks, are queued, and can be replayed, because a portal that was briefly unreachable must not cost you a day of orders. Local obligations are part of the integration rather than a separate project: invoices go to SEF in the format it accepts, and dispatch notes take the same route as that requirement comes into force. Anything that fails lands somewhere a person will see it, with the record attached.

Modules for a self-hosted installation: entities, admin screens and reports the platform did not ship with.

What that involves

Built on the platform’s own D7 module API so that an update does not undo the work: nothing is patched into the core, and nothing depends on a file Bitrix will overwrite on its next release. A module brings its own tables, its own admin screens and its own CRM entities, so the work shows up where your people already look rather than in a tool beside the one they use. It installs, uninstalls and upgrades like anything else in the system, and your administrators manage it from the same place they manage the rest.

Applications built to Bitrix24 Marketplace standards, through review and out to every client on the platform.

What that involves

Written to the Marketplace’s published requirements from the first commit: the OAuth scopes the application actually needs, a clean install and uninstall, and data handling documented the way review asks for it. It is built to serve many portals at once rather than one, localised for the markets it is listed in, and versioned so an update reaches existing clients without breaking the ones already running it.

Someone to call after launch: changes as the business changes, and training that leaves your own team running it.

What that involves

Training goes to the people who do the work, on the portal they will actually be using, and it is recorded, so somebody hired next year gets the same version of it. Every change is made on a test portal first, because an edit to one automation rule on a live portal reaches every open deal at once. What we change is written into the same documentation your administrators already hold, so the system stays something your own people can run. What we keep is a copy of what you keep.