What CTOs Should Check Before Approving a Custom Build

When a business leader at your company comes to you with a custom-build proposal, the temptation is to react with one of two defaults: “sounds risky, let’s use the platform we already have” or “sure, let’s build it.” Both are wrong defaults. Here’s the CTO checklist that actually separates the good custom-build investments from the bad ones.

1. Is the workflow stable enough to encode?

Custom software is good at executing a defined process. It’s bad at being a sandbox where a workflow gets discovered. If the team asking for the build still changes their mind on the core process every quarter, custom is premature. Wait until the workflow stabilizes (usually 12–18 months of consistent practice), then build.

2. Does the workflow have a real cost of not fixing it?

The cost should be quantifiable, not vibes. Either labor hours, error cost, or lost revenue/opportunity. If the business case is “it would be nice to have,” pass. If the business case is “we’re paying X per year in labor and Y in lost deals to this,” consider seriously.

3. What’s the integration risk?

The fast death of custom software is over-coupled integrations. Map every external system the build needs to talk to. For each, identify: stable API? Auth model? Versioning policy? Rate limits? If any of those are unstable or undocumented, the build cost roughly doubles and the maintenance cost compounds. Either negotiate better access or scope around the unstable systems.

4. Who owns the code and the data, and what does “owns” mean?

“Custom” varies enormously by vendor. Some build on shared infrastructure with contractual access to source. Some build in your own cloud account with you holding the keys. Some build with proprietary platforms that effectively lock you in. The CTO question is: if the build partner disappeared tomorrow, what would it cost to keep operating? If the answer is “more than 6 months of internal effort,” renegotiate the ownership terms before signing.

5. What’s the security and compliance posture?

Real questions to ask, not theater: How is data encrypted at rest and in transit? What’s the access control model? What audit logs exist? What’s the backup and recovery plan? For regulated environments (healthcare, finance, personal data): does the architecture support the compliance regime you operate in, or does it require special handling? Get specific answers before scope is locked.

6. What’s the deprecation plan?

Every system gets retired eventually. The good ones get retired gracefully. Ask the build partner: if we needed to replace this in 5 years, what does that look like? A good answer talks about export formats, data portability, and clear contracts. A bad answer is hand-waving about “we don’t see that happening.”

7. The single “walk away” signal

If the build partner can’t articulate, with specificity, how they’ll handle a change of business requirements 6 months in, walk away. Custom builds that can’t adapt aren’t custom — they’re sunk costs with extra steps.