How to Manage a Software Project When You Are Not Technical
You do not need to understand how code works to run a software project well. What you need is a clear way to define what success looks like, a process for making decisions without second-guessing every technical choice, and a few practical checkpoints that keep any development agency honest. This guide gives you exactly that, written for UK founders and ops leads who are commissioning custom software for the first time — or who have been burned before and want to do it better.
Why Non-Technical Managers Often Struggle (And Why It Is Not Their Fault)
The anxiety most non-technical buyers feel once a project starts is well-founded. Agencies and developers often communicate in technical shorthand, timelines slip without clear explanation, and it can feel impossible to know whether a delay is a real technical problem or a planning failure. The gap is rarely about intelligence — it is about not having the vocabulary to ask the right questions. Once you have that vocabulary, the power dynamic shifts.
Step-by-Step: How to Manage a Software Project Without a Technical Background
- Define outcomes, not features. Before a single line of code is written, write down what the tool needs to achieve in plain English. Not 'we need a dashboard' — but 'our ops team currently spends six hours a week copying data between spreadsheets; the tool should eliminate that.' Outcome-first briefs are harder for agencies to misinterpret and easier for you to hold them accountable to.
- Create a written brief and insist on a written scope. Verbal agreements evaporate. Your brief should cover: the problem being solved, who will use the tool and how often, what the tool must do on day one versus what can wait, and any systems it needs to connect to (e.g. Xero, Salesforce, your existing database). The agency's response should be a written scope of work — not a vague proposal — that lists specific deliverables.
- Ask for a phased delivery plan, not a big-bang launch. A reputable agency should break the project into phases or sprints — typically two-week cycles — with a working (if incomplete) product visible at the end of each one. If an agency wants to disappear for three months and surface with a finished product, that is a risk. You cannot course-correct what you cannot see.
- Establish one decision-maker on your side. Scope creep — where a project grows beyond its original brief — is one of the most common reasons UK software projects go over budget. It almost always happens because multiple people on the client side are making requests directly to the development team. Appoint one person internally who owns all change requests. Every new idea goes through them first.
- Learn to read a demo, not a codebase. You do not need to review code. What you do need is to attend every demo or review session and test the product yourself. Click through it. Try to break it. Ask 'what happens if a user does X?' If the agency cannot show you a working version at agreed milestones, that is a red flag — not a technical problem you should accept.
- Agree on a definition of done before you start. 'Done' is one of the most contested words in software. Before the project begins, write down what done means for each major feature: what inputs does it accept, what outputs does it produce, what happens when something goes wrong? This becomes your acceptance criteria — the checklist you use to sign off each piece of work.
- Protect yourself contractually. UK contracts for bespoke software development should cover: who owns the intellectual property once built (it should be you), what happens if the agency goes out of business mid-project, what the handover process looks like, and whether you receive the underlying source code. If any of these are missing from a contract, ask for them explicitly before signing.
- Build in a formal handover and documentation requirement. A tool you cannot maintain or modify yourself is a liability. Before final payment, require written documentation of how the system works, how to add users, how to make common changes, and who to contact for hosting or infrastructure issues. This is standard practice with a good agency and non-negotiable if you plan to bring the tool in-house later.
The Questions That Actually Tell You If an Agency Is Trustworthy
Most non-technical buyers ask agencies about technology choices (React vs Vue, AWS vs Azure) that they cannot meaningfully evaluate anyway. These are the questions that actually reveal whether an agency is a good partner:
- Can you show me a previous project where the brief changed significantly mid-way? What happened?
- What does your handover process look like, and will I receive all the source code?
- Who specifically will be working on my project, and will that change?
- How do you handle a situation where we disagree on whether something is in scope?
- What is the smallest version of this project that would still solve the core problem?
Tip
Pay close attention to how an agency responds to the last question. A team that wants to ship working software quickly will embrace a minimal first version. A team that is optimising for billing will push back and add complexity.
Common Mistakes UK Non-Technical Buyers Make
| Mistake | Why It Happens | What to Do Instead |
|---|---|---|
| Approving a proposal without a detailed scope | The proposal looks professional and you trust the agency | Ask for a line-by-line scope of work before signing anything |
| Letting the agency choose all the tools without explanation | It feels like a technical decision you cannot make | Ask: 'What are the trade-offs, and what does this choice mean for my ability to maintain or move the product later?' |
| Skipping the demo sessions | You are busy; you trust the team to get on with it | Block time in your diary at the end of every sprint — this is your primary control mechanism |
| Adding features mid-project without a change request process | Good ideas come up; it seems easier to just mention them | Every change goes through a formal change request that includes an estimate of cost and time impact |
| Paying a large upfront sum before any work is visible | The agency asks for it; it feels normal | Tie payment milestones to delivery milestones, not calendar dates |
What a Good Working Relationship With a Development Agency Looks Like
A good agency will welcome your involvement, not manage you out of the process. You should expect a regular rhythm of short written updates (often called a status update or sprint summary), a shared space where you can see tasks and progress (many teams use project management tools like Linear or Notion), and a direct line to the person actually building the product — not just an account manager.
The relationship works best when you are genuinely available. If the team needs a decision on a feature ambiguity and you take a week to respond, the project will stall or the team will make assumptions. Treat availability as part of your job on this project.
When to Escalate a Concern
Raise a formal concern (in writing, not just a Slack message) if any of the following happen: a milestone is missed without prior notice and explanation; you cannot get a clear answer about what is causing a delay; the scope is growing without a formal change request process; or the team stops being reachable between demos. These are not technical problems — they are project management problems, and they are your right to challenge regardless of your technical background.
Warning
If an agency responds to your concerns by suggesting the issues are 'too technical to explain', that is a warning sign. A trustworthy team will always be able to translate a problem into plain English, even if the solution is complex.
The Mindset Shift That Makes Everything Easier
The most effective non-technical project managers stop trying to understand the technology and focus entirely on the outcomes. Your job is not to validate the code — it is to validate that the product does what it was supposed to do, on time, within budget, and in a way your team can actually use. That is a job any sharp operator can do well, technical background or not.