Fractional CTO for Non-Technical Founders: How to Check Work You Cannot Read

Signs a build is on track, none of which require a code editor

You do not need to read code to read a project. You need to look at what comes out of it on a regular schedule. Software that is going well leaves evidence that a layperson can see, and software that is going badly tends to leave excuses. Keep a short weekly note, and these patterns show up within a month.

The right-hand column is not proof of bad faith. A lone developer under pressure ends up there honestly. But it does mean all the risk has collected in one person, and that person holds the only map. Founders often find this out on the day the person stops answering email. You can learn plenty before paying anyone, and the steps below will show you how.

When you do want someone to read the work directly, that is the case for Casey Kinnison, DataCram's fractional CTO. Casey is a builder of custom software applications who does full stack development and relational database management, wrote Athena CMS and ships DataCram's own software. A developer's estimate or a vendor's excuse gets read by someone who has written the code and designed the databases, and who can check it.

Who holds the keys: code, domain and the accounts

Ownership is the cheapest risk to fix and the most painful to discover. Each item below should be in the company's name, with you or a company email as the top-level admin. Developers should be invited in as users. If the reverse is true, the fix is usually a polite email, and asking early is a lot easier than asking during a dispute.

An afternoon's check you can run this week

1. 1

   Ask for owner access to the repository

   Frame it as housekeeping, because it is. A good developer will have no objection. Even if you never open it, you now hold a copy of what you paid for.

2. 2

   Look up your domain and your bills

   Confirm who the registrar account belongs to and whose card pays for hosting. Set a calendar reminder for the renewal.

3. 3

   Ask for a staging link

   A staging site is a private working copy. Ask to use it on your own phone, on a schedule, and try the three things your customers do most.

4. 4

   Match last month's invoice to finished items

   Put each line next to something you can click. What is left over is a question to ask, not an accusation.

5. 5

   Run the free checks

   Run a website health check and a site audit if a public site exists. They cannot judge your code, but they will catch the visible problems.

Those five steps do not require any skill you lack, and they change the relationship. A founder who holds the keys and looks at the work every two weeks is hard to drift away from. Honest developers often prefer it, since it makes their progress visible and gives them a person to tell when something is taking longer than expected.

Casey worked as a trader, and a trader has a term for a lone developer holding every password: an oversized position. The whole company rides on one name, with no exit agreed in advance. Nothing about that requires bad intent. It requires a second copy of the code, a second set of keys and a date on which someone checked.

Tech debt, and the caveats on the number everyone quotes

Tech debt is the shortcut you took to ship on Friday, and the interest is paid on every change after that. Your developer may well have made the right call. Debt is a tool at a startup, just as it is at a bank. The trouble starts when nobody writes the debt down, so it grows without an owner, and every estimate gets longer for reasons no one can explain to you.

The figure you will see cited comes from McKinsey, in October 2020. In a survey of 50 CIOs at financial and technology companies with over $1 billion in revenue, it estimated tech debt at 20% to 40% of the value of the technology estate before depreciation, with 10% to 20% of new-product technology budgets diverted to it. That study is old and its subjects are huge. It says nothing about your six-person startup, so do not let anyone sell you a remediation project with it.

What you can do instead is ask for a plain list: each known shortcut, what it slows down, what it would cost to fix and what happens if you leave it. Some items deserve to stay on the list forever. A fractional CTO's job is to keep it honest and to push back on the rewrite as readily as on the shortcut. For the small-business version of the same argument, read "we'll fix it later".

AI-written code: a quick draft that still has to answer for itself

A founder with a chatbot can now produce a working demo over a weekend. That is real, and we use these tools ourselves when building agents and software. Using them is sensible. The trouble is that a demo looks exactly like a product until the first customer tries something unusual, or until someone asks how the logins are stored.

• Someone has to understand it. Code that nobody on your side can explain is a debt from the first day, whoever or whatever wrote it.
• Vulnerabilities still count. Verizon's 2026 report says 31% of breaches start with software vulnerabilities, and a model will write a flawed login form as fast as a sound one.
• Secrets stay out of prompts. Passwords, API keys and customer records should not get pasted into a tool without a written rule allowing it.
• Tests come before trust. Ask for automated tests that fail when the important things break. Then ask to watch one fail.
• A human reviews before release. The person who approves should be able to say what changed and why.

None of this is an argument against using AI. Casey sets rules for it, the way a shop sets rules for a table saw. If you want AI inside the product itself, AI integration and AI agent development are separate projects with their own risks and prices.

What investors and buyers ask once the deck is finished

Sooner or later someone technical arrives on the other side of the table, hired by an investor or a buyer. Good questions are not a trap, and they are predictable. You can answer most of them in a document long before anyone asks, and doing so says more about the company than any slide. We cannot promise a funding outcome, and neither can anyone else.

• Does the company own its code, and can it prove that with signed contracts?
• How many people can deploy a new version, and what happens if one of them leaves?
• What personal or payment data do you hold, where does it live and who can see it?
• When was a backup last restored, and how long did it take?
• What are the known shortcuts in the code, and what would fixing them cost?
• What does the software cost to run per customer, and what happens to that at ten times the size?

Before the first line of code: specification, price and a second opinion

If nothing has been built yet, you are in the cheapest position you will ever occupy. A written specification turns a vague idea into something three firms can bid on. Many first versions do not need to be custom at all, and a good CTO should tell you so. Others do, and the startup or software company route has its own priorities: one sharp feature, a repository you own and enough documentation that you can change vendors.

DataCram builds this kind of thing: web apps start at $575, depending on complexity, iOS or Android apps from $3,750, and API integrations go live the same day, all on our pricing page as of November 2026. Our cost guide shows how to budget for the seat. And if the first problem you will face after launch is getting customers, the fractional CMO section covers that side. To talk it through, write to us and a person will reply.