The most important decisions in a custom software project get made before a single line of code is written. They sit in the questions that do or don’t get raised upfront: what this needs to deliver, who will use it, what happens after launch. We’ve been holding intake conversations about custom software since 2001, and the projects that go well share one thing: the hard questions came at the start, not halfway through.
So what follows isn’t generic project management advice, but the questions as they actually come up at our table. First the questions we’d ask you, then the questions you’re entitled to ask any development partner.
The goal comes before the feature list
Most requests we receive already arrive as a solution: a portal with a login, a link between two systems, a dashboard for management. Understandable, but our first intake question deliberately ignores that list. What needs to get easier in your organisation? Which work keeps piling up, where do mistakes creep in, which decision takes too long because the information isn’t there?
The answer determines what actually needs building, and sometimes that’s less than what was asked for. Part of the wish list often turns out to fit into software you already have, or disappears once the underlying process is simplified. If you’re unsure whether custom software is the right route for your situation, start with how custom software compares to off-the-shelf options.
The questions we ask during an intake
Every organisation is different, but these questions come back in almost every first conversation:
- Which process costs your people the most time right now, and how does it run today, step by step?
- Who will use this daily once it’s live, and who decides whether it’s succeeded?
- Which systems does the software need to exchange data with, and who manages those systems?
- What happens if you change nothing for a year?
- Who maintains the software after launch: your own team or your development partner?
The answers steer decisions that are hard to reverse later. The number of integrations says more about complexity than the number of screens. The least technical user determines how simple the interface needs to be. And the question of what happens if you change nothing shows what the challenge is already costing you.
What to ask a development partner in return
A good intake works both ways. A handful of questions tell you whether you’re sitting across from a partner or a supplier. Who owns the source code after delivery? What does maintenance cost per year, and what do you get for it? How quickly is there a first working version, and what can you already do with it? That first question in particular gets asked too rarely; how you avoid vendor lock-in is a subject in its own right.
Pay attention, too, to what doesn’t get asked. A party that starts calculating a price the moment your wish list ends has skipped the most important step: understanding why you have those wishes.
Not everything needs to be fixed in advance
A watertight forty-page specification isn’t a precondition for a good project. It’s more of a risk, because it locks in decisions at the point everyone knows the least. What does need to be clear before anyone starts programming: the goal, the users and the systems around it. The rest takes shape during the project, tested against a first working version rather than a document.
Want to know where that first version would start for you? Our page on custom applications explains how we get from challenge to working software. Bring your answers to the questions above, and the conversation won’t start with software, but where it belongs: with how your organisation works.