Your Role in a Custom Software Project: What to Expect at Every Stage

At some point, most business owners commissioning software for the first time have the same expectation: you describe what you need, hand it over, and receive a finished product some months later.

That is not quite how it works.

Custom software is not something you buy and receive. It is something you create together — a collaboration between you, the person who understands the business, and the development team, who understands the technology. How well that collaboration goes depends as much on what you bring to the process as on how skilled the team is.

This article walks through each phase of a typical project and explains exactly what your role looks like at every stage — so you know what to prepare, what to watch for, and where your input makes the biggest difference.

Before the project starts: get clear on the problem

The most valuable thing you can do before a project kicks off is get genuinely clear on what problem you are trying to solve — not what features you want, but what is actually going wrong in your business right now.

What to prepare:

• A description of the current situation: how things work today, where the friction is, what it costs you in time or money
• A sense of who is affected — which people in your business, which customers
• A rough idea of what success looks like in six to twelve months
• Any constraints that matter from the start: budget range, must-have integrations, regulatory requirements, timeline pressures

You do not need a full specification. You need enough clarity to have a productive first conversation. The development team's job is to help you build the specification — but they need raw material to work from.

During discovery: share the messy reality

The discovery phase is where your input is most critical — and most underestimated.

Many clients try to present a polished version of how their business works. In a software project, that is counterproductive. The team needs to understand how things actually function, including the workarounds, the exceptions, the unofficial processes, and the parts that are embarrassingly manual.

What you should do:

• Be genuinely available for workshops and conversations — not just send a delegate
• Include the people who actually do the work, not just the people who manage it
• Share real examples: show the spreadsheet, walk through an actual order, demonstrate the process end to end
• Be honest about what you do not know — "I am not sure how we handle returns in that case" is far more useful than a confident answer that turns out to be wrong

The more realistic the picture the team gets in discovery, the more accurately they can design and estimate what they are building.

During design: react quickly and speak up

Once discovery is complete, the team translates your requirements into concrete designs — interface layouts, user flows, feature lists, and technical decisions.

This is your last clear opportunity to shape the product before development begins. Changes made during design cost almost nothing. Changes made once development is underway cost significantly more.

What you should do:

• Review designs promptly — delays here push the whole timeline back
• React to the actual design, not to what you expected to see: does this reflect how your team will really use it?
• Point out anything that does not match how the business actually works
• Raise questions even if you are not sure they matter — over-communicating here is always the right call
• Make clear decisions when asked: if the team presents two approaches, give them a direct answer

Do not approve something just because it looks reasonable on screen. Ask to be walked through the user journey as if you were the person doing the job every day.

During development: stay engaged but do not redesign

Development is where the team does most of the heavy lifting — but your role does not disappear.

You will typically be shown work-in-progress demos every one to two weeks. These are not just status updates. They are checkpoints where you can catch problems early, when fixing them is still relatively cheap.

What you should do:

• Actually use the test environment — do not just glance at a screenshot or video
• Test the scenarios that matter most to your business: the common paths and the awkward edge cases
• Answer questions from the team promptly — a delayed answer can stall the whole team for days
• If you discover something needs to change, say so immediately — and understand that scope changes carry a cost in time and budget

What you should not do:

• Add new requirements without discussing the impact — every addition shifts something else
• Stay silent about concerns to avoid seeming difficult
• Assume the team will figure out something you have not told them

One practical rule: if you see something that does not look right, say something that day. Not next week.

During testing (UAT): this is your responsibility

User Acceptance Testing — where you and your team verify the system before it goes live — is not a formality. It is a critical quality check that only you can carry out.

The development team tests for technical correctness: does the system behave as specified? UAT tests for business correctness: does the system actually work the way your business needs it to work? These are two different questions, and only you can answer the second one.

What to focus on:

• The processes your team will carry out every single day — test these thoroughly and repeatedly
• Exceptions and edge cases that you know happen in real operations
• Data integrity: if you are migrating from an existing system, check that key records have transferred correctly
• The experience for different user types — what a manager sees may be very different from what a field worker or a customer sees

Take notes on everything that does not work as expected. Categorise by severity: what must be fixed before go-live, what should be addressed soon after, and what can wait.

During launch: lead the change management internally

Launch day tends to feel like the development team's moment. But the internal change management is entirely in your hands.

A technically excellent system can fail in adoption if your people are not ready for it. The development team can assist with training materials and documentation, but they cannot change your organisation's habits or culture. That is your job as a leader.

What you should do:

• Communicate to your team well in advance: what is changing, when, and why it matters
• Identify internal champions — people who will help their colleagues learn the new system and stay positive about the transition
• Run training before go-live, not the day of
• Plan for a period of reduced productivity while people adjust — this is entirely normal and worth anticipating in advance
• Set up a clear support path for the first few weeks: who does a team member contact when something breaks or does not behave as expected?

The smoother the internal change management, the faster you will realise the returns you expected from the investment.

After launch: keep someone in charge

This is the stage most often neglected — and the one that ultimately determines whether your software becomes a lasting business asset or starts to drift.

Every software system needs an internal owner: someone responsible for the relationship with the development partner, for collecting and prioritising feedback from users, and for making sure the system keeps serving the business as the business changes.

What this looks like in practice:

• A designated internal person who manages the development relationship
• A simple way for team members to report issues or suggest improvements
• Regular check-ins with your development partner — even quarterly — to review what has come up and agree on what to address next
• A realistic, standing budget for ongoing maintenance and incremental development — not a new negotiation every time something comes up

The businesses that get the most from their software investment are the ones that treat it as a living product: something that grows and adapts with the business, not a project that was completed, closed, and filed away.

---

Thinking about commissioning software for the first time — or trying to improve how an existing project is going? Talk to us — we will be direct about what the process looks like and what we will need from you.