The most important decisions in a custom software project are made before a single line of code is written. Whether you’re having a web app built, a client portal or an internal tool, those decisions sit in the questions that do or don’t get raised up front. What does this need to deliver, who will use it, what happens after launch. In more than ten years of intake conversations about custom software, we keep seeing the same thing: the projects that go well had the hard questions at the start, not halfway through.
So what follows isn’t generic project management advice, but the questions as they come up at our table. First the questions we’d ask you, then the questions you’re entitled to ask any development partner, and finally what you arrange yourself before the project starts. Why projects fail is something we covered in five reasons why web applications fail; this article is about the questions that prevent it.
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. “We want a web app” is a wish, not a brief. 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. Features that don’t touch any of the core points can wait on the bench. 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 has 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 problem is already costing you.
The answer to the first question is often less clear than you’d expect. An hour spent watching a planner or a back-office colleague at work tells you more than an hour discussing features in a meeting: you see where the work chafes, which steps an application can take over and which workarounds nobody ever wrote down. Do this before you sit down with development partners, so the conversation starts from practice rather than assumptions.
What to ask a development partner in return
A good intake works both ways. Past work tells you something: look at cases and pay attention to projects that resemble your situation. The first conversation tells you more. A partner who asks follow-up questions starts with your process and your goals, not their own technology, and translates every technical choice into what it delivers for you. A handful of questions tell you whether you’re sitting across from a partner or a supplier:
- Who owns the source code after delivery, and who can maintain the application later?
- How will you see, along the way, what’s finished and what isn’t?
- How are changes during the project discussed and priced?
- How quickly is there a first working version, and what can you already do with it?
- What does maintenance cost per year, and what do you get for 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.
Keep your budget honest
What custom software costs depends on its scope, the number of integrations with other systems, and the requirements around security and user numbers. What almost every project has in common: something comes up that nobody foresaw. Build in room for that in advance, in both budget and planning. The biggest misconceptions about the price of a custom web application we’ve set out separately.
Count your own hours too. Giving feedback, testing and bringing colleagues on board takes time from people who are already busy, and that time rarely appears in a quote. Appoint someone who makes decisions on behalf of your organisation, and give them the hours to do it. A project waits for a decision more often than it waits for a developer.
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.
Start that first version with the tasks that come back every day and make those flawless. An application that responds quickly and holds together logically gets used; one that’s packed with options but slow or confusing gets worked around. The rest can wait for a later round, guided by what users turn out to need after launch.
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.