We work remotely, for clients in any country. Accounts, data, access rights, reports. The system your people sit in every day — automation of the work that decides how much time goes on things that never needed doing by hand.
Andrei sets the architecture, Dumitru writes the backend, Emilian everything the user touches.
On a website a mistake costs a visit. On an internal system it costs a working day, and sometimes data that no longer exists. So the order here is different: first it is decided how this is put together, and only then is it written. Andrei has been a CTO since 2009 at two companies, and the conversation about your system starts with him.
From three months to a first version people can actually work in. After that a system usually grows for years — and that is the normal way it lives, not a sign that something went wrong.
An internal system is almost never built whole and at once: first comes the part you cannot do without, the rest is added as it becomes clear what people actually use. We count hours for the first version from the spec, and after that work month to month.
An internal system lives for years and outlives whoever wrote it. That is exactly the place where one pair of hands becomes a risk.
There are three of us, and two work on the same backend territory: if one drops out, the other picks it up without starting from a blank page. We know who is working on what because we talk constantly.
Accounts and permissions. Everyone has their own workspace: who sees what and who can do what — and what happens when a person leaves or changes role. Permissions are laid into the foundation, not bolted on afterwards.
Data. A model in which it does not sprawl, and a database that withstands your load rather than a demo one. Plus the thing almost everyone forgets: backups and the ability to roll back.
Reports and a dashboard. Not an export to a spreadsheet once a month but numbers you can look at the moment you need them. An export to a spreadsheet too, when it is needed: the accountants work with that.
Connection to what you already have. Accounting and 1C, warehouse, mail, payments, CRM or ERP — integrations here are a neighbouring specialisation inside the same team.
An action history. Who changed what and when. On an internal system that is not a luxury: without a log there is no way to settle an “it did it by itself” argument.
Server and deployment. Andrei runs the infrastructure: where the system lives, how it is updated, and what happens when an update turns out badly.
A ticketing platform for Moldova and Romania — not a website but a system: sales, several cities, organiser portal, box office, venue staff, entry through turnstiles. Public site, buyer app, scanning app. We did not start the project; we have run it for ten years, in active development and support to this day.
A portal for the Romanian confederation of small and medium enterprises across three levels: confederation → employers’ associations → member companies. The difficulty is not in the content but in who sees what: an association sees only its own companies, the federation only the structures under it. The access rule is written once and applied in the database query, so it cannot be sidestepped by a list, a filter or an export. Plus a consulting service and an archive of committee reports.
Waybills that reconcile themselves. The sum of the trips exactly equals the difference in odometer readings, distances come from a routing service rather than a guess, and routes do not repeat month after month. A finalised document is not changed retroactively: an edit creates a new version, every figure has a source and every action leaves an audit trail.
An open point-of-sale solution taken all the way to small shops in Moldova: a fiscal receipt with the right payment type, electronic scales whose product list does not drift from the till’s, goods receipt by import instead of manual entry, price tags from the same delivery note. Extended according to what the cashiers and accountants asked for. Four shops, each with its own copy — we install and maintain them ourselves.
A significant part of our work is covered by agency NDAs. Examples on request.
We do not take on a system nobody will be there to run. If after launch nobody opens it and nobody updates it, that is not a saving but a postponed breakage.
We do not quote a price before the spec. A figure based on a description of an idea is not an estimate — it is a number that will change anyway. We would rather change it before you have counted on it.
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.
The price is counted in hours, and we state the number of hours in advance, based on the technical spec. Without that document we give no figure: a sum guessed from a description of an idea would be just that, a guess.
From three months to a first version people can work in. The exact schedule comes from the finished spec.
A website tells; an application works. On a website a person reads and leaves; in an application they sign in under their own account and do something — place, calculate, keep records, approve. Everything else follows from that: access rights, states, action history, load. And so does the difference in price, which sometimes comes as a surprise.
We do, but it is worth asking first whether you need your own. Off-the-shelf CRMs are cheaper and faster right up to the moment your process stops matching their idea of it. Your own system is justified when the process is your advantage rather than a commonplace. The same applies to a portal or a client area for your customers: there an off-the-shelf solution almost always runs into the fact that your client does not do the same thing as your neighbour’s. We say what we see before the work starts.
Yes, and more often than not that is cheaper than writing it again. It starts not with an estimate but with reading the code — the page about taking over. The initial look is free.
Wherever you need it: on your server, on a rented one, or on your own hardware inside the office if the data must not leave it. Andrei runs the infrastructure — that is his territory, not a task handed to someone outside.
The backend is most often PHP with Laravel or Node.js with NestJS, the database MySQL or MongoDB, all of it in Docker on Linux. The full list of what we work with is at the bottom of the page. If your system 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.
The other one picks up the work: the same backend territory is held by two of us, and both are constantly aware of the other’s tasks.
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. We will rework it until no questions remain, and count the hours from that.
This is the way in. For internal systems the conversation starts with Andrei: architecture first, everything else after.
To write to one of us directly — contacts on the home page.
If the task is a different one: APIs, integrations and payments, 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 platform for ticket sales and event management: from publishing an event and picking a seat on the hall plan to payment, ticket issue, entry control and settlement with the organiser. Six interfaces in one product, two markets with their own tax rules — Moldova and Romania — interface and content in Romanian, Russian and English. In active development and support for many years now.
iticket.md iticket.roEvent catalogue, search, hall plan with seat selection, checkout and a personal account. Different prices by sector, row and individual seat; a temporary hold prevents one seat being sold twice and releases itself if payment does not go through. Three languages each with their own URLs, structured data and sharing images, cookie consent.
Creating and running events, your own team, sales reports. Several companies and contracts per organiser, commission tiers and carried-over advances, commission split across separate accounts, electronic invoices into the fiscal system, configurable rules for cancellations and partial refunds.
Internal operations, financial statistics, accounting reports with export to Excel and PDF. Role-based access rights and a full change log, GDPR flows for deleting and transferring personal data. Interface texts are edited by the client’s team, without developers.
A physical point of sale: issuing and printing a ticket on the spot from templates configurable per event.
Buying a voucher, sending it to a recipient, redeeming it against a ticket order, and scanning.
Search, promoted events, category chips, filters by city, tabs for tickets, vouchers and the account. Payment by card, by QR straight from the banking app, from the account balance, by invoice or on delivery — with a transaction history and its own error handling for each method. Push notifications.
Ticket control at the entrance for venue staff: QR scanning and real-time statistics for the event.
Integrations with external partners, booking widgets for third-party sites, email and SMS campaigns with template preview, a referral programme with payouts, cashback campaigns and A/B tests. Entry through turnstiles belongs here too: the turnstile stands at the venue and speaks its own protocol.
tier 1 — platform
The portal of Romania’s national employers’ structure for small and medium enterprises, organised on three levels: confederation → employers’ associations → member companies. The main task was not showing the content but deciding who has the right to see what: an association’s representative sees only the companies of their own association, the federation only the structures beneath it, the administrator the whole registry — and no list, filter or export may fall outside that rule. On top of the registry sit a consulting service, an archive of working committee reports, and a section of specialist content for confirmed members only. Built as developers within the partner’s team.
servicii.immromania.euA presentation of the confederation, service categories, articles and public documents. Site-wide search with highlighting of matches. Sections become public only after being explicitly published — nothing opens up retroactively. Images are converted on upload to a web format and a single geometry regardless of source, and user-entered content is stripped of stray code before publication.
The full confederation → association → member company hierarchy, maintained directly in the application. A company record with identification details, sector, CAEN codes, region and county. Bulk import of companies from Excel and CSV — to take over existing records. Working committees and economic sectors as cross-cutting structures above the registry. A change history on every record: who changed what and when.
Everyone sees only the structures they belong to: administrator, federation, association or their own company. The access rule is applied in the database query itself rather than by hiding buttons in the interface — so it extends by itself to lists, filters, search and exports, including whatever gets written later. The rights matrix is configurable per user and administered visually. Registration with email confirmation: until confirmed, an account counts as an ordinary anonymous visitor.
Member companies send questions to the federation’s consultants by service category, with documents attached to both the question and the answer. A question is routed to the consultant responsible for that service. Notifications about new questions and about answers received.
An archive of working committee reports with file upload. A clear separation between public documents and those available to members only. Private documents are never left in the open: downloading goes through a controlled route that checks the right on every request. Photo galleries can be restricted too, and a restriction can be lifted at any time.
The interface is entirely in Romanian, with a translation editor inside the application itself. Panel notifications about events that need attention. Users, rights and membership of structures — all from one place.
tier 1 — platform
A web application that compiles a company’s waybills and refuses to issue a document that does not reconcile. The sum of the trips exactly equals the difference in odometer readings, distances come from a routing service for the specific route, and generated routes do not repeat from month to month. Every figure has a source, every action leaves a trace, and a finalised document is not changed retroactively: a correction creates a new version linked to the original. Built as developers within the Blue Twin Bit team.
foi-parcurs.bluetwinbit.comPresentation, a step-by-step guide and common questions. Romanian and English, with sign-in to the application from the same place.
Company details are pulled in by CUI from public registries. After that come vehicles with their consumption norm, drivers and points of interest: one at a time or imported from a file, with the address confirmed on the map before it reaches a route.
Month, vehicle, starting and ending mileage, driver, and the points that may enter the routes. The limits are configurable: days, trips, trips per day, permitted days; empty fields take the company’s default rules. The proposal is checked on screen — daily and monthly totals, the source of every distance, warnings; it can be edited by hand, regenerated, or a constraint can be relaxed.
In strict mode the sum of the trips exactly equals the mileage difference; if no valid combination exists, the application says why and what can be changed, but never moves the limits itself. Distances come from a routing service, for the car profile and the exact direction — the matrix is directional. A pair of points without a distance does not block the month, but is never filled in with invented numbers. The generator avoids clustering, repetition and implausible jumps, and the seed is stored: the same data and the same seed produce exactly the same document.
The series and number are issued atomically and are unique even under simultaneous finalisation; a cancelled number stays used up. A finalised document is immutable, a correction creates a new version linked to the original, and cancellation requires a reason. At generation the details of company, vehicle, driver and points are frozen — an address changed tomorrow does not touch last month. Export to DOCX and PDF from one version of the data, layouts are versioned, and a historical export is reproduced with exactly the layout it was made with.
One account runs several companies, each with its own role: administrator, operator, observer. Colleagues are invited by email, access is revoked at any moment, and one company’s data is not visible from another. Auditing on generation, edits, finalisation, cancellation and exports — with author, date and the values before and after. Vignette, insurance, technical inspection, driving licences and company documents are tracked by expiry, with a warning on screen and by email. Two-factor sign-in is optional and can be required of everyone.
tier 1 — system
An open point-of-sale solution taken all the way to small retail shops in Moldova: compliance with local fiscal requirements, a link to the equipment the shop actually has — fiscal printer, electronic scales, barcode scanner — and trading flows in the form they are actually run here. Each shop has its own copy with its own product list, styling and settings; we install and maintain them ourselves. It was extended according to what the cashiers and accountants asked for, not according to a theoretical feature list. Running in four shops: Grădina trei scări, Connection, Deliart, Dulce – Sănătos.
Large buttons and visible actions — the screen is touched dozens of times an hour. The customer from the previous sale is filled in automatically where the shop works with regulars. The session is lengthened so the password is not asked for again mid-shift. Automatic actions that got in the cashier’s way — printing and the auto-return to the screen — were removed. Long product names wrap onto several lines.
Every closed sale is printed as a fiscal receipt: items, quantities, discounts, tax group. The payment type — cash or card — reaches the device correctly, otherwise the reporting does not reconcile. Mixed payment is separated out: on partial payment by gift card, only the amount actually accepted fiscally goes onto the fiscal receipt, and the rest stays in the shop’s internal records. The operating mode switches between installation, testing and production without code changes.
A separate PLU numbering for weighed goods, issued automatically from a reserved range. The upload file for the scales is exported straight from the application, so the product list in the shop and in the scales do not drift apart. The barcode printed by the scales is recognised at the till: the weight or the amount is taken from the code. A product is marked as weighed right on its own record.
Import of receipts and products from XML, picking up barcodes and categories — a receipt is no longer typed in by hand, item by item. Filtering products by the receipt they came in on. Turning an offer into an “invoice for payment” — the form used when working with companies. A supplier column in the product reports. Gift cards work in payment, including partial payment.
Printing price tags straight from the goods receipt note, with the design reworked. A separate, prominent button for printing prices after goods are received. The retail price is hidden where the shop does not use it. A barcode with the price for the products that need one.
A separate copy per shop: its own database, its own product list, its own styling. Delivery in containers, the security certificate is issued automatically, and updates reach every installation the same way. Secure remote access for intervention and support, without exposing the shop’s network. Equipment setup — printer, scales, scanner. Initial import of the product list and stock from whatever records were already kept. The interface in the staff’s languages, and training for the cashiers at launch.