How to Buy Custom Software When You Don't Have a CTO

A while ago we took over a system that a previous vendor had built for one of our clients. Solid company, complex product, software at the centre of how they sell. During the handover we found something nobody in the company knew: they did not own the intellectual property to their own system. Not the code, not the rights to change it. Years of business logic, owned by someone else.

Nobody had done anything wrong. There was simply no one in the building whose job it was to know. No CTO to read a software contract the way a lawyer reads a lease.

Most of the companies we work with are in this exact position, and the data says they are the rule, not the exception. This guide covers what actually goes wrong when a company buys custom software without a technical executive, what to prepare before you talk to any vendor, and what to insist on before you sign.

Why is buying software so much harder without a CTO?

Because the modern buying process assumes expertise you do not have in-house. Gartner's research on B2B buying puts numbers on it: the median buying group is 6 to 10 people, and they spend only about 17% of the buying journey talking to potential suppliers [1]. The remaining 83% is internal: researching, comparing, arguing. In a company without a CTO, that 83% happens without anyone who can verify a vendor's technical claims, and it shows: in a 2025 Gartner survey, 74% of B2B buying teams reported "unhealthy conflict" during the decision process [2].

The outcome is measurable. Capterra's Tech Trends research found that around 60% of software buyers regret a purchase made in the previous 12 to 18 months, and of those, 56% describe the financial impact as "significant" or "monumental" [3]. Notably, 89% of the regretful buyers hit an unexpected implementation disruption first: integration problems, migration issues, delays. The purchase did not fail at the demo. It failed where nobody could see.

What do companies without a CTO actually get wrong?

From our delivery work, the failures cluster in three places, and none of them is "picked bad technology".

Ownership. The story above: IP, source code access, repository ownership, infrastructure accounts. If your vendor disappears tomorrow, what do you legally own and what can you physically access? Companies with a CTO ask this in week one. Companies without one find out during a handover, a dispute, or a sale of the business.

Knowledge concentration. Another client of ours lost their technically skilled people, and with them the ability to evaluate their own system, built on an ageing legacy stack. The CEO was smart and committed, and suddenly the most technical person in the company. Every vendor conversation became an act of trust rather than judgement. We ended up rewriting the system, but the more expensive problem was the year of decisions made without anyone able to check them.

The translation gap. Engineers answer the question you asked, and without a translator nobody notices it was the wrong question. A team without a technical executive negotiates scope in business language, receives delivery in technical language, and discovers the mismatch in production.

What should you prepare before you even shortlist vendors?

Most buying guides start at vendor selection. That is already too late: a vendor quotes what you can articulate, and fills every gap you leave with assumptions. Before the first call, write down four things. None of them requires technical knowledge; all of them are questions we ask clients in the first workshop anyway, so arriving with answers puts you in control of the conversation.

1. Business goals. What is the main goal of this system? How will success be measured, in numbers you already track (quote turnaround, error rate, orders per person)? What specific problem are you solving? If you cannot answer these, no vendor can scope honestly, and every scope change later will be argued against a blank page.

2. Users and their journey. Who is the primary user: your sales team, your dealers, your production planners, the end customer? What are their goals and pain points, where do they start, what obstacles do they hit, what is the desired outcome? A system bought for "the company" fits nobody.

3. A map of your current systems. One page: what systems are in place (ERP, CRM, file shares, the Excel everyone pretends not to depend on), how they interact, what data needs to flow between them, and where the gaps are. Every integration surprise we have ever untangled traces back to a system that was missing from this map.

4. Your data and content. Who owns the product data, price lists, drawings and documents the new system will need, and what state are they in? "We will clean the data during the project" is where timelines go to die.

What should you insist on before signing with any vendor?

The questions below do not require a technical background. They require only the discipline to ask them and to insist on written answers.

