How to Plan a Software Project When You Are Not Technical
If you are thinking about commissioning a software build, whether that is a new app, a system to replace something your business already uses, or a tool to solve a problem you keep running into, the planning stage is where everything starts. And for most people without a technical background, it is also where things start to feel overwhelming.
Over the past two decades working on software projects, including large-scale platforms and early-stage builds, I've seen the same planning problems appear again and again. When the business problem, users, and scope are unclear at the start, development quickly becomes guesswork.
There is a lot of advice out there aimed at developers and product managers. This is not that. This is for the business owner who needs a new system and is not sure where to begin, and for the individual who has an idea for an app and wants to understand what they are actually getting into.
You do not need to become technical to plan this well. You just need to get clear on a few important things before you start talking to anyone who wants to build it for you.
- Planning is the most important stage of a software project and the one most often rushed.
- Most projects run into trouble because of unclear requirements, not bad developers.
- Business owners upgrading existing systems need to map what they already have before briefing anyone.
- You should be able to describe what you are building, who it is for, and how you will measure success before approaching a developer.
- A written brief, even a short one, significantly improves the quality of quotes you receive.
- Getting clear on constraints early (budget, timeline, integrations) prevents the most common and costly surprises.
Why so many projects run into trouble early
Most software projects that go wrong do not fail because of bad developers. They run into trouble because not enough thinking happened before development started.
That is not a criticism, it is just how it tends to happen. Someone has an idea, or a problem that needs solving. They find a developer or an agency. They have a conversation. A quote comes back. Work begins. And somewhere along the way it becomes clear that what is being built is not quite what was imagined, or costs twice what was expected, or takes far longer than anyone said.
The gap between what you picture and what gets built is almost always a planning gap. Not a technical one.
There is also a specific trap that business owners fall into when upgrading an existing system. The temptation is to ask for what you already have, but better. The problem is that what you currently have has usually grown through years of small workarounds and staff habits and recreating it without thinking clearly about what you actually need just rebuilds the problems you were trying to leave behind.
The conversations you have before a developer starts work are the most important conversations in the whole project. Getting those right; being clear about what you need, why you need it, and what success looks like, makes everything that follows easier and less expensive.
What you need to get clear on before you start
You do not need a lengthy written specification before you approach a developer. But you do need clear answers to a handful of questions. Without them, any quote you receive will be based on assumptions and assumptions are where cost and timeline surprises come from.
What problem are you actually solving?
This sounds obvious, but it is worth sitting with. What is the specific thing that is broken, slow, or missing right now? Who does it affect? How often? The more precisely you can describe the problem, the better placed you are to judge whether what a developer proposes will actually solve it.
Who will use it?
Not a category of people, a real person, or a clearly described type of person, with a specific need. For business owners, this is often your own staff. That matters, because a system your team does not understand or trust will not get used, however well it is built.
What does it need to do first?
Not eventually, first. What is the smallest, most focused version of this that would be genuinely useful? This is the foundation of a well-scoped project. Everything else can come later. Getting clear on the first version stops the scope from growing out of control before build has even begun.
How will you know it is working?
What does success look like 90 days after launch? Pick one measure. It could be time saved, errors reduced, customers served, or something else entirely, but having a clear answer to this question keeps the whole project honest.
What are the constraints?
Budget. Timeline. Any existing systems the new build needs to work alongside. Any legal or data requirements. Anything that could limit your options. Bringing these into the conversation early means you are not discovering them halfway through.
The five things to settle before you speak to a developer
Think of these as the five things you need in place before any scoping conversation. They do not need to be formal documents; a page of clear notes is fine. But without them, you are effectively asking a developer to make your decisions for you.
- A one-sentence description of what the product does. If you cannot explain it simply, the brief will be unclear and developers will fill the gaps with their own assumptions, not yours.
- A clear picture of who uses it and what they need it to do. For business owners, think about your staff as well as any customers. For individuals commissioning an app, think about the first real person who would find this useful.
- A short list of what the first version must include and a separate note of what can wait. This is your scope. Keeping it focused at the start is one of the most valuable things you can do for your budget and your timeline.
- A plan for what happens after launch. Who looks after the system? Who handles it if something goes wrong? Who decides what gets built next? These questions are much easier to answer before you start than after.
- A clear definition of done. How will you know the project has been delivered successfully? This needs to be agreed with your developer before work begins, not during the final week.
If you are replacing an existing system, there is one more thing
- Map what you currently have before you brief anyone. What does your existing system or process actually do? Where are the gaps and workarounds? What do people rely on day to day, even if it is clunky? Your developer cannot build a good replacement for something they do not understand and you cannot brief one well without this clarity.
- Pay particular attention to data. Old systems often hold years of records. Moving that data to a new system is almost always more complex than it looks, and it needs to be planned for, not discovered as a problem in the final week of the project.
A simple planning framework
Use this table to organise your thinking before any conversation with a developer or agency. Work through each row and write plain answers, not a polished presentation, just honest notes. A founder or business owner who can fill this in clearly is genuinely ready to commission a build. If certain rows are hard to answer, that is useful to know now rather than later.
| Area | What to think through |
|---|---|
| The problem | What is broken, missing, or not working well enough? Who does it affect and how often? |
| Current state | If replacing something existing, what does it do now? Where are the gaps and workarounds? |
| The user | Who will use this? What do they need it to do? How will you get their buy-in? |
| First version scope | What must the new system do at launch? What can be saved for a later phase? |
| Success measure | How will you know it is working 90 days after launch? |
| Constraints | Budget, timeline, existing systems to connect with, data or compliance requirements |
| After launch | Who owns, manages, and develops the system once it goes live? |
When a bit of outside help makes sense
Some people can work through this on their own without too much difficulty. Others find it genuinely useful to have someone alongside them who has been through this process many times and can ask the questions they have not thought to ask yet.
An independent advisor, someone who is not the developer who will be building your product, can help you in ways that are hard to replicate on your own. They can look at what you are planning and tell you honestly whether it makes sense. They can help you write a brief that gets you accurate quotes rather than vague estimates. They can review what a developer proposes, so you are not trying to evaluate something technical with no frame of reference.
The most important word there is independent. A developer has a commercial interest in the project going ahead. An advisor whose only job is to help you make a good decision has a very different kind of interest and that difference is worth a lot when you are about to commit a significant amount of money.
Qube Catalyst works with business owners and founders at the very start of a software project, helping you get clear on what you need, what it should cost, and what to watch out for. No jargon, no pressure. Just honest guidance from someone who has seen a lot of these projects from the outside.
A quick sense-check before you approach anyone
Before you have a scoping conversation with a developer or agency, it is worth being able to answer most of these honestly.
- I can describe what I am building or replacing in one or two sentences
- I know who the primary users are and what they need it to do
- I have thought through what the first version needs to include, and what can wait
- I have a rough idea of my budget and timeline
- I know what existing systems this needs to work alongside, if any
- I have thought about data; what needs to move, and what might be lost or left behind
- I have a sense of what success looks like after launch
- I have written at least a short brief, even if it is just a page of notes
If most of these feel comfortable, you are in a good position to start having conversations. If several feel uncertain, spending a bit more time on the planning now will save you a lot of time and money later. That is not a criticism, it is just how these projects work. The thinking you do before you start is always the best investment you make.
Nobody who commissions a software build for the first time feels fully prepared. The goal is not to know everything before you begin, it is to be clear enough that you can have honest conversations, ask sensible questions, and make good decisions as the project unfolds. That is entirely achievable, and this is what good planning gives you.