We work remotely, for clients in any country. We connect things that were never meant to talk to each other: someone else’s API, a legacy exchange, a payment provider, your accounting system. On both sides of the bridge stands something that was not written for you.
An integration is built not where it is convenient but where it is possible: someone else’s system cannot be rewritten, and everything it does wrong you will have to absorb yourself.
Hence the difference in estimates. “Connect payments” sounds like a single line item and turns out to be a body of work — because the point is not the connecting. The point is what happens when the response never came, came twice, or came wrong. Those cases are the integration; the rest is calling a method.
This territory belongs to Dumitru: backend, APIs, real-time exchange, payments — fourteen years, all of them on this side of the work. Architecture decisions and everything to do with servers belong to Andrei. Two of us work on the same backend territory, so an integration never stays the knowledge of one person.
One integration against a documented API — two to six weeks. Without documentation, or with hardware on the other side, longer — and how much longer is only visible once we have looked at it.
The schedule here depends not on us but on the other side: whether there is documentation, whether there is a test environment, and how quickly the people who keep that system answer. So we give a range after we have looked at the other side — not after we have read your spec.
An API for your product. One that will later be used by more than your own hands: partners, your mobile app, your next contractor. With documentation you can work from without asking us.
Integrations with third-party systems. Exchange with 1C and other accounting systems, warehouse, delivery, CRM — everything that has been running at your place for years and is not about to change.
Payments and acquiring. Card acquiring and cryptocurrency payments: we have built payments in BTC, ETH, ERC-20, BCH and LTC. Together with what happens on a decline, a double charge and a refund.
Real-time exchange. When data has to appear at once rather than on a refresh button: websockets, queues, webhooks.
Retries and queues. The other system is down for half an hour — orders are not lost; they wait and go through when it comes back.
An exchange log. What went out and when, what came back. Without it, a dispute with the other side turns into one word against another.
A ticketing platform for Moldova and Romania that we have been running for ten years. A ticket bought in the app has to open a turnstile at the entrance — and the turnstile stands at the venue, speaks its own protocol and cannot be rewritten. That is exactly the side you do not get to change.
SaaS for self-service car wash chains in Romania. The driver finds a wash on the map, sees free bays in real time, tops up an account and starts a bay from the phone — no tokens. The controller inside the machine was designed by the same team, so payment and the physical start are one flow. For chain owners — a multi-tenant portal with revenue and servicing.
Payments and integrations are the part of the work that is hardest to show: it is not visible in a screenshot, and a significant part of our work is covered by agency NDAs. We have built crypto payments; we cannot yet name the projects where. Examples on request.
We do not promise that an integration is done forever. A third-party API is changed without our consent and may be changed without warning; the question is not whether that happens but who is around when it does.
We do not quote a price before the spec and before the other side’s documentation. Especially here: half the work sits inside someone else’s system, and estimating it blind means guessing at your expense.
Buffer time goes into the estimate but not into the invoice: you pay for hours worked. If the work takes less, you pay less. More on how hours are counted — on the home page.
A technical spec from your side and documentation from the other side — better still, access to its test environment. An estimate without the second is an estimate of half the work.
Two to six weeks if the other side has documentation. If it does not, or if there is hardware on the other side, longer — and how much longer is only visible after we have looked: the schedule here depends on someone else’s system no less than on us.
We take it on, but it is a different body of work: we will have to work it out from what the system actually replies. We say so before the estimate, not after.
Card acquiring and cryptocurrencies: BTC, ETH, ERC-20, BCH and LTC, from our own experience. Which providers are available to you depends on the task and on the country where everything runs: what is ordinary in one country may not be available at all in another.
Yes — exchange with 1C is the most common integration after payments, and with other accounting systems it works the same way. The question is always the same: what exactly that system can send and receive. If it has an API or a scheduled export, we work with those; if there is nothing but a file export, the exchange is built around the file — that also works, it is simply more fragile.
The breakage shows up at once and in the log, not a week later through missing orders: the exchange is written on the assumption that the other side will sooner or later change its API without warning. If we stay on support, we fix it; if we have handed over, your team sees the same thing in the same place.
Most often PHP with Laravel or Node.js with NestJS, real-time exchange through websockets and queues, all of it in Docker on Linux. The full list of what we work with is at the bottom of the page. If your backend rests on a technology that is not on that list, it is more honest to say straight away that we are not the right people.
You do. We work month to month and invoice for work already done, so repository access can be handed over at the start rather than at the end — there is no reason for us to hold the code until the final payment.
Yes. A significant part of our current work is already under one.
We work remotely with clients anywhere, time zone EET. We speak and write Romanian, Russian, English and Bulgarian.
Come with a technical spec and with whatever is known about the other side. We will rework it until no questions remain, and count the hours from that.
This is the way in. APIs, integrations and payments are answered by Dumitru.
To write to one of us directly — contacts on the home page.
If the task is a different one: a web app or internal system, an iOS and Android app, an online store, a website or landing page, taking over an existing project, making an existing site mobile-friendly.
Want to see who we are first — the home page: the three of us, what each one does, how we count hours and what we have already built.
tier 1 — platform
A SaaS platform for self-service car wash chains in Romania. The driver finds the nearest wash on the map, sees in real time which bays are free, tops up an account in the app and starts a bay straight from the phone — no tokens, no cash. The chain is closed end to end: the electronic controller inside the machine was designed by the same team, so payment in the app and the physical start of the bay are one and the same flow. Chain owners get a multi-tenant portal: equipment, revenue, servicing, withdrawals. Built as developers within the Blue Twin Bit team.
mrduck.com dashboard.mrduck.comA map of every wash with bay status and automatic location detection. Search with history and filters: distance, county and locality, rating, service types, free bays, price. A location page with services, opening hours, tariffs and bays in real time. Starting a bay from the app or by scanning a QR code on the equipment. Favourites, wash and top-up history, reviews with ratings, push. iOS and Android.
A wallet with credits: ready-made packages or your own amount. Card payment with 3D Secure, billing details for individuals and companies with saved addresses, full transaction history and credit usage. Payment confirmation arrives as a server-to-server notification — regardless of whether the app is still open.
The module inside the wash machine was designed by the team rather than taken from a supplier: from the board that connects to the wash equipment to the protocol for talking to the platform. The start command arrives immediately after payment is confirmed and is passed to the machine exactly like a physically inserted token. The link is two-way: the equipment reports its state and events, and the platform stitches them to the wash session. Bay states — free, busy, servicing, faulty — are visible to both the customer and the partner; parameters are configured remotely, without a site visit. Tokens and coins still work as before; the app is an additional channel.
Multi-tenant: a company → wash → equipment hierarchy with full data isolation between partners. A dashboard with usage, equipment state and revenue. Servicing — scheduled, on fault and emergency — with assignment to people and automatic opening and closing of scheduled work. Financial accounting per company with the balance updated on every transaction and withdrawal requests.
Companies, washes, equipment and equipment types. A full geographic directory — county, locality, village — for search and filters. Users, reviews, support tickets. Content pages (FAQ, about the service, support) are edited here and shown directly in the mobile app. Push notification campaigns.
A presentation page with links to the stores and to the partner portal, tariffs and legal pages. Interface and content in Romanian and English, acceptance of terms recorded by version, notification settings per user, account and data deletion flows per GDPR and store requirements.