Non-Technical Founder? 7 Tech Decisions You Cannot Delegate

The seven decisions that never leave your desk

You can delegate almost every technical task in your company — the database schema, the deployment pipeline, the choice of framework. Seven decisions you cannot: (1) who legally owns the code, accounts and domains; (2) what ships in v1 and what gets cut; (3) what you build versus what you buy; (4) who your first engineering hire or agency is; (5) what customer data you collect and how it is protected; (6) what "done" means and how you verify it; and (7) when you rewrite versus when you live with what you have. These are not technical decisions wearing a business costume. They are decisions about ownership, capital, risk and time. When founders hand them to whoever happens to be writing the code, the company does not fail loudly — it fails quietly. Runway drains into features nobody uses, the agency turns out to own the repository, and by the time you understand what happened you have no leverage left. CB Insights' analysis of 431 venture-backed shutdowns found 70% ran out of capital and 43% never found product-market fit. Underneath, most of the decisions below are decisions about how fast you burn cash and how quickly you learn.

1. Who owns the code, the accounts and the domains

The decision: whose name is on the legal title to every asset your company runs on — source code copyright, domain registrar, cloud account, app store accounts, payment processor, analytics.

Why founders wrongly delegate it: it feels like paperwork, and the person doing the work already has the credentials. Setting up cloud hosting under the agency's billing is faster on day one, and nobody wants to open an ownership conversation with the person they are about to trust with everything.

The failure mode: under US copyright law an independent contractor owns the copyright in what they create unless a signed written agreement assigns it to you. The "work made for hire" doctrine covers employees acting within their employment, plus a narrow list of commissioned categories that does not include ordinary software (17 U.S.C. § 101; Community for Creative Non-Violence v. Reid, 490 U.S. 730). Founders discover this in a due diligence data room, with an investor's counsel asking for assignment agreements nobody ever signed. The operational version is just as bad: if the App Store listing sits in your agency's developer account, firing them costs you your reviews, rankings and subscribers.

Ask: "List every account this product depends on and who owns each one." "Which are billed to your card?" "Show me the signed IP assignment for everyone who has touched this codebase, including subcontractors." If you are choosing a partner rather than auditing one, our guide to vetting a software development agency covers the contract clauses that matter.

2. What is in v1 — and what gets cut

The decision: the specific list of what your first release does, and the explicit list of what it deliberately does not.

Why founders wrongly delegate it: scope looks like a project-management artifact, so it drifts to whoever runs the backlog. Founders also confuse "I don't know how to build it" with "I don't know what it should do." You are the only person who knows which customer conversation justified which feature.

The failure mode: scope expands to fill the budget. The Standish Group's CHAOS research, presented at XP2002, found 45% of features in delivered software were never used and a further 19% rarely used — a figure argued over for two decades but never seriously displaced. Every unused feature was paid for in runway. The subtler cost: a bloated v1 delays first contact with real customers, which is the only event that produces the information you actually need.

Ask: "If we cut this, which paying customer walks away?" "What is the smallest version a real user could complete a real task with?" "What are we choosing not to build this quarter?" Write the answers down — a one-page scope document beats a Slack thread. See how to write a software requirements document for a format non-technical founders can maintain, and our custom software development approach, which starts from the cut list rather than the wish list.

3. Build versus buy

The decision: for every capability — authentication, billing, notifications, search, analytics, admin dashboards — do you write it or rent it?

Why founders wrongly delegate it: it sounds like an implementation detail, and engineers often prefer building. Building is more interesting, more controllable, and genuinely faster in week one. The costs land in month nine.

The failure mode: you maintain software that is not your product. A home-built auth system needs password resets, SSO, session invalidation, rate limiting, breach response and an on-call rotation, forever — a permanent tax on a team of three. The reverse failure is real too: buying a platform for the one thing that is your differentiation, then discovering you cannot change the behaviour customers pay you for.

