The AnySpline Method
Ride the squiggle.
There is a drawing designers use to show how creative work really goes. It starts as a chaotic scribble, loops through research, dead ends, and revisions, and only near the end straightens into a single clear line. They call it the design squiggle. It is the most honest picture of building software we know.
Most software projects fail by straightening that line too early. Someone picks a solution in week one, the roadmap is drawn from the guess, and the mess that should have been worked through in cheap weeks resurfaces later as expensive quarters: rebuilds, unused features, a platform nobody asked for.
The fashionable alternative fails in the opposite direction. Design thinking, as practiced in most large organizations, has decayed into innovation theater: workshops, sticky notes, a five-stage framework performed instead of a problem solved. All ideation, no execution.
Our method is neither. We ride the squiggle deliberately: spend the uncertainty up front, where it is cheapest, with the smallest experiments that settle it. Then we execute. None of this is theory. It is what years of building and shipping products and services at big tech companies and high-impact startups taught us, distilled.
That is what the untangling buys. Software that matters comes out of the mess, not around it. Skip the squiggle and you ship filler: another app, another dashboard, another tool people quietly route around. Ride it, and you ship the thing that changes how the work actually gets done.
What follows is the journey we take you through, in four phases, each with a beginning, an end, and something real in your hands. Read it as a map, not a script. The squiggle is the territory.
And we never ride it alone. We take you along the whole way, because we love this work and it shows. None of these techniques are secret: learn them as we go, take them, use them on your own problems. A methodology that only works when we are in the room is not worth writing down.
Phase 01
Understand
Find the right thing.
Day one happens inside your workflow, not in a conference room. We shadow the people who live with the problem: we watch the spreadsheet get exported, the workaround get pasted, the phone call that fixes what the system cannot. Pain that never makes it into a requirements document is usually the pain that matters.
We interview the people doing the work and map the workflow as it actually runs, not as the org chart says it runs. We chase pain, not feature requests. When someone asks for a feature, we ask what they were trying to do when they started wanting it.
We think in jobs to be done. Nobody wants software; they want the job it exists for, done. Poorly designed productivity software only reinforces the oldest law of the workplace: work will find a way. People route around bad tools with spreadsheets, side channels, and heroics, because the job still has to get done. Only a deep understanding of the problem space, its workflows and the jobs inside them, makes it possible to manage work away instead of moving it somewhere else.
Two things we refuse to do in this phase: write code, and quote a build. An estimate given before the problem is understood is fiction with a currency symbol on it.
Resist solutions.
Sit with the people who have the problem.
You leave with
A written problem map: the workflow as it really runs, where it hurts, what the hurt costs, what we would build and what we deliberately would not. And an honest go or no-go. Sometimes the right answer is a process change, an off the shelf tool, or nothing at all. We will tell you.
Phase 02
Shape
Prove it's the right thing.
Now we make things, but nothing precious, and never just one thing. Prototyping is not a phase of its own; it is how shaping thinks. We whip up as many prototypes as the problem demands: clickable mockups, throwaway scripts, a spreadsheet that fakes the algorithm. Each one is a question wearing a user interface, aimed at a different direction through the problem.
Most of them exist to die. Cheap experiments kill bad ideas while they are still cheap: a prototype that dies in week three saves a build that would have died in month nine. The direction that survives has earned it.
We cut scope relentlessly, because scope is a design tool, not a negotiation. Every feature has to earn its place by surviving contact with a real user. The version we carry into the build phase is the smallest thing that solves the real problem end to end.
Testing happens in your users' real work, not in a review meeting. Demos mislead. Usage doesn't.
Prototypes over promises.
Kill ideas while they're cheap.
You leave with
A direction proven by the prototypes that survived and the ones that did not, tested with the people who will use the real thing. A build scope you can hold in your head, and a fixed shape for the build phase. If every direction dies here, it dies for a fraction of what a build would have cost. That is not a failure of the method. That is the method.
Phase 03
Build
Build the thing right.
Then, and only then, we build. Exactly the thing that survived shaping, and not the platform around it. The people building are the people you met in week one: principal members of our technical staff, no handoff to a delivery team, no B team.
You see working software every week, running against your data, not status reports about software. Momentum is the method: each week adds something a user can touch, and each piece teaches us something no plan could.
While we build, we train your team: AI-assisted development, modern engineering practice, and the judgment behind the tools. Handover is not a step at the end. It starts on the first day of the build.
Momentum over milestones.
Exactly the thing, not the platform.
You leave with
A production-quality system taking shape in your infrastructure, working software you can touch every week, and a team that has been learning it since the first commit.
Phase 04
Ship
The right thing, shipped right.
Shipping is its own discipline, not the last week of the build. We launch early and keep launching: the first version goes to real users long before it feels finished, because the first version in real hands is worth more than the perfect version in a branch. Every launch is a cheap experiment run against reality, and adoption tells us what no roadmap could.
Handover is the point, not the epilogue. The code, the infrastructure, the documentation, and the knowledge of why every decision was made are yours, and your team has been holding them since the first week of the build.
Our goal is that you need us less, not more. When the next mess appears, and it will, you know where to find us. Better still: your team, having ridden one squiggle with us, may ride the next one without us. We designed for both outcomes.
Launch early, keep launching.
Handover is the point.
You leave with
Production software live in your infrastructure, documented and tested, owned and operated by your team from day one. No license, no lock-in, no invoice required to read your own code.
The short version
Principles
No solutions before problems.
An answer chosen in week one is a guess with a budget. We earn the solution by understanding the problem first.
No innovation theater.
The mess is worked, not workshopped. If a sticky note matters, it's because someone acts on it the same week.
Prototypes over promises.
A rough thing in a real user's hands beats a polished deck in a meeting, every single time.
Scope is a design tool.
Cutting is not compromise. The smallest thing that solves the whole problem is the best version of it.
Weeks, not quarters.
Short phases keep uncertainty cheap and momentum real. Nothing we do takes a year to show value.
Seniors only, no handoffs.
The people who sat in your mess are the people who build the software. There is no handoff for anything to get lost in.
You own everything we make.
Code, infrastructure, documentation, knowledge. Our success is that you need us less, not more.
That is the method. The rest is your problem, as it actually is, which is exactly what we want to hear about.
Start here
Bring us the mess.
Thirty minutes with a member of our technical staff. No deck, no obligation. Just your problem, as it actually is.
Book an intro call →or write to hello@anyspline.com