--- title: "How to Choose a Digital Transformation Partner | Murarum" description: "What to check before hiring a digital transformation partner: seniority, delivery model, proof, ownership and the questions to ask." url: https://murarum.ro/en/insights/how-to-choose-digital-transformation-partner language: en alternate_ro: https://murarum.ro/articole/cum-alegi-partener-transformare-digitala --- 6 min read · Digital transformation # How to choose a digital transformation partner A digital transformation partner is an outside team that diagnoses how a company operates, designs the systems and processes it should run on, and builds them to production. The choice comes down to five checks: who does the work, whether they ship or only recommend, what proof they can show, who owns the result afterwards, and how they behave when the scope is unclear. This guide gives the questions for each check, written for owners and operations leaders of companies with 10 to 250 people. By Mircea Muraru · 26 September 2026 ## Why the choice is harder than it looks Three kinds of vendor answer the same enquiry. A consultancy sells analysis and a roadmap. An agency or dev shop sells capacity to build what you specify. A studio sells both, with the same people doing the diagnosis and the build. Each is right for a different situation, and each has a failure mode: the deck that never becomes a system, the build that faithfully reproduces a broken process, and the small team that cannot carry the scope. The market makes it harder still. In 2025, 5.21% of Romanian enterprises used AI, against 19.95% in the EU, and in 2023 only 15.52% bought cloud services against 38.97% in the EU (Eurostat, isoc\_eb\_ai; European Commission, Romania 2025 Digital Decade Country Report). Demand for transformation work is rising from a low base, which means many vendors are new to it. The checks below separate experience from vocabulary. ## Check 1: who actually does the work The senior person on the sales call is the reason you sign. Ask whether that person will be in the diagnosis workshops, in the design decisions and in the build reviews, and for how many hours a week. Ask for the names and roles of everyone who will touch the project. A vendor that cannot name the team in the proposal has not staffed it. - Who runs the diagnosis, and will the same people design and build? - How many other engagements does the lead run at the same time? - What happens if the lead leaves mid-project? ## Check 2: do they ship to production Recommendations are cheap to produce and expensive to leave unimplemented. Ask what the deliverable of each phase is, and insist that at least one phase ends with something running in your company: a connected system, an automated process, a platform your team uses. If every phase ends with a document, you are buying a consultancy, whatever the website says. - Show me a system you designed and also built. Who runs it now? - In your last three projects, how long from the first workshop to the first thing in production? - What did you refuse to build, and why? The last question is the one most vendors do not expect. A partner with judgment has said no to a client. A vendor that has never refused a scope builds whatever is asked, including the mistake. ## Check 3: proof you can verify Case studies are only proof if they name the client and describe what changed. Ask for two references you can call, in companies of a similar size, and ask those references one question: would you hire them again for the next phase? Be wary of anonymized outcomes ("a logistics company reduced costs 40%") and of any percentage without a named source. Our own proof is on the [work page](https://murarum.ro/en/work). The [ExproSov case study](https://murarum.ro/en/work/exprosov-website), for example, shows a company site designed and built from brief to launch by the same team, which is the delivery model this article argues for. How such a project runs, week by week, is in [our fixed-budget website redesign guide](https://murarum.ro/en/insights/website-redesign-week-by-week). We publish only clients who have cleared their name, and we mark any metric we cannot yet confirm as draft rather than ship it as fact. ## Check 4: who owns the result Transformation projects create systems your company will depend on for years. Before signing, settle four things in writing: who owns the code and the data, where it is hosted and under whose account, what documentation is delivered, and how the hand-off to your team works. A partner that keeps you dependent on them for every change has sold you a subscription, not a system. | Question | Good answer | Warning sign | | -------------------------------- | ---------------------------------------------------------- | -------------------------------------------- | | Who owns the code? | You do, in your own repository, from day one | Vendor-owned, licensed back to you | | Where does it run? | Your cloud account, your domain, your credentials | Vendor's account, migration "possible later" | | What is documented? | Architecture, runbooks, decisions and how to change things | "The code is the documentation" | | How does hand-off work? | Named phase, your team runs it with the vendor watching | No hand-off phase in the plan | | What if we stop after phase one? | You keep everything built so far, working | Nothing usable until the end | ## Check 5: how they behave when scope is unclear Every transformation project starts with an unclear scope, because the diagnosis has not happened yet. Watch how the vendor handles that. A fixed price quoted before any diagnosis means they will either pad it heavily or discover the real scope on your budget. A refusal to give any estimate means they have not done this often enough to know the shape of it. The honest pattern is a short, priced diagnosis phase with a defined deliverable, followed by a scoped proposal for the build. It costs you a few weeks and protects both sides from the two failure modes above. Our [approach](https://murarum.ro/en/approach) is built on that pattern: Diagnose, Design, Build, Scale, each with its own deliverable and its own decision point. ## Consultant, agency or studio: which one you need - You need a consultancy when the decision is strategic and the build will be done by others: a market entry, a merger, a regulatory change. - You need an agency when the design is done and the specification is complete; you are buying hands to build exactly that. - You need a studio when the problem is operational, the design is not done, and you want the people who diagnose it to also build it and hand it over. This is most transformation work in companies of 10 to 250 people. Size the partner to the scope. A large consultancy is built for programmes with hundreds of stakeholders and prices accordingly. A freelancer is built for one skill at a time. A studio sits between, and its limit is scope: ask directly what size of project is too large for them, and expect an honest answer. Our [digital transformation](https://murarum.ro/en/services/digital-transformation) service, for example, is sized for companies of 10 to 250 people and says so on the page. For a closer look at the freelancer, agency and studio options, see [freelancer, agency, SaaS or studio](https://murarum.ro/en/insights/freelancer-agency-saas-or-studio). ## Ten questions to bring to the first call 1. Who will be in the room for diagnosis, design and build, by name? 2. What runs in production at the end of the first phase? 3. Show me one system you designed and built. Who operates it today? 4. Give me two references at companies of my size. 5. What have you refused to build? 6. Who owns the code, the data and the hosting account? 7. What documentation and hand-off do we get? 8. What do we keep if we stop after phase one? 9. How do you price work before the scope is known? 10. What size of project is too big for you? ## Summary - Check the people, not the pitch: the seniors you meet should do the work. - Insist that phases end in running systems, not documents. - Verify proof: named clients, callable references, no anonymous percentages. - Settle ownership, hosting, documentation and hand-off in writing before signing. - Prefer a priced diagnosis over a fixed price for an unknown scope. ## Frequently asked questions ### What is the difference between a digital transformation consultant and an agency? A consultant analyses the business and delivers recommendations and a roadmap; someone else builds. An agency or dev shop builds what you specify; the design and the decision are yours. A studio does both with the same people, from diagnosis to production. For operational problems in companies of 10 to 250 people, the studio model usually fits best. ### What questions should I ask a digital transformation consultancy? Who does the work, by name; what runs in production at the end of each phase; one system they designed and built and who operates it now; two references at companies of your size; what they have refused to build; who owns the code, data and hosting; what hand-off and documentation you get; and how they price before the scope is known. ### Should a digital transformation partner give a fixed price up front? Not before a diagnosis. A fixed price for an unknown scope is either padded or wrong. The sound pattern is a short, priced diagnosis phase with a defined deliverable, followed by a scoped proposal for the build. Fixed prices per phase after that are reasonable. ### How do I check a digital transformation partner's track record? Ask for named case studies that describe what changed, two references you can call at companies of a similar size, and one system they designed and built that is still in use. Treat anonymized results and percentages without a source as marketing, not proof. ### Who should own the code and data after a transformation project? You should, from the first commit: your repository, your cloud account, your domain, your credentials. The partner should deliver documentation and a hand-off phase in which your team operates the system while the partner watches. Anything else creates dependency. [Still have questions? Write to us](https://murarum.ro/en/contact) ## Related - [Digital Transformation](https://murarum.ro/en/services/digital-transformation) - [All case studies](https://murarum.ro/en/work) [A website as solid as the restoration work behind it](https://murarum.ro/en/work/exprosov-website): ExproSov · Architecture and heritage · 2024 [A new teamsunday.com, in five languages](https://murarum.ro/en/work/sunday-website): Sunday · Branded merchandise platform · 2026 ## Bring the ten questions to us. We answer them on the first call, including the one about what is too big for us. [Let’s talk](https://murarum.ro/en/contact) [office@murarum.ro](mailto:office@murarum.ro) ## Contact - Email: office@murarum.ro - Phone: +40 761 339 149 - Let’s talk: https://murarum.ro/en/contact