What we do

Everything that lives in a browser — from the site that makes the first impression to the application your customers log into.

• Presentational websites

  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.

• Web applications

  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.

Selling online, end to end — the storefront customers see, and everything behind it that has to agree with your stock, your couriers and your books.

• Online stores

  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 — because 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.

• Payments and integrations

  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. 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.

Installed software, on whatever your people actually carry around or sit in front of.

• Mobile applications

  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 — privacy declarations, permission rationales, 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.

• Desktop applications

  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 — local processing, hardware, large files — it runs on the machine, and the application stays usable with no connection at all.

The software your company runs on, the systems that have to agree with each other, and the repetitive work nobody should still be doing by hand.

• Company software

  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.

• Automation

  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.

• System integrations

  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. 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.

Our specialty. If your company already runs on Bitrix24, we extend it rather than replace it — new modules, new screens and new automations inside the system your people already know.

• Bitrix modules

  Custom modules for an existing installation — the features the platform did not ship with.

  What that involves

  Built against the platform’s own 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. The result installs, uninstalls and upgrades like anything else in the system, and your administrators manage it from the same place they manage the rest.

• Marketplace applications

  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.