What a non-technical founder should own, and what to delegate

Here is the rule. Own every decision that encodes a business judgement; delegate everything that is craft. A business judgement is any decision whose right answer depends on what your company is for — what the product refuses to do, what counts as a wrong answer, who may see what, which trade-off you accept, and when you will ship. Craft is how those decisions get executed: schema design, framework choice, deployment, test strategy, the shape of the code. You can hire craft in a fortnight. Nobody can be hired to supply the judgement, because nobody else knows what the business is for.

The anxiety most non-technical founders arrive with is aimed at the wrong target. They worry about being unable to evaluate technical decisions, and under-worry about the judgements only they can make going unmade. An unmade judgement does not stay open: it gets made by default, silently, by whoever is typing — and defaults are chosen for the convenience of the code, which is a fine basis for a variable name and a terrible one for deciding which customers can see each other's data.

The clearest external statement of this division is not from a startup blog but from federal audit guidance. The Government Accountability Office's Agile Assessment Guide places acceptance squarely on the business side: "the product owner should identify acceptance criteria for every user story prior to development of the story," and "the acceptance criteria and definition of done constitute the expectations for the user story against which the requirement will be validated and either accepted or rejected by the product owner," who is "ultimately responsible for the user story." The guide is blunt about the consequence of abdicating it: "If customers are not involved in the review and acceptance process for software functionality, the software may not meet the intended purpose required by the customer" (US Government Accountability Office, Agile Assessment Guide, GAO-20-590G, September 2020). Written for organisations spending, by the same guide's count, at least $90 billion a year on IT. It applies unchanged at two people.

Own: what the product refuses to do. Every product has a refusal list, and if you have not written yours down it is empty — which means the answer to every request is yes until someone gets hurt. Will the assistant answer a medical question. Will you take a customer whose contract requires data residency you cannot provide. Will a refund ever issue without a human looking at it. What is the largest transaction the system processes unattended. None of those is a technical question; each is a statement about liability, brand and who you are willing to be sued by. Engineers will implement whichever answer you give and cannot give it for you.

Own: what counts as a wrong answer. If there is AI anywhere in the product, this is the single judgement most likely to go unmade, and it is the one that makes testing possible at all. NIST's AI Risk Management Framework declines to make it for you in as many words: the framework "does not prescribe risk tolerance," because "risk tolerance and the level of risk that is acceptable to organizations or society are highly contextual and application and use-case specific"; where established guidelines do not exist, "organizations should define reasonable risk tolerance," and only "once tolerance is defined" can risk be managed at all (NIST, Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1, January 2023). The framework also notes that "senior leadership sets the tone for risk management within an organization." At your size, senior leadership is you, and the deliverable is unglamorous: ten to twenty written examples of outputs that are unacceptable, and why. Hand those over and an engineer can build an evaluation suite. Withhold them and no suite is possible, whoever you hire.

Own: who may see what. The matrix is yours; the mechanism is theirs. You decide whether a regional manager sees peer regions, whether an agency user can see the agency's other clients, whether support can read a payment method, whether a contractor keeps access after the project ends. Those are commercial and legal positions. How the rule is enforced — row-level security, a policy layer, per-tenant schemas — is craft, and it should be argued about by people who have implemented it before. NIST's Zero Trust Architecture is a useful brief for the handover, because it states the standard the mechanism must meet: "least privilege principles are applied to restrict both visibility and accessibility," and "authentication and authorization to one resource will not automatically grant access to a different resource" (NIST, SP 800-207, Zero Trust Architecture, August 2020). You supply the rows of the matrix; security and compliance engineering is the half that guarantees nothing outside it is reachable, and it is why a student information system we built across 150+ college branches was designed with per-branch data isolation and audit trails from the first sprint rather than retrofitted once 150 branches were live.

Own: which trade-off you accept. Engineers can price two options; they cannot tell you which failure you would rather survive. Ship in six weeks with a data model you will migrate later, or in fourteen with one you will not. Take the dependency that saves two months and adds a company whose outage becomes your outage. Cache the number and show it fast, or read it live and show it slow. Both answers are defensible in every pair, and the choice belongs to whoever carries the consequence. The failure mode is not choosing badly; it is not choosing, so the answer arrives as an implementation detail and surfaces a year later as a surprise.

Own: the date, and therefore the scope. This is the judgement founders most often delegate by accident, usually by agreeing to a feature list and treating the date as an output. The US Office of Management and Budget requires federal agencies to "deliver useable functionality every 6 months," and when the Government Accountability Office checked, 22 agencies reported that 64 percent of their software development projects would meet it while GAO's own review of seven departments found approximately half actually did (US Government Accountability Office, Information Technology Reform: Agencies Need to Increase Their Use of Incremental Development Practices, GAO-16-469, August 2016). Organisations with a mandate and an auditor overstate their increment discipline by fourteen points. Fix the interval, let the scope be the variable, and you have kept the only lever that reliably works.

Now the hard part: the decisions that look like craft and are not. This is where the rule earns its keep, because these arrive dressed as engineering and get delegated on that basis. Which cloud region you deploy to is a data-residency position, and data residency is contractual. Whether you store a piece of personal data at all is a judgement about what you are willing to be breached with. Every third-party service you add is a subprocessor your first enterprise customer will ask you to name, in writing, with a deadline. Single-tenant or multi-tenant decides which customers you can ever sell to. A reliable test: if the decision would ever appear in a security questionnaire, in a contract, or in an apology to a customer, it is yours — however technical the conversation that surfaces it.

And the mirror image: what founders wrongly keep. Framework and language choice. Database engine. Code review. Sprint mechanics. Which of two competent engineers to hire for a role you cannot assess. Holding these does not reduce risk; it makes you a bottleneck on work you cannot evaluate, and it costs the judgement list the attention it needs. Eurostat found that among EU enterprises which considered AI and did not adopt it, 70.89% cited a lack of relevant expertise, ahead of legal uncertainty at 52.52% and data protection and privacy concerns at 48.83% (Eurostat, Use of artificial intelligence in enterprises, data extracted December 2025). Expertise is the top barrier and the most purchasable one. Buying it is the correct response; supervising it line by line is not.

How to delegate craft without abdicating it. Ask for three things in writing whenever a decision is made on your behalf: what was decided, what the alternatives were, and what would have to become true for it to change. You do not need to evaluate the engineering to read that paragraph usefully — you need to notice when the third clause is missing, because a decision with no stated reversal condition is one nobody has really thought about. A file of those paragraphs also gives your next engineer the thing that is never in the repository: why.

The four artefacts to own personally, each a page or less and kept current by you rather than by whoever is available. The refusal list: what the product will not do, and for whom. The wrong-answer list: concrete unacceptable outputs, which becomes the evaluation suite. The permission matrix: every role against every category of data. The trade-off record: decisions taken, with their reversal conditions. Six pages between them, an afternoon to start, and the entire difference between a founder who is non-technical and a founder who is absent.

This is also the honest test of a build partner: a startup software development company worth hiring will push those four documents back at you rather than quietly filling them in. The partner-side version of the same boundary is in the criteria for choosing a software development partner, and the reason the judgement list gets urgent right after launch is in what breaks when an AI-built prototype meets real users — several of those breaks exist because a judgement was never made, not because code was wrong. To find out which apply to what you have already shipped, the free production-readiness diagnostic reads a description of your system and names the failure modes most likely to bite first. On the date-and-scope judgement specifically, how to scope an MVP so it ships is the rule in full.