The Goldilocks Approach: finding the right balance between systemisation and speed

Finding the systemisation sweet spot

When we talk about systemisation in product development, we’re talking about the processes, tools and standards we use to bring consistency to how we work, especially across design and engineering. It includes things like design systems, coding conventions, shared workflows and reusable patterns. All of it is meant to help teams move faster, stay aligned and reduce friction. But too much systemisation can slow teams down. Too little can create chaos.

At Instil, we’ve been refining our own product development process, moving from concept to delivery as fast as possible without sacrificing quality or consistency. If we move too fast, things break. If we add too much structure, teams get stuck in the process. The challenge is finding the sweet spot: just enough systemisation to keep things smooth, but not so much that it gets in the way.

Pixel perfect every time?

Take design systems. Our design team love a structured approach. Atomic design, reusable components and clear guidelines make sense. But reality doesn’t always let you build things in a neat, methodical way. Sometimes, you don’t have the time or budget to perfect the system before the product needs to ship. Sometimes, pixel-perfect alignment between design and code isn’t worth the extra effort. And sometimes, trying to get everything just right means nothing actually gets delivered.

So, we’ve taken a more pragmatic approach. Instead of meticulously crafting every component, we jump straight from foundational elements—typography, colour, grids - into real, working templates. The middle layers? They can wait. What matters is getting something functional in front of users as quickly as possible.

Prioritising user experience

For us, the production code is the source of truth. If it’s not built, it doesn’t exist. Tools like Storybook help us manage and visualise components in real-time. It acts as a live library - letting us see what we’ve built, reuse it where needed, and keep things consistent without over-engineering the system. But we don’t obsess over documenting every possible variant before anything gets shipped. The priority is the experience.

A seamless, end-to-end product beats a flawless design system that results in a clunky final build.

Making it just right

The right amount of systemisation is the amount that helps you move forward, not the amount that makes things perfect. A rigid process won’t work for every team and neither will total flexibility. The key is to build systems that adapt, not dictate. Because the reality is, systems don’t just shape workflows - they shape outcomes.

Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.

Melvin Conway

In this context, a system could be a design framework, a process map, or a team’s internal structure. Conway’s Law reminds us that the way we structure our systems influences the solutions we create. If teams spend more time working within the system than solving the actual problem, they should rethink their approach. Systems should serve the work, not the other way around.

Not too much. Not too little. Just right.