Adding structure to a spike

Scaling without losing what made you special

You built something that does one thing exceptionally well. Customers love it. They overlook the missing features, the rough edges, the things that break occasionally - because your product solves their specific problem better than anything else. You have product-market fit for your very narrow group. You’ve got a tall spike that got attention, but it’s starting to wobble.

You built the spike by ignoring everything else. Technical debt? Future problem. Feature parity? Doesn’t matter until it does. You won by being narrow and sharp while everyone else was broad and dull.

But right now, your spike is just an outline. Without internal structure, it won’t stay standing as it grows.

This essay assumes you’re growing toward bigger accounts. If your spike is simplicity itself - if staying small and focused is your strategy - this isn’t for you. But if you’re trying to scale to larger customers, read on.

From Outline to Structure

Building the spike was about proving the point exists. Building the structure is about proving the point can scale.

Everything shifts. The engineering mindset goes from “whatever works” to “whatever lasts.” The priority goes from speed of discovery to speed of deployment. Debt stops being a tool for survival and becomes a threat to the mission.

This isn’t about making the spike broader or duller. It’s about making it solid. Under real weight - enterprise requirements, scaling demands, the grind of daily operations - an outline doesn’t wobble. It snaps.

You’re not replacing the spike. You’re reinforcing it. The spike is still the point. The structure is what lets it reach higher.

The Real Warning Sign

The obvious symptoms are easy to spot: deploys slowing down, engineers avoiding parts of the codebase, prospects walking away over missing features. Everyone knows these are problems.

The real warning sign is subtler: you start making reactive decisions.

We’ve all seen a founder spend Q3 building an integration to win a big contract, then Q4 disappears into a security overhaul after a near-miss with a vulnerability. January becomes an all-hands on a feature a competitor had launched. By February, they realised they’d shipped nothing from the original roadmap in six months. The company isn’t failing - revenue was up - but they’re not at the wheel anymore. They’re was just not crashing.

When you’re stable, you choose what to work on. When you’re unstable, you’re always responding to whatever’s most on fire. Each reaction makes sense in isolation. The pattern is the problem.

If most of your roadmap is shaped by what went wrong last month rather than what you’re trying to build, your structure is failing.

Here’s a quick diagnostic: look at your current sprint. How much of it was decided in the last two weeks? If it’s more than a third, you’re not building structure. You’re just a very expensive fire extinguisher.

Why Focus Needs to Persist

How do you build structure without losing the spike? Stop going 100% on anything. Maintain a balance - some attention on differentiating, some on the structure that supports it.

But don’t shift that balance too often.

Here’s why: engineers build mental models. Understanding a system well enough to improve it takes weeks. If you redirect someone after two weeks, you’ve paid the learning cost without getting the payoff. Do that repeatedly and you’re spending most of your engineering capacity on context-switching, not building.

How long should focus persist? Long enough to ship something complete, whatever that means in practice. “We’re improving deploy reliability until deploys are under 10 minutes” beats “we’re doing infrastructure for Q2.” The first ends when you’ve built something; the second ends when the calendar says so, whether you’ve achieved anything or not.

Set a focus. Hold it until you’ve shipped something meaningful, and then reassess.

But what about the fires that don’t wait? The database that starts melting in week two, the security issue that can’t be ignored? You can’t just “hold focus” through a genuine emergency.

The answer isn’t discipline. It’s capacity. You need some portion of the team dedicated to structural work. But don’t call it “maintenance” or you’ll lose your best people. Frame it as building the automated systems that make the spike possible: deploy pipelines, monitoring, reliability infrastructure. The prestige has to match the importance, or your high performers will see it as a demotion and start updating their LinkedIn profiles.

When to Build, When to Buy

If you’re going upmarket, enterprise features like SSO, audit logs, and role-based access aren’t optional. Without them, you can’t support bigger customers.

The question is whether to build them yourself. The simple version: build what touches your spike, buy what doesn’t.

Auth, payments, email delivery, and monitoring are almost always a buy. These are solved problems. The vendors have spent years hardening them. You won’t do better, and the months you’d spend trying are months you’re not sharpening your spike.

But buying isn’t skipping. Integration is still engineering. Buying Auth0 means your engineers spend two weeks on a high-quality integration instead of six months on a low-quality build. The win isn’t “no work” - it’s different, shorter work. And integrations accumulate their own maintenance debt over time: API changes, version upgrades, vendor deprecations. You’re trading one kind of structural work for another, less painful kind.

But what if something touches your spike and is a solved problem? Your differentiation might require unusual auth flows. Your spike might depend on custom analytics.

Here’s the test: is the way you’d build it part of what makes you special? If you’re just integrating a standard solution more deeply, buy it and customise. If the implementation itself is where you differentiate - if your competitive advantage depends on doing it differently - build it. The hard cases are real, but they’re rarer than founders think.

Most “we need to build this ourselves” decisions aren’t strategy. They’re productive procrastination. Building auth or infrastructure feels like real work because the requirements are clear and the path is known. Building the spike is scarier since it might not work, customers might not want it, or you might just be wrong. So engineers gravitate toward the comfortable structure work and away from the high-stakes spike work. It looks like progress, but it’s actually an escape.

The Hardest Part

There’s no escape from the tensions. Differentiation, parity, debt will pull in different directions forever.

The spike gets the glory. It’s the thing customers talk about, the thing that wins deals, the thing that got you here. The structure is invisible. Nobody praises it externally. They’re just happy your product works.

The thing is, success at this stage looks like doing less of what made you successful. Less pure spike work. More of the boring reinforcement that lets the spike keep growing.

Some founders struggle with this because they can’t accept it emotionally because they fell in love with building the spike and can’t let go. Others have the mindset but lack the skills to build structure, or the team, or the capital. The blocker is different, but the outcome is the same: a spike that stops growing because there’s nothing holding it up.

The spike got you here. But a spike with nothing underneath it is just a monument to what you used to be good at.