There is a temptation, when commissioning a software project, to step back once the brief has been written. The developer has been hired; the specification exists. Surely the sensible thing is to leave them to it and wait for the result?
This reasoning feels professional — and it is one of the most reliable ways to get software that works technically but does not fit the business it was built for. Developers are very good at building things. They are rarely in a position to know which things to build unless someone with business knowledge stays actively involved. That someone is you.
The most successful app projects are not primarily technology projects. They are business change projects with a technical component. The distinction matters enormously for how you structure the work, what you take responsibility for, and what you hand over to the people you have hired.
An app project is a business change project with technical help. Until the business owner leads the outcome, the developer cannot lead the solution.
Why App Development Is a Business Change Project
When you commission software, you are not buying a product from a catalogue. You are funding a process that will change how your business operates — how work moves, how data is recorded, how decisions are made, how customers interact with you. Those changes ripple outward in ways that cannot be entirely predicted in advance.
Consider a logistics company commissioning a job-tracking system. The immediate goal is to give drivers a simpler way to log deliveries. But the project will also touch invoicing workflows, customer communication templates and staff habits. Each of those is a business decision, not a technical one. If the business owner is not actively shaping them, the developer will make them instead — working from incomplete information.
The framing matters because it determines who is responsible for what. Business change belongs to the business. Technical execution belongs to the developer. The trouble starts when those responsibilities blur — when developers are expected to decide what the business needs, or when owners assume the technology will somehow carry the change on their behalf.
The Healthy Split: Business Owns Outcomes, Developer Owns Technical Choices
The most effective partnership model is simple to describe, though it takes discipline to maintain.
The business owner owns the outcome: what success looks like, which problems matter most, which edge cases are common enough to build for and which are rare enough to handle manually. These are not technical questions. They require business judgement, and they can only be answered by someone who runs the business.
The developer owns the technical solution: how to build it, which architecture fits the scale, which approach will make future changes easier. These questions require technical judgement, and they can only be answered well by someone with experience of building software.
When each side trusts the other to stay in their lane, the project moves faster and produces better results. When the lines blur, both sides start second-guessing each other — and the project slows accordingly.
Treating your developer as an order-taker wastes the most valuable thing they bring: technical judgement. Expecting them to also do your job asks more than any one person can reliably deliver.
How Trust Is Built Through Clarity, Evidence and Decisions
Good working relationships on software projects are built through a specific sequence: the business owner gives the developer clarity about what is needed; the developer gives evidence of what is being built; both make decisions where those two things meet.
Clarity means being specific about outcomes, not prescriptive about solutions. “I need to see all outstanding orders at a glance, sorted by due date, with overdue ones flagged in red” is clear. “Build me a dashboard” is not. The first gives the developer something to aim for; the second invites them to guess what you value.
Evidence means not waiting until launch to see what is being built. Wireframes and prototypes mid-project are cheap to change. The same feedback after launch requires unpicking something already live.
Decisions will arise throughout — not just at the start. Technical choices belong to the developer. Joint ones (“We could do it this way or that way — which fits your business better?”) belong to both. Answer those questions promptly; delayed decisions are one of the most reliable causes of delayed delivery.
Why Phased Delivery Usually Beats Grand Certainty
There is a version of software commissioning that feels thorough: define everything upfront, agree a fixed price, wait for the finished system. It is appealing because it feels controlled. In practice it tends to produce a system that is out of date with what the business actually needs by the time it arrives — because requirements shifted, scope was underestimated, or the real workflow only became clear once people started using it.
A phased approach means dividing work into chunks that each deliver something useful, so the business can test real usage early and course-correct before significant money has been committed to the wrong direction. Phase one delivers the most critical workflow. Phase two adds reporting. Phase three handles the edge cases that turned out to matter more than expected. This requires more business involvement, not less — which is precisely what makes the software better.
The business owner who stays engaged across phases gets a system that fits. The one who signs off in January and checks in again in August rarely does.
A Practical Partnership Model for SMEs
Larger organisations have product managers and business analysts whose job is to sit between the business and the developer. Most SMEs do not — and do not need to, provided the business owner understands what they are taking on.
Before the project starts, write down what the business needs to be able to do — in plain language, without specifying how. The developer reads this, asks questions, and produces a proposal mapping those needs to a technical approach. Agree on the first phase, a rough timeline, and the key decisions that will arise along the way.
During the project, review work at agreed intervals — at minimum every two weeks. Answer questions promptly, raise concerns specifically (not just “this doesn’t feel right”), and test against real scenarios from your own business, not just the ones that seem tidy. When something needs to change, discuss the impact on scope and cost before the change is made.
The partnership model is simple in principle: the business owns what success looks like, the developer owns how to build it, and both own the communication in between.
Practical Steps to Lead Your Project as a Business Owner
- Write what the business owns before the project starts. List the outcomes you need — the workflows, the problems, the things the business must be able to do. Do not leave this to the developer to infer from a conversation.
- Write what the developer owns too. Acknowledge explicitly that technical choices — architecture, data structure, tooling — belong to them. Resist the urge to specify how things are built unless you have specific technical knowledge that is genuinely relevant.
- Define ‘done’ in business terms. Not “the feature is built” but “a new member of staff can take a booking from start to invoice without asking for help.” Concrete success criteria are testable. Abstract ones are not.
- Stay available throughout. Block time in your diary for reviews, not just at launch. A business owner who is hard to reach slows the project and shifts decisions to people who should not be making them.
- Test with real scenarios. When you review work in progress, test it against the actual situations your business encounters — the awkward customer, the partial order, the edge case that happens every Friday. Demos that only show the happy path miss the problems that matter.
- Raise concerns specifically. “The order screen is confusing” is hard to act on. “Our team calls this the pick state, not fulfilment status” is actionable.
Getting the Mindset Right
The business owners who get the most from software projects are not the ones who brief once and step away, nor the ones who micromanage every technical decision. They are the ones who stay engaged on the things that are genuinely theirs — outcomes, priorities, workflows, real-world testing — while trusting their developer to make the technical judgements they were hired to make.
The outcome is yours. The solution is theirs. Everything in between is a shared responsibility — and the ones who take that seriously tend to end up with software worth having.
Before your next project starts, write two short lists. The first: what the business needs to achieve, in plain language. The second: what you are trusting your developer to decide — the technical choices, without you second-guessing them. Share both on day one. It is the clearest signal you can give that this will be a genuine partnership, not an order and a delivery.
