Who Should I Hire for Digital Transformation — An Agency or a Developer?
Who to hire for digital transformation decides a project’s fate more than the choice of software. A project that starts with the wrong party won’t run even with the right tool. 🔎
Short answer: first someone to write the process, then someone to build it. A developer doesn’t design your process — they build what you ask for. A system bought before the request is clear goes unused.
Below: what each party actually does, the selection criteria, the red flags and the contract clauses. 🎯
Who does what?
Answering who to hire for digital transformation starts by separating the roles.
What if I want it all from one hand?
Then choose a consultant who doesn’t sell software and have them manage the build. That’s our model: we don’t sell products; we choose the right tool with you and manage the setup — scope on the consulting page.
What are the selection criteria?
Three filters eliminate most candidates.
What are the red flags?
Some signals end the conversation.
Can it be done in-house?
Honest answer: partly.
What belongs in the contract?
Three clauses protect you.
The three protective clauses
One: data, account and code ownership with the business, with export always possible. Two: a delivery list — which processes get written, which setup gets done, is training included. Three: measurement — a baseline table and an end-of-period comparison. With all three written, the work runs transparently; quote-reading rules sit in the quote article. 📜
📝 Field Notes
We’re wary of parties that present a product in the first meeting — and the rule applies in our own kitchen too. In our first meeting there’s no screen; there are questions. Who starts the job, where does it jam, what was the last error. Recommending a product without knowing the process is prescribing without an examination. ❓
📖 Quick Glossary
Process design: writing and simplifying the steps of a job. Setup: adapting the chosen tool to the business. Internal owner: the person running the project inside the business. Data ownership: records belonging to the business and being exportable.
⚡ Quick Summary
First the process writer, then the builder. 🔎 Consultant solves WHAT, developer solves HOW. A party selling a product recommends a process that suits it. A candidate who opens with a product demo is out. Every project needs an internal owner.
🎯 Next Step
Put us through the same filter: our first meeting is about process, not product — the first review is free: the quote page. Scope on the consulting page. ✅
Frequently Asked Questions
Sık Sorulan Sorular
A consultant defines what will be done: writes the process, simplifies it, produces the requirement list, manages product selection. A developer solves how it gets built. These are different professions; expecting one to do the other is the source of disappointment. 🧭
You can, but it carries a tension: a party selling its own product tends to recommend a process that suits that product. That isn’t bad faith, it’s natural bias. Which is why process design and build sitting with different parties is healthier. ⚖️
A party that starts explaining a product in the first meeting doesn’t know how to write processes. The right party asks you questions: who starts the job, how many people touch it, where do errors appear. The more concrete the questions, the sounder the diagnosis. ❓
Work that doesn’t measure the starting position answers “did it help?” with a feeling. Hours saved, errors reduced and collection speed must be measured up front — the method sits in the return article. 📊
Sector memorisation isn’t required, but willingness to learn is. A process written without visiting the floor or talking to staff stays on paper. A good consultant spends the first week listening. 👂
“Our software solves everything”, “no need to write processes, we’ll set it up and you’ll see”, “we’ll hold your data”. The third is especially dangerous: data and account ownership must sit with the business. Most unused-software stories start with these sentences — the unused-software article. 🚩
Your team can write the processes; it’s discipline rather than technical work. Where they struggle is usually two points: the courage to remove an unnecessary step (because the person who added it is in the room) and experience in product comparison. Outside help accelerates both. 👥
The project needs an internal owner — ideally someone who lives that process daily. A project without an owner stops when the consultant leaves. That’s the business’s decision, not the consultant’s. 🔑
Not necessarily, but proceed knowing the bias: recommending a process that suits their product is natural. Getting a second opinion or producing the requirement list with an independent party restores balance. The decision must stay with you.
You can. Write the process with your own team, remove unnecessary steps, then research products. Outside help brings speed and blind-spot detection. The one thing you shouldn’t do is buy software without writing the process at all.
Not wrong — it eases coordination — provided that firm has no product it’s obliged to sell. An independent consultant can recommend what fits. Where there’s a product tie, that freedom narrows.
Source: BCG — digital and technology