domnmoraru.md
A Moldovan online store for craft vinegars and herbal teas: catalogue, cart, checkout, payment and delivery, bilingual RU/RO. Ongoing support.
WooCommerce on a custom theme · bilingual RU/RO · maintained after launch
A store is
not a storefrontEcommerce development from scratch
We work remotely, for clients in any country. Everyone can see the catalogue — the work starts behind the “pay” button: payments, delivery, stock, accounting. Here the storefront and what stands behind it are built by one team.
02 — how it works
A custom online store: there is room to grow
We build the store end to end and write it for you, so it has no ceiling set by somebody else: it keeps growing and does not run into technical barriers.
A new payment method appears — we connect it. A second market opens with its own currency and its own delivery — we add it. An exchange is needed with an accounting system nobody thought about at the start — we build it.
None of those steps runs into “that is not possible”. They run into hours — and you see the hours in advance.
Two of us run a store: Emilian is responsible for the storefront — catalogue, product page, checkout, speed on a phone; Dumitru for what stands behind it — payments, delivery, stock, exchange with the accounting system. That is one team and one invoice, not a markup contractor and a backend contractor you have to keep introducing to each other.
how long building a store takes
A store with one payment method and one delivery option — from six weeks. With several currencies, warehouse exchange and accounting — from twelve.
03 — scope of work
What the work on a store includes
Catalogue and product page. Filters, variants, availability — the things that make a buyer either find the product or leave. Plus a search that works across your range rather than on the full title.
Cart and checkout. Steps, fields, delivery, input errors — everything the buyer goes through between “I want this” and “paid”. This is where most orders are lost, so this is where most of the work is.
Payment. Cards and crypto payments included — we have built payments in BTC, ETH, ERC-20, BCH and LTC. What happens when a payment fails, goes through twice or hangs is written separately.
Integrations behind the order. Delivery, warehouse, the accounting system — 1C or another — notifications: everything that has to learn about an order once it has been placed. More about that part on the APIs, integrations and payments page.
An admin panel your people actually work in. Products, stock, orders, statuses — arranged so that daily actions take two clicks rather than eight.
The code is yours. Repository and access from the very start, not on completion. Domain and hosting are registered in your name.
04 — evidence
Online stores we have built
Premiercom
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.
built as part of the Rinnovation team
A significant part of our work is covered by agency NDAs. Examples on request.
05 — process
How an online store is built
- 01You come with a technical spec.What you sell, how delivery is calculated, what people pay with, what should happen to the order next. That part is yours: without it there is nothing to count.
- 02We analyse it.We turn it into a document that leaves no questions and no double readings: what exactly we are building, and what we are not. For a store that means first of all the order states: what happens to an order after payment, after cancellation and after a refund.
- 03An estimate in hours — from the finished spec.The numbers are counted from a document you have read and approved. Counting hours from a description of an idea is guesswork you pay for. In a store what counts is not the number of products but the number of payment methods, delivery options and exchanges with other systems.
- 04You see something working early.Not a screenshot but a store you can walk through to the payment. Changing your mind at this stage is cheap.
- 05You see where the time goes.Tracked in Toggl, the report open to you: once a month — hours by task, what is done, what comes next. You are billed for hours worked, not in advance.
- 06Launch — then support or handover.The store can stay with us on monthly support, or move to you or your team. The repository and the access are yours either way.
06 — plainly
What we do not do in stores
We do not price a store by the number of pages. The price is set not by the storefront but by what stands behind it: payment methods, delivery, stock, order states.
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.
07 — common questions
Common questions about building online stores
How much does a store cost?
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.
How long does building a store take?
With one payment method and one delivery option — from six weeks. With several currencies, warehouse exchange and accounting — from twelve. The exact schedule comes from the finished spec.
Do you build stores on WooCommerce?
Yes, and it is a common choice when a store needs a familiar admin panel and a standard set of features. The theme, though, we write ourselves rather than buy. When a store outgrows what WooCommerce can do without rework, it is more honest to write it separately — and we say so before the work starts, not halfway through.
Which payment methods can a store have?
Cards almost always, cryptocurrencies when that is your case. The exact set of providers depends on the country the store operates in. More about payments as such on the APIs, integrations and payments page.
How many products can the catalogue hold?
As many as the database and search are designed for at the spec stage. A catalogue of a hundred items and one of a hundred thousand need different database and search decisions, and they are made before launch, not after, when everything has already slowed down. In a B2B store there are also per-buyer prices and terms on top, and that too is decided in the database, not in the storefront.
Do you build marketplaces with several sellers?
We have. But a multi-vendor store cannot be counted like an ordinary one: a seller is not a row in a catalogue but a separate role with their own range, their own stock, their own reporting and their own money. On top of an ordinary store come a second admin panel — the one the seller sits in, not you — and the rules by which the order and the payment are split between you. That is noticeably more work, and it is worked out at the spec stage rather than after.
Can products be loaded from a supplier automatically?
Yes, if the supplier provides an export in some form — a file or an API. This is an ordinary integration: agree the format, parse it, decide what to do with products that have disappeared from the export. It is estimated separately from the store itself.
Can a store be migrated from an existing platform?
Yes, if the platform is on the list at the bottom of the page: the move starts with reading the code, as on the page about taking over. If the platform is not one of ours, it is more honest to say straight away that we are not the right people.
Who connects delivery and the warehouse?
We do. Delivery, warehouse and accounting are integrations, that is the same work as payments, and the same person does it.
Who owns the code?
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.
Will you sign an NDA?
Yes. A significant part of our current work is already under one.
What time zone and languages do you work in?
We work remotely with clients anywhere, time zone EET. We speak and write Romanian, Russian, English and Bulgarian.
08 — next
Tell us what you sell
Come with a technical spec. We will rework it until no questions remain, and count the hours from that.
one address, all three of us
This is the way in. Stores are answered by two of us: Emilian for the storefront, Dumitru for what stands behind it.
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, 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
Premiercom
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.
storefront
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.
synchronisation with the ERP
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.
contract prices
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.
the order, there and back
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.
B2B account area
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.