Every project that goes sideways skips the same phase. Not the build. The thinking that should have happened before anyone opened a laptop. The questions nobody asked. The assumptions everyone shared but nobody said out loud. The direction that was implied but never made explicit. Skip that phase and you will spend twice as much time and money fixing what you should have prevented.
We have watched this pattern for 25 years. It shows up in brand work, in infrastructure decisions, in AI deployments, in solo developer projects, in billion-dollar enterprise rollouts. The domain changes. The failure mode does not.
The pre-concept problem
The Smashing Magazine piece on turning brand strategy into visual direction makes a point that sounds obvious until you watch teams violate it every single week: the strongest work does not start in the tool. It starts with the right questions. There is a whole phase before the first concept — a phase where you surface hidden assumptions, align on what you actually mean when you say words like "bold" or "trustworthy" or "clean," and build a shared foundation that makes the eventual execution almost inevitable. Teams that skip this phase open Figma on day one and call the output a concept. It isn't. It is a guess dressed up in a nice typeface.
The same logic applies everywhere, and we mean everywhere.
Infrastructure decisions made without thinking
When someone switches from Google Drive to self-hosted storage, the move itself is not the interesting part. What is interesting is the question that had to come first: what do we actually need from this tool, and are we getting it, and what are we giving up to get it? Most teams never ask that question. They default to the familiar option, the one with the big logo, the one that was already running when they showed up. They stay on it until the pain is so loud they cannot ignore it anymore, and then they scramble. The teams that ask the question early, before the vendor lock-in calculates, before the data is somewhere they cannot easily move it, those teams make a deliberate choice. Everyone else makes a default.
Defaults are not neutral. They are just decisions you did not notice you were making.
Technical scope without context
Adding a new runtime to a browser-based tool sounds like a pure engineering problem. But the post on adding Go to a browser code runner is a quiet case study in what happens when you think through constraints before you start. The author had to work out execution boundaries, sandboxing, compilation targets, user expectations, all of it before writing the first line of implementation code. That upfront thinking is not overhead. It is the reason the implementation did not collapse midway through. The work before the work is what makes the work survivable.
Enterprise AI without the foundation
This is where the stakes get serious. The Stack Overflow conversation about building AI agent systems at enterprise scale is essentially a warning dressed as a roadmap: you cannot evaluate for reliability and correctness in an AI system you did not design for those properties from the start. Bolting evaluation on after the fact is not engineering. It is hope. The teams that are actually getting ROI from AI deployments are the ones who decided, before any model was selected or any API was called, what success looked like and how they would measure it.
And then there is the Deutsche Telekom story. The OpenAI writeup on how Deutsche Telekom is becoming an AI-native company is easy to read as a vendor case study. Read it more carefully and it is a story about pre-work. They did not start with the model. They started with the workflow. They mapped customer service, employee operations, network management, and the future of voice-based interaction before they started wiring anything together. That sequence matters. The AI is not the strategy. The strategy is the strategy. The AI is a capability they plugged into a foundation they already understood.
What this costs you right now
If you are running a $1M to $5M business and you are operationally stretched, the temptation to skip the pre-work is enormous. You are behind. The deadline is real. The client is waiting. The hire starts Monday. The tendency is to open the tool, start the project, and figure it out as you go. We understand the impulse. We have felt it ourselves. But here is what we have also seen, consistently: the time you spend doing the work before the work is almost always a fraction of the time you spend undoing a decision you made too fast.
A brand direction built without alignment costs you two extra rounds of concepts and a client who quietly thinks you do not understand their business. An infrastructure choice made by default costs you the migration you will eventually be forced to do, under pressure, with bad timing. An AI agent deployed without a measurement framework costs you a tool that looks impressive in demos and fails in production. A technical architecture scoped without constraints costs you a rewrite at the worst possible moment.
The pattern is not subtle. The pre-work phase is the one everyone skips, and it is the one that determines whether everything else goes smoothly or sideways.
What to actually do
Before any new project, any new tool, any new hire, any new strategy, ask three questions and write down the answers. Not in your head. Actually write them down, because the act of writing forces precision that thinking alone does not.
- What problem are we actually solving, and how will we know when we have solved it?
- What assumptions are we making that we have not verified?
- What decision are we about to make by default, and is it the decision we would make on purpose?
This is not a framework. It is not a process. It is just the discipline of naming the thing before you build it. Most teams treat this as overhead. The teams we admire treat it as the cheapest insurance they can buy.
The work before the work is the work. Everything else is cleanup.