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. The ExproSov case study, 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. 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 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 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.
Ten questions to bring to the first call
- Who will be in the room for diagnosis, design and build, by name?
- What runs in production at the end of the first phase?
- Show me one system you designed and built. Who operates it today?
- Give me two references at companies of my size.
- What have you refused to build?
- Who owns the code, the data and the hosting account?
- What documentation and hand-off do we get?
- What do we keep if we stop after phase one?
- How do you price work before the scope is known?
- 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.
