Before I joined this fintech startup, the company had been running for a few years. But those years were almost exclusively product development — no operations, no marketing, no systematic documentation of anything.
I was the first person brought in specifically for operations and marketing. And like most people, I started with a "ship first, organise later" mentality. In a startup, you have to move fast before you know what the problems are. That logic isn't wrong.
But I later discovered there's an important line between "ship first, organise later" and "never organise at all." That line is: the moment you hire your first person.
When a company has three to five people running on instant messages and verbal agreements, you can't feel the problem. Everyone knows the rules because the rules live in everyone's head.
The problem explodes the moment a new person joins. You suddenly need to onboard someone and discover there's no onboarding process. A customer complains, and the new hire doesn't know the refund policy, because the refund policy was a tacit agreement between you and the founder — never written down. Someone asks about the communication standard, and you say "it depends" because you're genuinely not sure what the standard is.
Every "it depends" is a landmine waiting to detonate.
During this period, I spent time at a local UK tech company with around 100 employees. Their onboarding was thorough enough to be almost startling. Every role had clear accountability definitions, standard operating procedures, and a "things you need to know in your first month" document. New hires in week one already knew who to ask for what, and what they could decide independently versus what needed escalation.
This isn't bureaucracy. This is efficiency.
When an organisation's knowledge lives entirely inside human heads, the scaling limit of that organisation is the memory capacity of those humans.
Many people think "building documentation" is administrative busywork — written and then left to gather dust in some folder nobody visits. But I've come to understand that the act of building documentation is itself organisational design.
When you create a folder for each department, you're drawing an org chart. When you decide whether a document belongs under "Legal" or "Operations," you're defining accountability boundaries. When you write a refund SOP, you're making a decision — not deferring it to later. You're making it once, and everyone gets to use it forever after.
An org chart isn't for external display. It's for internal use. It tells you which roles need to be filled as you go from three people to ten, which processes need to be split, which decisions can be delegated.
Before I actually built our document architecture, I assumed our core departments would be Commercial Development, Marketing, and Customer Service.
Doing the work revealed that compliance and legal should come first.
We're a payment system operating under FCA regulation in the UK. Customer funds flow through our infrastructure. A bug, a chargeback dispute, a compliance question — any of these can freeze the system and leave a customer's money stuck. This isn't something you think about "later." It's the defence you build on day one.
I ultimately isolated Legal as its own category — not because we had a legal department, but because the frequency with which legal issues appeared was far higher than I'd anticipated: vendor contracts, fraud cases, FCA requirements, cross-jurisdictional compliance. Centralising all of it made every subsequent legal interaction — finding a solicitor, collecting evidence, checking a regulation — dramatically faster.
That act of organisation was itself a form of risk management.
Many startups, when they think "operations," only think outward — customer service, brand communications, commercial partnerships. Internal operations matter just as much, and are usually more urgent.
When a colleague hits an emergency, they need an SOP telling them what to do next. Without one, they message you, you get interrupted, and your time is no longer yours. When a customer asks about refunds, an unstandardised "it depends" produces inconsistent customer experiences, which slowly erodes brand trust — not because of any single bad decision, but because of the absence of a decision.
Standards themselves are protection for brand reputation.
Not on day one. On day one of a startup, you should be doing things, not writing about things. You need to run first to understand what's tripping you.
But if you're paying attention, somewhere around six to eight months in, you'll start seeing patterns — which problems keep recurring, which decisions keep needing re-explanation, which processes keep breaking when personnel changes.
That's when you build documentation. Not because you have time. Because you now have enough material to know what needs building.
The tools available now can handle a lot of the structural work: you describe your industry, your operational situation, your customer profile, and AI can generate a first draft of a document map, a naming logic, a folder structure. That's genuinely useful.
But there's one thing AI cannot do: it doesn't know where your company is most fragile. That knowledge requires being inside the system, stepping on the landmines, and then looking back to say "this is where we need a wall." AI gives you the map. You tell it which roads you've walked and where the potholes are. Together, you turn that map into something actually usable.
Every time you say "we'll sort it later," you're scheduling an overtime session for your future self. Not today's overtime — the overtime in the moment when you're most stretched, most exhausted, and most in need of systems holding things together. That moment is usually: when you've just hired someone new, when you've just landed a big client, or when a crisis you didn't anticipate has just landed in your inbox.
You don't need to build every document on day one. You just need to write down the answer when you know the answer.
Those written-down answers become your organisational architecture.
Next: Why your English marketing copy isn't converting — and what AI can and can't fix