The four technical decisions I’d check before investing

Founders pitch their stack. You hear that it’s built on a modern framework, runs on one of the big cloud providers and uses the latest AI tools. None of that tells you much. Those choices are easy to have an opinion about, so they get plenty of attention. They’re also cheap to reverse, which is why they rarely matter much.

I’ve been around early technical decisions for over a decade. I spent three and a half years in the in-house product team at Forward Partners, a venture fund, building for its portfolio companies. Since 2023 I’ve made them for Propelr, where I’m CTO. One pattern has held the whole time. How much a decision gets debated depends on how easy it is to have a view on, not on what it costs to get wrong.

The test I use

Everything feels important at seed, so I don’t ask whether a decision is important. I ask what it would cost to reverse, and how long it would take to find out you need to. A poor framework choice costs a rewrite of the front end, and the team knows within a quarter. The expensive decisions are the ones where reversing means touching everything, and the bill arrives eighteen months later. Often that’s after the round you’re about to write a cheque for.

The cost of a technical decision is the cost of being wrong, multiplied by how long it takes to notice.

1. The data model

The schema is the part of the code everything else depends on. Every feature and every report leans on how the core things in the business were defined. Renaming a table is trivial. Finding out in month eighteen that a customer and an account were never the same thing, after four features were built assuming they were, means a rewrite, even if the ticket calls it a migration.

AI tools make this matter more. They make it cheap to produce a lot of code quickly, and all of that code sits on whatever shape the data already has. A wrong model used to slow a team down early, which was at least a warning. Now a team can stack a year of features on it before anyone feels the drag.

What I check: whether the core entities match how the business actually works, and whether the people who built them can explain why they’re shaped that way.

2. Tenancy and permissions

This is about whether one customer’s data is kept apart from another’s by the architecture, or by a filter someone has to remember to add to every query. It also covers whether a user and an organisation are separate things in the system, and where the rules about who can see what are enforced. Adding proper separation to a codebase that wasn’t built for it is one of the classic rewrites. It tends to be demanded at a bad moment, by the first large customer halfway through a deal, usually with a security questionnaire attached.

What I check: where access is enforced, whether that happens in one place or many, and what happens if one query forgets.

3. What they’ve built instead of bought

Anything a company builds rather than rents, such as payments, messaging, search or login, is more than a feature. The company now has to run it and keep it secure for good, and pay people to do that. At seed, the honest answer to most build-or-buy questions is buy. The fastest teams I’ve worked in or alongside rented everything that wasn’t the product and owned the one thing that was.

What I check: what has been built in-house that a supplier would do better, and whether the thing that’s meant to be special is the thing they’ve actually built.

4. What they’ve promised

These are things like uptime guarantees, where data is stored, a compliance standard, or “we never train on your data”. Once one of these is in a signed contract, it constrains every technical decision that follows. Founders agree to them on sales calls, reasonably enough, because the deal is real and the architecture feels abstract. Usually nobody technical is on the call.

What I check: the technical commitments in the customer contracts you or your lawyers point me to, and whether the system can actually keep them. I read those for what they ask of the code. What they mean legally is a question for your lawyers.

What I don’t worry about

• —Language and framework, within the mainstream. The best choice is usually whatever the strongest engineer is fastest in.
• —Which of the big cloud providers they use. They’re unlikely to move, and it rarely matters.
• —Microservices, monorepos and similar debates. At seed the right answer is usually one application in one repository.
• —Anything with a lot of online argument attached. The decisions that really can’t be undone are too specific to one company for anyone else to argue about.

If a pitch spends a long time on these, it isn’t a red flag. It just isn’t where the risk is.

They don’t look like decisions

The awkward thing about the four is that they rarely arrive as decisions. Nobody books a meeting called “should a customer and an account be the same thing”. It gets settled on a Tuesday afternoon, inside a ticket about something else, by whoever is nearest the code. So when I look at a company I check what they decided, and also whether anyone noticed at the time that they were deciding.

For an investor, that’s the more useful signal. A team that can tell you why it made these four choices, including the ones it would make differently now, is more likely to notice the next one.