The rule that holds up: build what customers pay you for, buy everything else, until the vendor bill exceeds the fully loaded cost of ownership. Price the buy option before estimating the build. Our build vs buy calculator and the longer founder's decision guide include the maintenance line most estimates omit. Ask: "What does the off-the-shelf version cost per month at our expected volume in 18 months?" "If we build it, who maintains it at 2am?" "Would a customer ever name this as a reason they chose us?"

4. Your first engineering hire — or your agency

The decision: the first person or firm with real authority over your codebase.

Why founders wrongly delegate it: you feel unqualified to judge, so you outsource the judgment — to a recruiter, a referral, or the cheapest credible bid. You are qualified; you just have to judge different things.

The failure mode: your first engineer sets the architecture, the tooling, the hiring bar and how decisions get made. A wrong first hire is not one bad hire — it is a filter every later hire passes through. With agencies, the specific failure is a bid that won on price because it excluded testing, deployment, security review and handover, then billed those as change requests.

What you can actually assess: can they explain a tradeoff to a non-technical person without condescension or fog? Do they ask about your customers before your stack? Do they volunteer what they would not build? Will they name the senior person on your account and let you meet them? Buy a two-to-four-week paid trial of real work before signing anything long, and read how to manage an outsourced development team before the contract starts, not after the first missed deadline.

5. What customer data you collect and how it is protected

The decision: which personal data your product collects, why, where it lives, who can see it, how long you keep it, and what happens when it leaks.

Why founders wrongly delegate it: it looks like a security topic, and security looks like an engineering topic. It is not. Under GDPR you are the data controller; under most US state privacy laws the obligation attaches to the business. Regulators and journalists name the company, not the contractor who wrote the endpoint.

The failure mode: IBM's 2025 Cost of a Data Breach Report put the global average breach cost at $4.44 million and found 63% of breached organizations had no AI governance policy, with unsanctioned "shadow AI" adding roughly $670,000 to the average breach. For an early-stage company the number that kills you is smaller and arrives sooner: the enterprise deal you cannot close because you have no security questionnaire answers, no retention policy and no idea which third parties hold copies of your customer records.

Ask: "Show me every place customer data is stored, including spreadsheets, analytics tools and AI services." "Which people can query the production database, and is that access logged?" "If a customer asks us to delete everything, what exactly do we do?" Collect less. Every field you do not collect cannot leak.

6. What "done" means — and how you verify it

The decision: the written standard work must meet before you pay for it and call it finished.

Why founders wrongly delegate it: "done" sounds like a developer's word, so the developer defines it — usually as "the thing I described works on my machine." You then accept a demo you cannot evaluate, nodding at a screen share.

The failure mode: you pay for the same feature twice. Work is marked complete, the invoice clears, and three weeks later a customer finds it breaks on mobile, or nobody wrote the error state, or it was never deployed to production. Without a written definition of done you have no contractual anchor — only a disagreement about what was implied.

A definition you can enforce without reading code: deployed to production, not staging; tested by you on your own phone and laptop against a written acceptance scenario; error and empty states handled; the two nearest features still work; someone other than the author has reviewed it. Put those five lines in the contract. Ask: "Give me the click-by-click steps to verify this myself." "Is this live for real users, or behind a flag?" "What broke while you were building it?" A partner who never reports anything breaking is not reporting.

7. When to rewrite — and when to live with it

The decision: whether to rebuild a system from scratch, refactor incrementally, or accept it and keep shipping.

Why founders wrongly delegate it: the request always arrives with technical justification you cannot evaluate — "the codebase is a mess," "we'd move faster on a clean foundation." It is also the first thing many new senior engineers propose, because reading someone else's code is harder than writing your own.

The failure mode: a full rewrite is six to eighteen months in which customers see nothing new while a competitor ships — and the old system still needs maintaining, so you fund two. The mirror failure is refusing every rewrite until the system genuinely cannot support the business, then rebuilding under duress with customers already leaving.

How to decide: demand the case in business terms. Not "the code is bad" but "feature X takes four weeks instead of four days because of Y, that happened three times last quarter, here is the cost." Ask for the incremental option first — most "we must rewrite" arguments are really "we must replace this one module." If a rewrite is warranted, insist the old and new run side by side so value keeps shipping. Then get a second opinion from someone with no stake in doing the work; that is much of what a fractional CTO is for.

