How to Commission Bespoke Software: 5 Smart, Proven Steps
Commission bespoke software with confidence. This 5-stage guide shows small business owners how to scope, quote, build and launch custom software smoothly.
Commissioning bespoke software for the first time is a bit like commissioning an architect to extend your house. You know roughly what you want. You have a sense of what you can spend. But you’ve never done it before, you’re not entirely sure what the process looks like, and there’s a nagging worry that you might end up with something that doesn’t quite match what you had in mind, at a cost that exceeded what you planned.
The worry is understandable. The software development industry has a mixed track record, particularly with smaller clients who don’t have experience commissioning technical work. Projects that run over budget, deliverables that don’t match expectations, and relationships that turn adversarial over scope disputes are common enough that healthy scepticism is warranted.
But bespoke software projects go wrong for identifiable reasons, and most of them are avoidable with the right approach, the right partner, and a clear understanding of what you’re signing up for. This article demystifies how to commission bespoke software for a small business: what the process actually involves, what to expect at each of the five stages, how to protect yourself, and how to make the most of the relationship.
Table of Contents #
Why Bespoke Software Projects Go Wrong #
Understanding the failure modes is the best starting point for avoiding them.
Poorly defined scope. The most common cause of budget overruns and disappointment in bespoke software projects is a specification that wasn’t clear enough at the start. When the client has a broad idea and the developer makes assumptions to fill the gaps, those assumptions are often wrong. Reworking completed software is expensive.
Scope creep. Related but distinct: the project starts with a clear scope, then requirements gradually expand over the course of the build. Each individual change seems small. Cumulatively, they can double the project size.
Communication failures. Technical developers and non-technical clients sometimes struggle to communicate clearly. A developer who doesn’t translate technical decisions into plain language, and a client who doesn’t ask questions when they don’t understand something, can end up delivering and receiving very different things.
Mismatched expectations about process. Clients who expect a finished product to appear at the end of a defined period, and developers who build iteratively and expect client input throughout, are set up for frustration.
Wrong partner. A developer whose expertise, working style, or communication approach doesn’t suit your project is a problem that no amount of good process will fully fix.
None of these are inevitable. They’re predictable. A good commissioning process addresses each one directly.
The Bespoke Software Development Process at a Glance #
Before getting into the detail, it’s worth seeing the shape of the journey. The bespoke software development process for a small business breaks down into five distinct stages, each with its own purpose, deliverables, and decision points.
- Discovery and scoping. Conversations and a written specification.
- Quoting and agreement. A clear price tied to a clear scope, with sensible payment terms.
- Build and review. Iterative delivery with you in the loop throughout.
- Testing and delivery. Acceptance testing on your side, fixes before final sign-off.
- Launch and after. Going live, post-launch support, and a plan for ongoing maintenance.
Each stage is short to describe and longer to do well. The sections below walk through each one in turn, with the things you should provide, the things you should expect, and the small details that quietly decide whether a project lands smoothly or wobbles.
Stage One: Discovery and Scoping #
A good bespoke software engagement begins not with code, but with conversation.
The discovery stage is where a developer (or development team) works with you to fully understand what you need, why you need it, and what success looks like. This involves mapping your existing process, understanding the data involved, identifying the users of the system and what they need to do, and establishing the constraints. Constraints typically include budget, timeline, integration requirements, and technical environment.
From this, a specification is produced: a document that describes, in clear terms, what will be built. This is your protection. A well-written specification means that both parties have agreed, in advance, on what the project delivers. Disagreements about whether something was in scope become easier to resolve because the answer is in the document.
What you should provide at this stage:
- A clear description of the problem you’re trying to solve (not necessarily the solution, that’s the developer’s job)
- Details of your existing process and tools
- Any specific constraints (must integrate with X, must be accessible on mobile, must be hosted in the UK)
- A realistic sense of your budget range
What a good developer will provide:
- Questions that surface requirements you hadn’t considered
- Honest feedback if your expectations aren’t aligned with your budget
- A clear specification document before any agreement is signed
If your project will handle personal data, this is also the stage to flag it. UK data protection rules apply from the moment the system is designed, and the Information Commissioner’s Office publishes practical guidance on what compliance looks like for small businesses. A good developer will bake the relevant requirements into the specification rather than retrofitting them later, which is faster, cheaper, and considerably less risky.
Stage Two: Quoting and Agreement #
Once the scope is clear, you’ll receive a quote. A few things to understand about quotes for bespoke software:
Fixed-price quotes protect you, if the scope is clear. A fixed price for a well-defined scope is the most client-friendly structure. It means you know what you’re spending before work begins, and cost overruns are the developer’s problem rather than yours.
Vague scope makes fixed prices misleading. If the specification has gaps, a fixed price quote will either be padded with contingency (making it more expensive than necessary) or won’t hold in practice (leading to scope disputes). Good specification work upfront pays for itself in quote accuracy.
Hourly rates suit exploratory work. For projects where the requirements genuinely can’t be pinned down in advance (complex integrations, early-stage product discovery), an hourly rate with a cap is sometimes the more honest structure. It means work isn’t padded with contingency you might not need.
Staged payments are standard and sensible. A payment structure tied to delivery milestones (deposit on signature, payment on delivery of defined stages, final payment on completion) aligns incentives properly. Be cautious of any arrangement that requires full payment upfront.
Bespoke Software Cost: What’s Reasonable #
The honest answer is that bespoke software cost varies widely depending on complexity. A focused internal tool or a simple API integration might cost a few thousand pounds. A larger custom platform with multiple users, complex logic, and several integrations sits in the low five figures or higher. The right benchmark isn’t what other clients have paid for other projects; it’s whether the quote is proportionate to the value the software will deliver to your business.
When comparing quotes, pay attention to what’s included beyond the build itself. Hosting, deployment, post-launch fixes, and documentation can each add or remove significant cost. A cheaper headline quote that excludes these can end up more expensive than a higher quote that bundles them in.
What you should check before signing:
- Is the scope described clearly enough that you’d both agree on whether something is included?
- Are the payment terms tied to delivery milestones?
- What happens if requirements need to change during the build?
- Who owns the code and intellectual property at the end?
- What support is provided after delivery?
The IP question is particularly worth pinning down. The UK government’s intellectual property overview explains how copyright and ownership work for commissioned software, and it’s the kind of detail that’s easy to overlook in the excitement of getting a project moving. Make sure your contract is explicit about who owns the codebase, the design assets, and any associated IP at handover.
Stage Three: Build and Review #
Once the project is underway, a well-run bespoke software build involves the client more than many first-timers expect.
Modern software development works best iteratively: building in stages, reviewing with the client at each stage, and incorporating feedback before moving on. This is better than the alternative (building everything and revealing it at the end) because it catches misunderstandings early, when they’re cheap to fix, rather than late, when they’re expensive.
What you should do during the build:
Review each stage promptly when asked. Developers working on your project maintain context about the codebase in their head, and long delays between reviews break that context and slow the project. If you’ve been asked to review something, prioritising that review protects your timeline.
Be specific in your feedback. “This isn’t quite right” is harder to act on than “the button should be on the left, and the error message should say X instead of Y.” The more precisely you can describe what needs to change, the faster and more accurately it will be addressed.
Separate “must change” from “nice to change.” Not every piece of feedback needs to be actioned before moving on. Distinguishing between changes that are essential and those that would be nice helps keep the project moving and prevents the build from drifting into perfectionism.
Flag changes to requirements immediately. If you realise during the build that a requirement has changed or something was missing from the specification, flag it as soon as you notice. Don’t wait until delivery. Change requests mid-project can be accommodated, but they’re easier to handle when raised early.
What you should expect from a good developer during the build:
Regular updates on progress, even when nothing is ready to review. Early flagging of any technical issues that might affect scope or timeline. Plain-language explanations of technical decisions that affect you. And proactive questions when they encounter ambiguity rather than making assumptions.
Stage Four: Testing and Delivery #
Before anything goes live, testing matters. It’s a collaborative process.
The developer will conduct their own technical testing. But user acceptance testing (checking that the software does what you need it to do, in the way you need to do it) is your responsibility. This means actually using the software, with real or realistic data, following your real workflows, and verifying that the behaviour matches what was specified.
Common things to check during acceptance testing:
- Does the software handle your most common use cases correctly?
- What happens when something goes wrong (an error, an unexpected input, a missing field)? Does it fail gracefully?
- Is the software fast enough for how you’ll use it?
- Are there any edge cases in your process that aren’t covered?
Any issues found during acceptance testing should be documented clearly and resolved before final delivery and final payment. This is your last opportunity to get corrections made within the original project scope.
A short acceptance period (typically one to two weeks, depending on complexity) gives you time to use the software in your real working environment without keeping the project open indefinitely. Agreeing the length of this period in advance avoids ambiguity about when the project formally ends and ongoing support begins.
It’s worth keeping a simple log of issues during acceptance testing. A shared spreadsheet or a project board with each issue tagged as critical, important or minor lets you and the developer agree on what must be fixed before sign-off and what can be picked up later under support.
Stage Five: Launch and After #
Going live is not the end of the relationship with a good development partner.
The weeks after launch typically surface a handful of issues that didn’t appear during testing: edge cases encountered in real use, small adjustments needed as users interact with the system for the first time, and occasionally more significant issues that require prompt attention. A good development partner is available and responsive during this period.
Beyond the initial launch period, ongoing maintenance and support becomes relevant for most bespoke software. As discussed in our article on development retainers, an ongoing support arrangement ensures your software stays healthy as the platforms it connects to evolve, your requirements change, and improvements accumulate over time.
This is also the point where the value of bespoke software starts compounding. The first version solves a defined problem. The second iteration, informed by real use, refines that solution. The third adds capabilities you didn’t know you needed when you started. A piece of software you own, paired with a partner who knows it well, becomes a long-term operational asset rather than a one-off purchase.
Plan a brief review at thirty days post-launch and again at ninety days. The first catches the immediate snags. The second catches the things that only become visible once the system has been used in anger across a full month-end or sales cycle.
Choosing a Partner When You Commission Bespoke Software #
The single biggest determinant of how a project goes is who you choose to commission bespoke software with. The right partner makes a complex process feel manageable. The wrong one makes a simple process feel impossible.
A few practical signals worth weighing:
Do they specialise in your kind of project? A developer whose previous work has been enterprise platforms is overqualified and probably overpriced for a small business automation. A freelancer who has only ever built simple WordPress sites is underqualified for a complex integration. Look for proven experience at roughly the scale and complexity of what you need built.
Do they ask good questions in the first conversation? A partner who jumps straight to a quote without understanding your problem is selling you something off the shelf. A partner who pushes back gently on assumptions, surfaces requirements you hadn’t considered, and is willing to tell you when bespoke software isn’t actually the right answer is the one to keep talking to.
Are they comfortable explaining things in plain English? This matters more than it might seem. The developer who can’t translate technical concepts into language a non-technical owner can understand will struggle to communicate during the build, and you’ll struggle to make informed decisions.
Can they show you work that’s been live for a while? Anyone can demo something on launch day. The real test of a developer is software that’s still running smoothly twelve or eighteen months after handover. Ask for examples and references from clients who have worked with them long-term.
What does their support arrangement look like after launch? A developer who treats the launch as the end of the relationship is one to be cautious about. The first few weeks of real-world use almost always surface adjustments that need handling, and the long-term health of custom software requires ongoing attention.
The British Computer Society maintains a published code of conduct for IT professionals that’s worth keeping in mind as a baseline expectation. It isn’t a guarantee of quality, but a partner whose working practices align with it is probably more dependable than one whose don’t.
A note on size: small does not mean junior. Some of the best partners for SME work are deliberately small studios or experienced solo developers who chose that scale because it lets them work directly with clients rather than through layers of account management. The right size of partner is one whose typical client looks roughly like you.
Custom Software for Small Business Owners: Common Pitfalls #
Even with the right partner and a clean process, there are a handful of avoidable mistakes that small business owners specifically tend to make when commissioning their first piece of custom software for a small business context. Knowing them in advance is half the battle.
Trying to specify the solution rather than the problem. It’s tempting to arrive with a fully-formed idea of what the software should look like. Resist that urge in the discovery conversation. Describe the problem and the outcome you want, and let the developer recommend the implementation. They’ll often suggest a simpler, cheaper, or more reliable approach than the one you had in mind.
Cutting documentation to save money. Documentation feels like overhead when you’re trying to keep costs down, but it’s the artefact that lets a different developer pick up the codebase later, or that lets a member of your team understand how the system works. Skipping it makes the software meaningfully more fragile.
Assuming “done” means “finished forever”. Software that connects to other platforms, holds business data, and evolves alongside your operations needs ongoing care. Budgeting for the build but not for the maintenance is one of the most common reasons custom software stops being valuable a year or two after launch.
Choosing the cheapest quote without comparing scope. Two quotes for the same project can differ by a factor of three for entirely legitimate reasons: different inclusions, different levels of testing, different support arrangements, different ownership terms. Compare what’s actually being delivered, not just the headline number.
Underestimating your own time. A bespoke project needs your input throughout: discovery conversations, review sessions, acceptance testing, decisions about edge cases. Plan for that time, or the project will either slow down waiting for you or be delivered without the input it needed.
Treating the developer as an order-taker. The most successful projects are collaborations. Treating your developer as a contractor who simply executes your instructions misses the value they bring as a thinking partner. Their best ideas often emerge in conversation, not in a brief.
Working With PMG Software Services #
PMG Software Services Ltd follows a structured process designed to make commissioning bespoke software as clear and low-risk as possible for small business clients.
It begins with a free consultation. No commitment, no pressure. The goal is to understand your situation, what you’re trying to achieve, and whether a bespoke solution is genuinely the right answer (sometimes it isn’t, and honesty about that is part of the service).
If a project makes sense, a discovery and scoping process produces a clear specification. This is the foundation everything else is built on, and PMG invests proper time in getting it right.
A fixed-price quote follows, tied to a defined scope, with staged payments against delivery milestones. No surprises.
Delivery is staged, with review points built in so you’re seeing progress throughout the build rather than waiting for a big reveal. Communication is in plain English throughout.
Support after delivery is available through a flexible retainer arrangement, giving you a development partner who knows your systems and can keep them healthy over time.
This process applies whether you’re commissioning automation workflows, API integrations, bespoke internal tools, custom dashboards, a knowledge base, or a white label SaaS product.
The Bottom Line #
Commissioning bespoke software doesn’t have to be the anxiety-inducing experience it sometimes is. With the right partner, a clear process, and a realistic understanding of what’s involved, it’s a straightforward and genuinely valuable way to solve real business problems.
The businesses that get the most from commissioning bespoke software are the ones that come in with a clear problem to solve, engage actively during the build, and treat the development relationship as a long-term partnership rather than a one-off transaction. Done well, the result is a piece of software you own outright, that fits your business exactly, and that keeps paying back for years.
Book a free consultation with PMG Software Services to find out what commissioning bespoke software would look like for your specific situation.
Frequently Asked Questions #
How do I know if my idea is feasible?
A good developer will tell you honestly during the scoping process. If something isn’t technically feasible, or isn’t feasible within your budget, you need to know before work begins, not after.
What if I don’t know exactly what I want?
That’s fine, and common. The discovery process is designed for exactly this situation. You don’t need to arrive with a complete specification. You need to be able to describe the problem you’re trying to solve.
How do I protect myself if the project doesn’t go to plan?
Staged payments tied to delivery milestones are your primary protection. Don’t pay in full upfront. Ensure the specification is clear before work begins. Choose a developer who communicates proactively rather than one who disappears for weeks and reappears with something that doesn’t match expectations.
Who owns the code after the project is complete?
This should be explicitly addressed in your agreement. With PMG, the client owns the intellectual property and codebase at the end of the project.
Can I change my mind about what I want during the build?
Requirements change. It’s normal. The key is to raise changes early, understand that changes to scope may affect cost and timeline, and agree formally on any changes before they’re implemented.
What if the software needs updating after delivery?
All software needs maintenance and iteration over time. An ongoing support retainer is the most cost-effective way to handle this for small businesses, keeping your systems healthy without the cost of an in-house developer.
How long does it take to commission bespoke software from start to finish?
A small, focused project might go from first conversation to launch in four to six weeks. A larger project with multiple stages and integrations can take three to six months. The discovery stage usually gives you a realistic timeline before you commit.
Is bespoke software cost-effective compared to off-the-shelf SaaS?
For small, simple needs, off-the-shelf often wins. For workflows specific to your business, ones that span multiple tools, or ones where subscription costs add up over time, bespoke software is frequently the cheaper option over a three to five year horizon, particularly because you own the result.
Can I commission bespoke software in stages rather than all at once?
Yes, and for many small businesses this is the smarter approach. Commission a focused first version that solves the most pressing problem, get it live, and let real use inform what to build next. This keeps the upfront cost manageable and ensures each subsequent stage is shaped by evidence rather than assumption.
Suggested CTA Block (for the end of the article in WordPress) #
Thinking about commissioning your first piece of bespoke software?
A 30-minute conversation is usually enough to know whether it’s the right move for your business, what a realistic scope and budget would look like, and what the next sensible step is. There’s no obligation and no pressure.
PMG Software Services Ltd provides bespoke software development for solopreneurs and small businesses, from initial consultation through to delivery and ongoing support. Visit pmgss.ltd to book a free consultation.