FOUNDER PROFILE· 22 APRIL 2026

Architect of the innovation: when you're not the coder

You don't have to write the code. You do have to be the architect. Scott Horton's minimum bar for founder ownership of the innovation, and how to meet it.

Duke Harewood
Duke HarewoodFounder, TorlyAI
22 April 2026 · 8 MIN READ
torly.ai/insights/architect-of-innovation
Architect of the innovation: when you're not the coder

Most non-technical founders worry about the same thing when they read the Innovator Founder Visa criteria: do I need to be able to code? The answer from every public source is no. What you need to be is the architect.

Scott Horton sets the standard precisely:

At the very minimum they must be seen as the architect of that innovation and they know exactly what the innovation is they're proposing.
Scott Horton, Envestors

Source: envestors.co.uk.

And again, with the metaphor that became the standard:

They may not be the coder and have the technical expertise to actually build the technology, but they certainly know how to define, how to shape, how to — they know what they're planning to build. It's similar to an architect and a builder.
Scott Horton, Envestors

Architects don't lay bricks. They know which bricks, where, why, and what happens if you use the wrong ones. That's the standard.

What "architect" actually means in practice

An architect of the innovation:

  • Defines what the innovation is — not in buzzwords, in specifics. The workflow it changes, the data it needs, the output it produces.
  • Shapes how it will be built — the components, the dependencies, the decisions about what to build versus buy versus outsource.
  • Owns the technical trade-offs — understands why specific choices were made (language, architecture, data model) well enough to defend them.
  • Directs the build — the development team or outsourced vendor receives instruction from the founder, not the reverse.

A founder who meets this bar can walk through the technical architecture of their product in a 10-minute conversation with an engineer. They don't have to be the engineer. They have to be able to have the conversation.

The ghost-written test

The architect-of-the-innovation standard exists specifically to catch ghost-written applications. Horton:

We've seen a very lot of ungenuine — if that's the word — applicants. Somebody has proposed the idea for them and the idea on itself can sound very innovative perhaps, but there's a missing link. There's no track record experience — viable applicant — that links to the proposition.
Scott Horton, Envestors

Ghost-written applications fail predictably because the founder can't reason about the technical substance of the idea. The pitch deck holds up; the follow-up questions don't. Covered in ghost-written ideas and buzzword traps and the dynamics of the formal presentation interview.

The three common non-technical founder paths

Non-technical founders can clear the architect bar in three distinct ways. Pick the one that matches your actual situation.

Path 1: Deep domain expertise with a technical co-founder

The strongest pattern. The non-technical founder has spent years inside the sector being disrupted (healthcare, logistics, financial services, education, manufacturing), understands the workflow being changed, and has paired with a technical co-founder who handles the build.

In this pattern, the non-technical founder is the architect of the product-market interaction — they know exactly which workflow is being changed and why. The technical co-founder is the architect of the system. Both architectures need to be explained in the application, ideally by their respective owners.

Path 2: Product management / technical leadership background

Founders with prior product management, engineering management, or technical program management roles can be the architect without writing the code themselves. They've shipped products before. They know how software gets built even if they don't build it directly.

In this pattern, the founder's track record at their prior company is evidence. Specific projects shipped, decisions made, team sizes managed — the detail demonstrates that architectural judgement was exercised historically, and will be exercised again.

Path 3: Sustained deep engagement with the technical build

Founders without a technical background or a technical co-founder can still clear the architect bar, but the path is harder. They have to have spent enough time on the specific build — 6-12 months minimum — that they genuinely understand the technical choices.

"I spent nine months working with two engineers to build the MVP. I reviewed every architectural decision. I can walk through the data model, the API structure, and the reasons we chose PostgreSQL over MongoDB" is a passable statement. "I hired an agency to build it" is not.

Know exactly where your application stands.

Get your free AI assessment in 90 seconds.

Get your assessment

What doesn't clear the bar

