We work remotely, for clients in any country. We read the code, tell you what state it is in, and only then name the hours. Not the other way round.
Messages are read, there are no replies. The schedule keeps moving and the access stayed with them.
The work is the same, the invoice is not, and there is nowhere to go: only they know how the project is put together.
No documentation, no author. Any change starts with excavation and ends at an unknown date. This is exactly where a code audit is needed — before promising anything about schedules.
It holds, and everyone pretends that was the plan. Legacy that has not been updated for years — until the first task that cannot be postponed.
The project is alive, the task is clear, there is nobody to do it. Starting over because of one feature is expensive.
It may well be. Or the person who said it may simply not want to read somebody else’s code.
We do not name a price until we have read the code. That is the only honest order, and the most inconvenient one for us.
Anyone who names a sum and a schedule from a description of the task is naming them at random. On your own project random is wrong by percentages; on somebody else’s, by multiples — and one side pays the difference. So first the reading, and the numbers after it.
What state the code is in: what works, what is held together with tape, and what is already dead and merely lying in the repository.
What can be fixed, what deserves refactoring, and what is cheaper to rewrite. Those are different answers for different parts of one project, and “rewrite everything” is almost never among them.
Where the risks are: what has not been updated for years, where there are no backups, what will break first.
What has to be done urgently and what can wait. Urgent and important are different lists, and confusing them is expensive.
A quick code audit — free. A few hours to understand what we are dealing with; you do not pay for them.
A detailed review is paid: by the hour and on the timer, like all the rest of the work. But you will not have to order it blind — we tell you how long it will take after the free look.
A ticketing platform for Moldova and Romania: public site, organiser portal, box office, buyer app, scanning app for staff, entry through turnstiles. We did not start the project — the codebase arrived already written. We have run it for ten years, in active development and support to this day.
A B2B store for a finishing materials distributor, fused with its ERP. Every partner has their own contract prices, discount group, payment terms and manager — all of that already lived in the ERP, and the store was not to become a second source of truth. A partner signs in and sees their own price, the order goes back into the ERP as a document, delivery status is read from there too. The same storefront also serves private buyers — with card payment and instalments.
A significant part of our work is covered by agency NDAs. Examples on request.
We do not propose rewriting everything from scratch by default. That is the most expensive answer and almost never the most necessary one. Sometimes it is the right one — but then it is a conclusion drawn from reading the code, not an opening line.
We do not name a price before reading the code. You have already heard the quick “yes, we will do it, cheaply” once — and that is most likely why you are here.
We do not take things on quietly. If the reading shows that repairing costs more than rewriting, you will hear that plainly — and then we will propose rewriting.
Andrei has been a CTO since 2009, at two companies. Reading somebody else’s project starts with him.
Somebody else’s code is exactly the place where one pair of hands runs into an unfamiliar stack. Two of us work on the same backend territory, two on the same mobile one.
There can be a buffer in the estimate, but only hours worked reach the invoice. If the work took less, you pay less. More on the home page.
Access to the repository and to the server. Nothing else at this stage: working out how it is all put together is our job, not yours.
For a website that may be enough: what sits on the hosting most often is the source. We will look at what is there and tell you exactly.
A quick look — a few hours, and it is free. How long a full review will take is visible after that: the volume of somebody else’s code cannot be judged from the outside, and naming a schedule blind is exactly the guesswork the client pays for.
That alone is not a reason to rewrite it: it is the normal state of a project that stood a year without a developer. Upgrading is estimated as separate work with its own schedule: first we tell you how far behind everything is and what that risks, and you decide whether to upgrade now or run as it is for the time being.
If it copes — yes, there is no reason to change it for the sake of changing it. If the project’s problems start precisely there, we will say so while reading the code. Migration is separate work too, and hosting is better registered in your name than in ours.
Only if it matches ours — the list is at the bottom of the page. Working out somebody else’s code in a technology we do not do means learning at your expense. 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.
There is no need to prepare a technical spec. It is enough to write what the project is and why it was left without a developer — we will ask the rest ourselves.
This is the way in. Taking over always starts with Andrei — he is the one who reads the code.
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, APIs, integrations and payments, an iOS and Android app, an online store, a website or landing page, 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
The distributor sells through one and the same store in two modes: to partner companies and to private buyers. The difficult part was the B2B side — every partner has their own contract prices, their own discount group, their own payment terms and an assigned manager, and all of that already lives in the company’s ERP. The store was not allowed to become a second source of truth. So the work was not about opening a store but about building the layer that ties the store to the ERP: the price a partner sees after signing in is their price from the ERP, and the order goes back into the ERP as a document, without retyping. Built as developers within the Rinnovation team.
One store for two kinds of buyer: customer categories with different prices, a different order flow and different payment methods. Private customers get shelf prices, card payment and instalment purchase through financing partners, all in the same cart. A notification when an out-of-stock item is back.
Partners arrive from the ERP, and store accounts are created and updated by themselves. The product directory is synchronised: categories, products, images and the mapping of ERP attributes onto store fields. Stock levels are updated so a partner orders against real availability rather than a static list. Discount groups, payment terms and managers are pulled through and tied to the partner. Synchronisations run on a schedule, with a log and separate diagnostic tools for when the mapping does not line up; there is data reconciliation and clean-up of records left without a pair.
Three levels of price from the ERP: the general offer, what was agreed personally with the partner, and current promotions. After signing in, a company sees only its own prices, with the right priority between the general price, its own and a promotion. Offers are processed in batches — there are many partner-product combinations. Group discounts are applied in the store exactly as in the ERP.
An order from the store is exported automatically into the ERP as a document — with the partner, products, prices and terms. The order status is read back from the ERP and shown in the account area, so the partner sees the real stage of delivery. The accompanying documents are available in the same place. The export respects the customer category: a retail order and a contract order enter the system under different terms.
Contract prices are visible only after signing in, and instead of immediate payment there are terms, ordering against an invoice, and an assigned manager. A company is verified automatically by its fiscal code against the public VAT registry.
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.