A developer's job is to build what you describe. An IT partner's job is to figure out what you should actually build — and then build it.
That distinction sounds minor. It isn't.
The Same Budget, Two Different Outcomes
Here's a situation I've seen play out more than once.
A company comes to a developer with a clear request: "We need a website with a product catalog and a contact form." The developer builds exactly that. The project delivers on time, on budget, technically correct. Six months later: no traffic, no leads, the catalog is already out of date because updating it requires technical skills nobody on the team has, and the contact form emails are going to an inbox nobody checks.
The developer didn't do anything wrong. They did their job correctly. The problem is that someone needed to ask the business questions before a line of code was written — and that wasn't the developer's job.
Now take the same company, same budget, same request — but this time they're talking to someone who asks questions first.
Before any design or code, there's a 30-minute conversation. Who are your customers? How do they find you today? What do you want them to do when they arrive at your site? What happens after they submit a form — who sees it, and how fast? After those 30 minutes, the answer might look completely different: you don't need a catalog at all. You need a landing page built around the three services people actually buy, connected to your CRM so leads don't fall through the cracks.
Same budget. Completely different outcome.
The Questions That Should Come Before the Code
When a new client describes a project to me, I spend the first part of the conversation asking about their business, not the technology. What are they selling, and to whom? What does success look like in 12 months? What's the most painful part of how things work today?
The technology is how we solve the problem. Understanding the problem comes first.
This matters especially for companies hiring outside IT help for the first time. If nobody is asking the business questions, you end up with technically correct solutions to the wrong problems. The code works. It just doesn't do what you needed.
This is also where experience shows. After 25 years of development and 12 years as CTO of a logistics company, I've been involved in enough projects to recognize, early in a conversation, when someone is asking for a thing when they actually need a different thing. Sometimes what they've described is exactly right. But at least the idea has been pressure-tested before anyone starts building. When the stakes are higher — a major platform decision or an acquisition — that same discipline is what technical due diligence provides formally.
slug="fractional-cto"
text="If you're not sure whether you need a developer or someone to own the bigger technical picture, that question itself is the answer. I work as an IT partner for growing businesses — asking the hard questions before a line of code is written."
/>
What This Looks Like in Practice
An IT partner relationship doesn't mean your project takes longer or costs more. It means the conversation before the work is different.
Instead of receiving a specification and starting immediately, there's a brief period of asking uncomfortable questions. What problem are we actually solving? Who will maintain this after it's built? What happens when it breaks? Is this the right tool for this job, or is it the tool you happened to think of first?
Those questions take maybe a few hours. They can save months of rebuilding something that technically worked but practically didn't.
The companies I do my best work with are the ones who come in willing to have that conversation — where the brief is a starting point for thinking, not a contract I'm being hired to execute. Those projects tend to be more focused, finish faster, and produce something the client actually uses rather than something that gets quietly shelved. The pi-pi.ee B2B platform — 28 languages, 32 EU markets, six payment methods — started with exactly that kind of conversation, not a specification document. The result was a system the team actually uses across borders, not a deliverable that got filed away. For a broader look at what this ownership model means day-to-day, see what a fractional CTO actually does.
If you have an IT project and you're not sure you're solving the right problem, let's talk before you build anything.
Top comments (0)