Exact questions to ask a developer or agency

You do not need to understand the technology to evaluate the answer. You need to notice whether it is specific, whether it contains a tradeoff, and whether it survives a follow-up.

One meta-rule: if an answer leaves you more confused than before, that is data about the person answering, not about you. Senior technical people can explain their work to a smart outsider.

Frequently asked questions

Do I need to learn to code as a non-technical founder?

No. You need to learn to evaluate, not to build. The skills that pay off are reading an estimate critically, recognising a scope creep conversation, asking for tradeoffs rather than recommendations, and verifying that work is genuinely finished. A weekend spent understanding what a database, an API and a deployment are will serve you far better than six months learning a programming language you will never use professionally.

How do I know if my developer is doing a good job when I can't read the code?

Judge outputs and behaviour rather than code. Are working changes reaching real users on a predictable cadence — weekly, not quarterly? Can you personally verify each completed item against a written acceptance scenario? Does your developer proactively surface problems and things that broke? Do estimates roughly hold, and when they slip do you hear early rather than on the deadline? Consistent yes answers matter more than any code review you could not perform anyway.

Should I give a technical co-founder equity or hire an agency?

They solve different problems. A technical co-founder brings long-term ownership and unlimited hours but costs a large permanent equity slice and is extremely hard to reverse if the fit is wrong. An agency buys speed and capacity but has no stake in your outcome beyond the invoice. Many founders now do neither at first: they buy senior technical judgment part-time to make the seven decisions above, and use contractors for execution. Compare models and costs on our pricing page.

What does a fractional CTO actually do for a non-technical founder?

A fractional CTO owns the decisions you cannot delegate to the people executing them: architecture direction, hiring and vetting, vendor selection, scope arbitration, data and security posture, and the honest second opinion on whether a rewrite is justified. They typically do not write your production code. Traditional fractional CTO engagements run roughly $8,000 to $25,000 per month, which is why most companies at this stage buy that judgement in smaller scoped pieces instead — one technology decision at a time.

Who owns the code my agency writes for me?

By default, often not you. In the United States an independent contractor retains copyright in what they create unless a signed written agreement assigns it to your company — employment-style "work made for hire" rules do not automatically cover commissioned software. Never rely on an invoice or a verbal understanding. Require a present-tense written assignment covering all past and future work, signed by every contractor, and confirm they hold equivalent agreements with anyone they subcontracted to.

How much should an MVP cost?

There is no honest single number, because "MVP" describes a decision-making strategy rather than a fixed quantity of software. What you should scrutinise is the shape of the quote: a fixed price against a long, vague scope usually means risk has been priced in as padding, or will return later as change requests. Ask what the smallest testable version costs, what it excludes, and what the first three weeks would produce. Our custom software development page explains how we scope it.

What are the biggest red flags when hiring a development partner?

Refusing a paid trial. Unwillingness to name the senior person who will actually do the work. Accounts, repositories or app store listings held in their name rather than yours. Estimates with no stated risks. No written definition of done. Never reporting anything that broke. And any partner who answers "why this approach?" with an appeal to authority instead of a tradeoff. Our guide to vetting a development agency has the full checklist.

When should a non-technical founder bring in technical leadership?

Before you commission the build, not after it goes wrong. The decisions with the largest downstream cost — ownership structure, v1 scope, build versus buy, and who you hire — are all made in the first few weeks, usually by whoever was available rather than whoever was qualified. Getting those four right is cheap. Unwinding them eighteen months later, mid-fundraise, is not.

Make the seven decisions on purpose

None of these require you to write code. They require you to refuse to let the person doing the work also define what the work is worth, who owns it, and when it is finished. For a second opinion from someone with no stake in building it, book a free 30-minute technical session — we will walk your ownership checklist, your v1 scope and your current partner arrangement, and tell you plainly where the risk sits. If you want that judgement applied to the decision itself rather than to a one-off conversation, that is what our strategy work does.