Who owns the IP? All code written for you, owned by you, stated in the contract. No "licence to use".
Where does the code live and who controls access? You should hold owner rights to the repository, the cloud accounts, the domains. Not the vendor.
What happens when we part ways? A written offboarding path: documentation, handover, no hostage data.
Who else can read this? Any competent third party should be able to review the code and architecture. If a vendor resists external review, that is the answer.
What are we NOT getting? Every scope has an edge. A vendor who cannot name what is out of scope has not thought about it.
How will we work during delivery? Clear responsibilities on both sides, a timeline with milestones, testing checkpoints tied to those milestones, and an agreed way to communicate changes. Delivery habits are set in the first two weeks; put them in writing before the kick-off.
What will we see, and when? Wireframes and mockups before code, a feedback loop with named people and response times, demos on a working system rather than slides.
How will we know it works after go-live? Agree the KPIs up front (adoption, error rates, time saved), who reviews them and how often. A system nobody measures degrades quietly.
How many vendors are we comparing, and for how long? Capterra's data on successful buyers is specific: shortlist of no more than three, decision within about three months [4]. Longer processes produce fatigue, not quality.

Do you need to hire a CTO to buy well?

Usually not, and for a 50-200 person company a full-time CTO is often the wrong spend. What you need is someone technical whose incentives sit on your side of the table during decisions.

That role has a name now: a fractional CTO. A senior person who joins your side part-time, reads the contracts, asks the vendor the uncomfortable questions, and translates between your business and any delivery team, including ours. With more than one client, this is where we eventually landed, and we learned to keep the roles deliberately separate: the delivery team has a project manager whose job is to ship, and the fractional CTO sits with the client, whose job is to challenge what gets shipped. Same company, different interests, on purpose. It works because the client stops buying on trust and starts buying on verified answers.

This is now a named part of our offer. Our technology strategy advisory exists because we kept meeting this exact problem at the start of client relationships: someone has to sit on the client's side of the table in conversations with consultants, SaaS vendors and the rest of the software landscape, before anything gets built. Business advice first, implementation when it makes sense.

If your vendor offers something similar, one honest test applies: does that person ever tell you NOT to build something? A client-side advisor who never says "no" is a salesperson with a different title. That test applies to us too.

Frequently Asked Questions

What is the single biggest risk when buying custom software without a CTO?

Ownership, not technology. A mediocre system you fully own can be fixed or replaced. A good system you do not own, hosted on accounts you do not control, is a dependency you discover at the worst possible moment. Check IP, repository access and infrastructure ownership before you evaluate a single feature.

What should we prepare before contacting any vendor?

Four things: business goals with measurable success criteria, a picture of the primary users and their journey, a one-page map of your current systems and data flows, and an honest look at the state of your data. Vendors scope against what you articulate; gaps get filled with assumptions and change requests.

How much of the buying process happens without the vendor?

Around 83%, according to Gartner: buyers spend only ~17% of the journey with potential suppliers. That is why internal capability matters more than vendor promises; most of the decision is made when the vendor is not in the room.

What does a fractional CTO cost compared to a bad purchase?

A fractional CTO is typically a part-time engagement, priced in days per month. For comparison, 56% of buyers who regretted a software purchase described its financial impact as significant or monumental (Capterra). The comparison is rarely close.

Can our accountant or lawyer check the software contract instead?

They should read it, and they will catch payment and liability terms. They will not catch a missing IP assignment clause disguised as a licence, repository ownership, or an architecture that locks you into one vendor. Those need someone technical who represents you.

The Bottom Line

Buying custom software without a CTO is not a knowledge problem you can read your way out of; it is a representation problem. The buying process is long, mostly internal, and full of claims nobody in the company can verify. The fix is not becoming technical yourself. It is doing the preparation only you can do (goals, users, systems map, data), insisting on written answers about ownership and exit, agreeing how you will work before the kick-off, and putting one person with technical judgement on your side of the table.

We build custom software for manufacturers and operations-led companies, and we tell every client the same thing before any contract: if you cannot answer who owns your code today, start there, not with new features. Book a welcome coffee and we will go through the nine questions above against your current setup, whether you build with us or not.