Our own product: you connect it to your company's data and ask questions in plain language. It is built and running. Almost nobody uses it yet. That second sentence is most of the job.
Metricor Technologies Global SRL is a software company in Bucharest, founded in 2026, with three partners. We build custom software for clients — and one product of our own, which is what this document is about.
The team is small. There is no management layer between you and a decision: if you propose something good, it gets built.
Most companies sit on data they cannot ask questions of. The numbers are in a database, and getting an answer out means finding someone who writes SQL and waiting for them. Metricor removes that step: you connect your databases, and then anyone in the company — sales, operations, support, the founder — asks in plain language and gets an answer back.
Every correction makes the next answer better. The definitions a company agrees on — what “revenue” means, what counts as an “active customer” — are stored, versioned and editable, so the product gets more useful the longer it is used.
Two things make it different from a chatbot pointed at a database. First, it shows its work: every answer carries the reasoning behind it and links back to the rows it came from, so you can check it rather than trust it. Second, it refuses to guess: if you ask about “active customers” and nobody has defined what that means, it asks you instead of inventing an answer. The rule the team works to is blunt — slower answers are fine, wrong answers are not.
It also watches the numbers you tell it to watch and raises the things it noticed on its own — a metric that moved, a segment that swung — without being asked.
It is live at metricor.cloud, running in production, with sign-up and paid plans already wired in: three plans plus add-ons for extra seats, datasources, monitors and automations.
On the client project there is a client telling us what they need. Here there is nobody. Somebody has to decide what gets built, and be right often enough.
This is the honest part, and we would rather you hear it from us: Metricor works, it is in production, and it has no paying customers yet. The billing is built; the revenue is not there. So the question in front of this product is not “which feature next” but “who is this for, and what would make them pay”.
You would not answer that alone — it is a decision for the three of us together. But we want someone whose daily job is to keep asking it, and who brings evidence instead of opinions.
Before anything else, you use it. Connect real data, ask real questions, and write down every time the answer is wrong, slow, confusing or almost-right. Nobody on the team can do this properly any more — we know what it is supposed to do, so we stop seeing what it actually does. You will only have that outside view once, so we want it recorded while you have it.
Same as on the client work: which screen, which button, who clicks it, what happens next, what happens when it goes wrong. On a product this matters more, not less — there is no client to correct us halfway through.
The hardest kind of testing here is not “does the button work”. It is “is this answer right”. That means reading the reasoning the product shows you, checking it against the data, and being able to say precisely where it went wrong. We already run a set of test questions with known answers; keeping that set honest and growing would be yours.
Watching real people meet it for the first time and noting where they stop. Which industry gets it fastest, which question they ask first, where the trial goes quiet. This is the evidence that answers the question in the section above.
We keep a written list of everything queued and everything in flight. You would take it over: decide the order, argue for what should be dropped, and say out loud when something we are proud of is not earning its place.
You get an account and real data to point it at. You ask it a hundred questions and keep a log of everything that went wrong. At the end you tell us what it is actually like to meet this product cold — while you still remember.
Your log becomes requirements. You take over the queued list and put it in an order you can defend. You test and accept what the team ships, including judging whether the answers are right.
You sit in front of people who have never seen it and watch what happens. You come back with a view on who this is for and what it would take to get the first paying customer — and you argue for it.
You would work on two things: an ERP built for a concrete producer, and this. They ask different things of you.
On the ERP there is a client with an opinion, real deadlines and people whose day gets worse when something breaks. The work is understanding what they need and getting it specified exactly.
On Metricor nobody is waiting. There is no deadline except the one we set, and no one to tell us we got it wrong — until we try to sell it. The work is deciding what matters, and being honest when we have decided badly.
The first job teaches you the second. That is a large part of why we want the same person on both.