Splinx Studio
Projects rarely fail because someone picked the wrong framework. They fail because everyone agreed on a plan while quietly imagining a different thing.
The discovery conversation is where that gets caught, and it's the cheapest hour in the whole project. Here's most of what we ask.
What has to be true for this to have been worth it?
We ask this first because it forces a real answer. "A modern website" isn't one. "Twenty enquiries a month instead of four" is. So is "my office manager stops spending Fridays reconciling fee records."
Once there's a number or a specific frustration on the table, every later argument about scope has something to be measured against. Without it, the loudest opinion in the room wins by default.
Who actually uses this, and on what?
There's usually more than one answer, and the second one is where projects go wrong. A school platform has administrators on desktops, but it also has parents checking fees on a five year old phone. A hospital system has doctors moving between rooms with a few seconds to spare.
If we only design for the person paying for the project, we tend to build something that's a pleasure to demo and a chore to use.
How do you do this today?
Before proposing anything, we want the current process in detail, including the ugly parts. Which spreadsheet, which WhatsApp group, which drawer, which thing everyone knows is wrong but nobody has time to fix.
The workaround people have built by hand is usually a better specification than anything written in a brief.
It also tells us what to migrate. Years of records in inconsistent spreadsheets are a real part of the job, and pretending otherwise is how a project loses three weeks in its final fortnight.
What happens when something goes wrong?
Every system has bad days. A payment fails halfway. Two people edit the same record. Somebody uploads a file with three duplicate rows and one date in the wrong format.
Asking early means those paths get designed rather than discovered. It's also a good way to find out how much a mistake actually costs the business, which tells us how much care that part of the build deserves.
What does not need to exist yet?
This is the most valuable question and the one clients enjoy least. Almost every brief contains features that sound essential and would be used twice a year.
Cutting them isn't about doing less work. It's about launching sooner, learning from real use, and spending the remaining budget on the things people turned out to need. Anything genuinely essential comes back on its own, quickly and loudly.
Who decides?
Finally, the unglamorous one: when there's a disagreement, whose call is it? Projects with three equal decision makers and no tiebreaker drift, and the drifting always shows up as a delay we get blamed for.
One name is enough. It doesn't have to be the most senior person, just the one who can end a debate.
Why we won't skip it
Occasionally someone wants to bypass all of this and get straight to building. We understand the instinct, but we've never seen it save time. An hour of questions has repeatedly saved us weeks of building the wrong thing carefully.