The bottleneck is the brief

If you've scrolled the home page, you've seen a few thousand particles drift to the right, jam against an invisible wall, and pour through a small gap as you scroll. People keep asking how we got the helical vortex.

The honest answer: we didn't.

There is no helix in the code. There is a wall, a gap, a flow direction, and a rule that says if you are near the wall and not in the gap, get pushed toward the gap. Run that rule on a few thousand particles and what emerges is a swirling, vortex-looking pattern that nobody wrote.

That is also our entire methodology.

Constraints first, behavior second

Most agency engagements start with a feature list. The client wants a hero, a project grid, a CMS for blog posts, a contact form, three CTAs, and integrations with HubSpot, Customer.io, and a homegrown lead-routing thing. The team turns those features into tickets, the tickets into a build, and the build into a site that does what it says it does and almost nothing else.

We start somewhere different. We start with the constraints.

Where is the marketing team blocked today? What is the longest queue in the funnel? Which surface is the brand drifting on? What does engineering refuse to touch?

Those are the bottlenecks. The features are the gap you cut into the wall to let the flow through.

When you build that way, behavior emerges. The site is fast not because someone wrote a "make it fast" ticket, it is fast because the constraint that mattered was that marketing could not ship copy without filing a dev ticket, so we removed the dev ticket from the path, which removed the build server from the path, which made the whole thing fast as a side effect. You did not solve performance. You solved the bottleneck. Performance came along.

The hero is the methodology, rendered

The animation on the home page is the same idea, drawn:

• Particles want to move from left to right. So does the work. The site has a job to do.
• A wall stands in the middle. So do the bottlenecks the team is currently jammed against.
• There is a gap in the wall. The gap is whatever change unblocks the flow. A new CMS architecture. A componentized design system. A container that hosts both the marketing site and the application. The exact change depends on the client.
• As the gap opens, the particles pour through. Behavior emerges. Marketing ships, engineering breathes, the brand stays whole.

Nobody wrote the vortex. The vortex is what shows up when you set the right constraints and let the system flow.

Why this matters for client work

It changes what a kickoff looks like. We do not start by picking templates or scoping plugins. We start by asking the team what is in the way. Then we name three to five constraints we believe are the right ones to relax. Then we write a plan that does exactly that, and very little else.

It changes what a deliverable looks like. We do not optimize for feature count. We optimize for the shape of the flow. If the constraint was that marketing could not ship copy, the deliverable is a site marketing can ship on. Whatever supports that goal stays. Whatever does not gets cut. A short feature list with a clean shape will outwork a long feature list with a tangled one every time.

It changes what handoff looks like. A site built around the right constraints is legible. The next developer who opens the codebase reads the constraints from the structure. They do not need a tour. The bottleneck and the gap are visible in the architecture, the same way they are visible in the animation.

The shorter version

Pick the right wall. Cut the right gap. The flow does the rest.

That is the whole methodology, and now it is also the hero animation.

If that resonates with how you think about your stack, tell us about your project.