Several configurations reliably fail the architect test:

"I had the idea, my friend built it." If the friend owns the technical decisions, the friend is the architect. The founder is a vision-haver, which isn't enough.

"I outsourced the whole build." Horton is direct that the innovation must happen in-house in the UK, not offshored to a home country — and that an outsourced core build typically fails the architect test regardless of geography. Richard Harrison at Innovator International reinforces:

When you're not designing the solution and you're saying to a third party 'design me a solution, here's a theoretical problem, design me a solution, make it for me' — you're basically just offloading all of the IP generation.
Richard Harrison, Innovator International

"I'll hire a CTO once I arrive." The plan can include a CTO hire, but the current state needs to show that the founder has the technical ownership in the interim. Intending to hire someone doesn't meet the bar at application.

"My plan-writer explained the technology to me." If the founder's understanding of the technology comes from the person who wrote the plan, the founder is not the architect. Horton:

If they have no prior experience of the technology that they're actually proposing within this visa application, then of course that's a big red flag.
Scott Horton, Envestors

How to demonstrate you're the architect

Four forms of evidence carry weight:

Your CV

Industry role fit. Ten years in fintech presenting a fintech proposition is the strongest possible signal. The bar for demonstrating technical ownership is lower when your career makes it obvious. See why viability of the applicant is the #1 assessment factor.

Prior shipped work

Patents you've authored. Products you've led. Papers you've published. GitHub contributions with your name on them. Anything where you can point at an artefact and say "I made the decisions that shaped this" is evidence.

In-interview reasoning

The formal presentation interview is where this gets tested in real time. A founder who can reason about technical trade-offs — why X not Y, what would change the decision, what the failure mode looks like — demonstrates ownership. A founder who retreats to "my team will handle that" does not.

Named in-house UK collaborators

The people who will build with you in the UK. A UK-based technical co-founder, named and evidenced, materially strengthens the architect story. See co-founders, skill gaps, and in-house teams.

What this looks like in a strong application

A strong non-technical applicant submission typically includes:

  • The founder's background in the sector, with specific roles and durations.
  • A named UK-based co-founder or employee who owns the technical build, with their background evidenced.
  • A technical architecture section in the business plan that the founder can walk through and defend.
  • Evidence of prior engagement with the technology — pilots run, prototypes built, patents filed, research completed.
  • An in-interview demonstration that the founder reasons about the technology rather than recites about it.

A weak non-technical applicant submission typically includes:

  • A high-level description of the technology with no specifics.
  • Generic technology language ("AI-powered", "blockchain-secured") without mechanism.
  • Plans to hire a CTO post-visa without current technical ownership.
  • A plan-writer named in the conversation as the technical authority.
  • Retreat to "my team will explain that" when pressed in interview.

Cross-body note

Both Envestors and Innovator International test for founder ownership of the innovation. Envestors uses the "architect" language explicitly; Innovator International uses the "founder played a key role in the research, design and implementation" framing from its four innovation questions. The underlying test is identical. See the three endorsing bodies compared.

External context

The Home Office Innovator Founder Visa guidance requires the applicant to be a founder or "very senior" member of the business proposing the innovation. The architect-of-the-innovation test is how endorsing bodies operationalise that requirement.

Key takeaways

  • You don't have to code. You do have to be the architect — the person who defines, shapes, and owns the technical trade-offs.
  • Three valid paths: deep domain expertise with a technical co-founder, product/technical leadership background, or sustained personal engagement with the build.
  • Ghost-written applications fail this test reliably because the founder can't reason technically.
  • Evidence that works: CV fit, prior shipped work, in-interview reasoning, named UK technical collaborators.
  • "I'll hire a CTO once I arrive" doesn't clear the bar — the architecture ownership has to exist now.

Tags
  • architect
  • founder
  • ownership
  • envestors
  • technical

Share

Know exactly where your application stands.

Get your free AI assessment in 90 seconds.

Get your assessment