On constraints

Image credit

https://unsplash.com/photos/a-close-up-of-a-window-with-a-clock-on-it-hxxhjaEd6pQ?utm_source=63921&utm_medium=referral

Topic

DecisionMaking

Type

Quick take

We're building a company with limited budget, limited time, and funding that's enough to move but not enough to waste. Every euro counts. Every sprint counts.

That's not a complaint. That's the best thing that could have happened to us.

Constraints force decisions. And decisions force clarity.

When you have unlimited budget, you "explore." You build features nobody asked for. You hire ahead of need. You overcomplicate things because you can afford to. When you have constraints, you build what matters. You cut the noise. You ship.

Here's a real example. We needed a task management system. The brief was wide open — technically, we could build anything. Custom workflows, automations, integrations, the works. A system that "does everything."

And that's exactly where the danger was.

A system that does everything does nothing well. We've all seen it. The internal tool that became a monster. The Notion workspace with 47 databases that nobody understands. The "flexible" platform that requires a PhD to configure.

So we started with constraints. On purpose. What's the minimum this needs to do? What are we NOT building? What's the simplest version that still solves the problem?

That changed everything. The constraints didn't limit us — they guided us.

There's actually solid theory behind this. Eliyahu Goldratt introduced the Theory of Constraints back in the '80s, originally in a book called The Goal. The core idea is simple: every system has a bottleneck, and the performance of the entire system is determined by that single constraint. Instead of trying to improve everything at once, you identify the constraint, exploit it, and subordinate everything else to it.

Goldratt's five steps: identify the constraint, decide how to exploit it, subordinate everything else, elevate the constraint, and repeat. It was written for manufacturing, but it applies perfectly to startups. You don't have infinite resources, so find the one thing that's actually blocking progress and fix that. Ignore the rest.

Most founders I talk to think constraints are a problem to solve. Something to overcome once the next round closes. I think the opposite. Constraints are the reason you're building something focused instead of something bloated.

The companies that scare me are not the well-funded ones. It's the small, constrained teams that ship fast and stay focused. They don't have the luxury of indecision.