Straight talk
If you drive a Mercedes, you take it to a Mercedes workshop. A mechanic who only knows Toyotas will do what they know — not necessarily what your car needs.
So why assume any technical team will implement a given stack equally well if that stack is not their bread and butter?
The market is big, loud, and increasingly tough on software houses. We see it — we have lived it from the inside. Developers recommended technologies they knew, where they already had libraries, templates, shortcuts — not necessarily what was best for you. Not because they acted in bad faith. Because **everyone optimises inside their own box**.
Vendors are not incentivised to tell you “this is outside our wheelhouse”. They are incentivised to **sign**.
Technology is 10% of the puzzle. A poor technology choice is not a 10% problem. It is the **foundation** you will stack every later mistake on.
Technology is 10%
Handing delivery to IT alone is like handing a house project to the formwork carpenter. The structure will stand. It may pass building code. The question is whether you will actually want to **live** in it.
BCG surveyed more than 850 companies and surfaced a ratio that collapses most transformation briefings.
Where implementation success actually comes from — the BCG split
Most organisations pour ~90% of their energy into that first 10%. They buy the licence. They pick the stack. They negotiate with the vendor. They sign. Only then do they wonder what to do with the system. Who will use it. How it will change a Tuesday afternoon when someone gets stuck and there is nobody to explain how it works.
Technology is 10%. A mismatched stack is not “just” 10% of your problem — it is the **bedrock** for the rest of the errors.
Developers reach for familiar tools the way people reach for Excel
Not because they are stubborn — because they know that environment. They know the edges and the workarounds. It is the same mechanism that sends a colleague around a new system back to a spreadsheet. Everyone optimises inside what they know. **So does your vendor.**
What you will not find spelled out in the BCG PDF
Some of the highest returns on new technology sit in developers’ **pet projects** — because they understand the problem from the inside. They match the tool to the problem, not the problem to whatever happens to be on the shelf. They know when a simple algorithm is enough and when a model earns its keep.
An organisation that buys an implementation without understanding the problem from the inside buys **someone else’s optimisation**. It pays for that choice for years — upgrades, migrations, prompts that broke when the model moved on.
That is why audit-style methods exist. And why most companies never lean on them.
Event storming, domain-driven design, Wardley maps, value stream mapping, impact mapping. It reads like a conference bingo card. In practice these are ways to answer one question **before** anyone chooses technology: what is actually happening here, and where is the real pain?
Event storming can surface the full event flow — including the exceptions nobody mentions in a tidy workshop because everyone assumes someone else already knows. DDD helps draw boundaries so tightly that integration stops being a science project and becomes a consequence of the design. Wardley maps show where a technology is already commodity and where craft still matters — a direct input to **build versus buy**.
None of these replaces showing up where the work happens. Each of them asks questions a typical tender never touches — not “which vendor wins”, but “do we even understand what we want to automate, and is it worth the candle?”
Most companies we meet start with the tool. Audit-style methods start with the **terrain**. That is the difference between navigation and **driving blind** while hoping the road appears.
Why we run working groups
We invite partners from different technology backgrounds into the same room on your problem. We do not arrive with a finished answer. We arrive with questions — and with people who have seen different answers work.
Every vendor knows their own stack. Every consultant has a favourite hammer. A working group has one job: find what **works for you**, not what flatters us.
Describe the problem and join a working group →
Read next: Who will deploy AI for us — sequencing, a deployment checklist, and the costs that never make it into the quote →
Consultation
Book a consultation
Send a short note on context — we will reply with a time slot and a suggested next step. You can also write to connect@atypical.pl.