What a project costs, how long it takes, and what you own after

There is no price list, because a price before scope is a guess. First we agree what the thing has to do and what counts as done — that conversation is free and usually one call. Then you get a fixed price for that scope, or a monthly retainer if the work is open-ended. What moves the number: how many systems it has to talk to, whether there is hardware involved, whether data has to be migrated from something that is still running, and how much of the design already exists.

Kickoff is within two weeks of agreeing scope. For delivery, the honest answer is the projects on this site: the bilingual storefront took one month, the multi-warehouse ERP with the fiscal printer took two. Anything touching custom hardware is longer and less predictable, and we say so before you commit rather than after.

A small in-house team — engineering, design, infrastructure and the search and analytics side. Nothing is subcontracted without telling you, and there is no account manager standing between you and the people building the software. The trade-off is honest: we take fewer projects at once, so start dates are real constraints rather than sales talk.

Code, documentation and a runbook. The code in your repository under your account, not ours. Documentation covering the data model and the decisions that are not obvious from reading the source. A runbook for the boring parts: how to deploy it, what to check when it breaks, which numbers mean something is wrong.

CI/CD, monitoring and the runbook are part of delivery, not extras. After that a retainer is optional, and it is a real option rather than a requirement: some clients keep one for changes and monitoring, others take the runbook and run it themselves. Both are fine, and you are not locked into us to keep your own software alive.

We design it. Tokens and components get built once and reused, which is why the pages stay consistent as the project grows instead of drifting. If you already have a designer or a brand system, we build to it — that is usually faster and always cheaper than redoing work you have paid for.

Clients so far are spread across six countries, in Europe and the US. Working hours overlap the European day completely and the American morning partly. Everything runs on written scope, weekly demos you can actually click, and a handoff you own — none of which depends on sitting in the same room.

The floor is around $2,000. That buys a working shop: catalogue, cart, orders, card payments cleared through MAIB, and the fiscal receipt issued when the order completes. What moves the number above it is how much control you want on your side — stock across several locations, roles and permissions, discounts and promotions, integration with an accounting or ERP system — and how much design the shop gets, from a clean standard layout to a bespoke one with custom illustration and motion. This is a floor, not a quote: the same rule as everywhere else on this site, that a price given before scope is a guess.

Yes. What we need before starting: which 1C configuration and version you run, and one way in — either 1C published as a web service (OData or HTTP services), a machine on your network we can reach over VPN, or scheduled file exchange in CommerceML, XML or CSV if the installation is old. Then a decision per field about which system is the source of truth — stock in 1C or in the shop, prices in 1C or in the shop — because that is a business decision before it is a technical one. Finally, a test copy of the database rather than the live one, and someone on your side who can make changes inside 1C, usually your 1C partner. We handle everything outside 1C.

Yes — Swift on iOS and Kotlin on Android when the app leans on the device: camera, background location, Bluetooth, offline data, or performance a wrapper will not give you. When the app is mostly screens and data, React Native or Flutter ships to both stores from one codebase and halves the cost of every later change. Sometimes the honest answer is an installable web app instead: no store review, no thirty per cent, same reach. We say which of the three your case is before you pay for any of them, and the app is published under your developer account, not ours.

Usually yes, and it is a large part of what we do. In order of preference: a direct database connection if we can get read access, scheduled file exchange if the system can export, and — when there is genuinely no other way in — a script that drives the system's own interface the way a person would. That last one is a last resort, not a first idea: it breaks when the interface changes, so we say so before you commit to it. Regional systems, older ERPs and in-house databases are the normal case here, not the exception.

Three things, and only one of them is code. A contract with the bank for the payment gateway — MAIB, MICB or another — which you sign, not us, and which takes the longest. A way to issue the fiscal receipt, either through a fiscal service or a registered device, because a card payment without a receipt is a problem you discover after launch. And the site itself, on HTTPS, with the order flow built so that the payment, the order record and the receipt cannot drift apart. We do the third and walk you through the first two; we have shipped this exact chain before.