Bespoke Software Development
It started as a way of tracking something. Then it acquired formulas, then tabs, then a second version for the branch office, then colour coding that only one person fully understands. It now runs a meaningful part of the operation, it exists in six slightly different copies, and if the person who built it left tomorrow you would have a genuine problem.
Discovery on site where possible, watching the work happen rather than reading the process document · Process mapping written down and shown back to you before anything is priced · A written scope with a fixed price for phase one, a timeline, and an explicit list of exclusions · Interface designs and a clickable prototype of the main screens before development starts
On this page
- When does a spreadsheet become a business risk?
- What if only one of those is true?
- What kinds of software do we build?
- Should you build bespoke software or buy off the shelf?
- What should you ask any software company before you sign?
- What scale of software build are you looking at?
- What actually moves the price of a software project?
- What would we tell you not to build?
- What does it take to make two systems talk to each other?
- What do reporting and dashboards actually give you?
- Who owns the software, and how is it secured and supported?
- What happens if you want to move to another developer?
- What have we built, and where?
- Do you work with businesses outside the West Midlands?
When does a spreadsheet become a business risk?
When losing one person, or one file, would stop part of the operation. The tipping point is rarely dramatic — it usually looks like one of the six patterns below. If two or three of them are true of your business, there is probably a case for bespoke software.
- The same information gets typed in three times. Once into the quote, once into the job sheet, once into the accounts. Every re-entry is a chance to get it wrong, and somebody spends hours a week doing it.
- Nobody can answer a simple question quickly. How many jobs are open. What the margin was on that contract. Which customers have not ordered since spring. The data exists, spread across systems that do not talk, and answering takes someone half a day with an export.
- The process lives in one person's head. They know which spreadsheet is current and which supplier needs the special treatment. Holidays are stressful. Their resignation would be a crisis.
- Off-the-shelf nearly works. Each product does 70% of what you need and forces an awkward workaround for the rest. You are considering changing how you work to suit the software, which is the wrong way round.
- You are paying per seat for capability you do not use. Licences across a growing team, year after year, for a fraction of the features. This is also the most common reason businesses ask us about a CRM built around their own pipeline.
- Growth has hit a ceiling made of admin. Taking on 30% more work would mean taking on another administrator, and the maths has stopped working.
What if only one of those is true?
Then there may not be a case, and we will tell you. A system nobody needed is a bad advertisement sitting in someone's office for years, which is a worse outcome for us than a project we did not win.
What kinds of software do we build?
Eight categories, all of them shaped around an existing operation rather than sold as a product. Most projects combine two or three of them — a business system with a customer portal attached, or a reporting layer over an integration.
- Internal business systems. Job and order management, scheduling, resource planning, stock, service records, compliance and document management. The systems that run the operation rather than the ones that market it.
- Customer and supplier portals. Somewhere your customers can check an order, download a document, submit a request or approve a quote without emailing someone. Usually pays for itself in reduced inbound admin faster than anything else on this list, and it is the most common starting point for a browser-based application people log into.
- Workflow and approval systems. Multi-step processes with rules, permissions, sign-offs and an audit trail. Anything currently held together by an email chain and a shared folder.
- Reporting and dashboards. Live figures pulled from the systems that hold them, presented as the questions your managers actually ask, refreshed automatically instead of assembled by hand each month.
- Integration between systems you already run. Making your website talk to your accounts package, your production system talk to your stock, your CRM talk to your telephony. Often the fastest way to remove real cost without replacing anything.
- API development. Building an API so your systems, your partners or your customers can connect to your data securely. Also consuming other people's APIs when the documentation is poor or absent, which is more common than vendors admit.
- Legacy replacement. The Access database from 2009. The bespoke system whose developer disappeared. The VB application nobody dares update. Replacing these carefully, in phases, without stopping the business.
- Data migration. Getting years of accumulated information out of the old system and into the new one, cleaned, de-duplicated and reconciled so you can verify it before go-live.
Should you build bespoke software or buy off the shelf?
Buy off the shelf when your process is broadly standard, you need it working in weeks, or the scope is too small for bespoke to earn its keep. Build bespoke when you have already tried products and are working around all of them. We build bespoke software, so treat our view with appropriate scepticism — and then read the row where we argue against ourselves.
| Route | When it is the right call |
|---|---|
| Buy off the shelf | Your process is broadly standard — accounting, payroll, general CRM, email marketing — and the products are excellent. You need it working in weeks. The scope is small enough that bespoke would be too thin to be useful, and we will tell you when you are there. The requirement is still moving, and building around an unsettled process is expensive learning. Or a mature product exists for your specific industry with features that would take years to replicate. |
| Build bespoke | Your process is genuinely distinctive and is part of why customers choose you — do not flatten a competitive advantage to fit a product. You have tried products and are working around all of them. The value is in joining systems that do not otherwise connect. Per-seat licensing across a growing team has become a significant annual cost. The data is strategically important and you want it in your own database. Or compliance, security and data residency requirements rule out the general options. |
| The middle path | Keep the off-the-shelf products for the standard functions and build bespoke only for the part that is genuinely yours, connected by integration. That is often the cheapest good answer, and we recommend it more often than a full custom build — sometimes with nothing more than an integration layer behind your existing website. |
What should you ask any software company before you sign?
Ten questions, and the answers matter more than the portfolio. Ask them of us and of everyone else you are speaking to. A good supplier answers all ten without hedging. The ones worth worrying about change the subject, produce a number instead, or tell you it is covered in the contract.
- “Can you show me a system you built that is in daily use, and let me click around it?” A good answer is a screen share, or an introduction to the client who owns it. A case study PDF is a description of working software, not evidence of it.
- “Where will I test this before it goes live?” A good answer names a staging environment holding a copy of your real data. If the answer is that you will test it in production, or that testing is your job after launch, you have learned what you needed to.
- “Who owns the source code and the data, and what happens the day I stop paying?” A good answer is that you own both on final payment, with the repository transferred. A licence back to your own system is a different product being sold under the same word.
- “How is it secured, who can see the data, and where are the backups?” A good answer covers role-based access, encryption in transit and at rest, and a restore somebody has actually performed — rather than a backup that exists and has never been read back.
- “Who writes the code, and will I meet them?” A good answer introduces the engineers by name. Subcontracting is not a scandal and plenty of good work is done that way, but it belongs in the conversation before you sign, not after the first invoice — the same judgement runs through the trade-offs between hiring in-house and buying the work in.
- “How will I see progress?” A good answer is something you can log into at a fixed interval, not a status email. Any arrangement that leaves you waiting for a reveal is one where problems stay hidden until they are expensive to fix.
- “What does support cost once it is live, and what does it cover?” A good answer separates three things that get quietly bundled: fixing a defect, patching dependencies and building something new. Ask which of the three you are actually buying.
- “Can I have the quote itemised?” A good answer breaks the work into parts you can recognise, question and drop. One number for everything cannot be compared against another supplier, which is usually why it is presented that way — it is worth understanding how a bespoke software quote is put together before you accept one.
- “What does leaving look like?” A good answer is a list of things handed over — repository, schema, credentials, hosting accounts — not a reassurance about the relationship. Ask for that list in writing at proposal stage and check it against what you receive.
- “What would you tell me not to build?” A good answer is specific and costs the supplier money. If everything you describe is a great idea and nothing gets pushed back on, you are talking to a sales process rather than to a developer.
What scale of software build are you looking at?
Cost follows how much of your operation the system has to hold. The drivers are the number of distinct processes it covers, how many systems it must integrate with and whether those have usable APIs, how many user roles and permission rules exist, and how clean the data you are migrating turns out to be. The three bands below are how most buyers place themselves before the first call.
| Scope | Typically |
|---|---|
| Focused tool | One clear process. A job tracker, a booking system, a reporting dashboard, an integration between two systems. Six to ten weeks. |
| Business system | Multiple connected processes, user roles, several integrations, data migration from an existing system. Three to five months. The most common project. |
| Platform | Multi-site or multi-team, customer-facing portal, complex integration with production or finance systems. Scoped individually, because no two are alike. |
What actually moves the price of a software project?
Six things, and the last one is the biggest — it is also the one you control. Everything else on this list we can estimate; how settled your requirement is before we start decides whether the estimate survives contact with the build.
- The number of distinct processes the system has to handle
- How many systems it must integrate with, and whether those have usable APIs
- The state of your existing data, which is almost always messier than anyone expects
- How many user roles and permission rules exist
- Whether it must work offline, or on a phone in the field — a design decision made at the start rather than a feature added later, which is why mobile builds are scoped separately
- How much of the requirement is settled before we start
What would we tell you not to build?
A system to replace a spreadsheet that only two people open. A feature nobody has asked for twice. A rebuild, when the real problem is one broken integration. A mobile app, when what you actually have is a website with a login. Those four come up often enough that we now raise them before anyone writes a scope.
The spreadsheet one is a headcount test. If two people maintain it, both of them understand it, and it changes twice a year, software will make their week worse and your year more expensive — the cost is never only the build, it is the administration the system then needs for as long as it exists. The feature nobody has asked for twice is the same argument in miniature. If it was described once in a meeting and has not come up since, it is a preference rather than a requirement, and it should wait until the system is in daily use and the people using it can tell you what is genuinely missing. Features that come out of real use get used; features that come out of imagination sit on a menu.
The rebuild is the expensive mistake. A business concludes the whole system has failed when what has actually failed is one integration that drops records overnight, or one report nobody has maintained since the person who wrote it left. Repairing that costs a fraction of the money and is almost always the better use of it, which is worth weighing against what a full bespoke build is priced from. The app is the other one. If your users sit at desks on office wifi and what they need is a login and a form, they need a browser page. A phone in a van with no signal is a real reason for an app; a preference for the word is not, and that is worth settling before anyone argues about whether it should be native or cross-platform.
The point
Repairing that costs a fraction of the money and is almost always the better use of it, which is worth weighing against what a full bespoke build is priced from.
What does it take to make two systems talk to each other?
It takes an integration: a piece of software that moves data between two systems on a schedule or the moment something happens, handles the cases where one of them is down, and tells somebody when it cannot. Most businesses do this by hand without calling it anything — somebody exports a file on a Friday and types it into the other system on a Monday.
The work is rarely the connection itself. It is the disagreement between the two systems: one calls it a customer, the other calls it an account; one allows a blank postcode, the other refuses the record; one updated the address last week and the other did not. Deciding which system is the authority for each field is the part that takes the meetings, and it is the part that decides whether the integration is trusted six months later.
Where a system has a documented API, the connection is straightforward and the time goes into mapping and error handling. Where it has none — older accounting packages, industry-specific tools, anything with a desktop-only interface — the route is a scheduled file exchange or a direct database read, which works but needs more care. We check what is possible before quoting, because the answer changes the shape of the project. Integration is usually why a custom CRM is worth building at all, and it is the same work behind a browser-based business application.
The point
Where a system has a documented API, the connection is straightforward and the time goes into mapping and error handling.
What do reporting and dashboards actually give you?
They give you the numbers you run the business on, from the systems that already hold them, without anybody rebuilding a spreadsheet every month. That is the whole promise, and it is worth less than people expect if the underlying data is inconsistent — which is why reporting is usually the last thing built rather than the first.
A useful dashboard answers questions somebody actually asks in a meeting. Which jobs are late and why. Which customers have not ordered since the spring. What the pipeline is worth by stage, and what it was worth this time last quarter. Margin by product line rather than revenue by product line, which is the number most systems show and the one that misleads. We start by writing down the questions, because a dashboard built from available fields rather than real questions ends up admired once and never opened again.
Practically that means scheduled reports that arrive by email whether or not anyone logs in, role-based views so a branch manager sees their branch, exports that go into a board pack without reformatting, and alerts on the handful of things worth interrupting somebody for. Where the numbers need to combine marketing spend with what it produced, the reporting and the campaigns being measured are better designed together than joined up afterwards.
The point
Where the numbers need to combine marketing spend with what it produced, the reporting and the campaigns being measured are better designed together than joined up afterwards.
Who owns the software, and how is it secured and supported?
You own it. On final payment the source code, the database schema and the designs are yours and we hand over the repository. We do not licence your own system back to you, and there is no release fee.
- UK or EU hosting as standard. If you have data-residency requirements, raise them at scoping and we will design to them.
- Security is built in. Role-based access control, encrypted data at rest and in transit, audit logging, dependency monitoring and regular patching — decisions made at the architecture stage, not retrofitted after a penetration test.
- GDPR by design. Lawful basis recorded, retention rules configurable, subject access and erasure handled through the interface rather than by a developer running queries.
- Support after launch, either on a retainer or a day rate. Software is never finished, and the version that goes live is the beginning of the useful conversation rather than the end of the project.
- If you leave, you take everything and we help hand over. Standard technologies, documented code, no proprietary lock-in.
- If what you are building is a product rather than an internal system, ownership works the same way — see how we handle a SaaS first release.
What happens if you want to move to another developer?
You take the system with you. What follows is a list of things handed over rather than a promise about how we behave, and you can check each item off before the final invoice is paid. Most of it already sits in accounts registered to you, so there is nothing for us to release.
- The repository, with its full commit history. Not a zip of the current files — the branches, the commit messages and the issue trail, transferred to an account in your name, so the next developer can see why something was built the way it was.
- The database schema and a full data export. Structure and contents together, in a standard format another developer can restore, rather than a spreadsheet of whichever screen you happened to be looking at.
- Environment variables and third-party credentials. API keys, service accounts, webhook secrets and the payment, email and storage providers the system depends on, listed with what each one connects to and what stops working if it is rotated.
- Deployment and build documentation. How the application is built, where it is deployed, what runs on a schedule and what has to be true for it to start — written for a developer who has never seen it before.
- The domain and the hosting accounts, in your name. Registered to you from the outset wherever we set them up, the same way we do it for a site we build and host for you, so there is no account to hand back and no release fee to negotiate.
- The interface designs, the prototype and the process map the build was scoped from. Between them they explain the decisions the code cannot, which is most of what a new team needs.
- A handover session with the engineers who built it. Useful whoever picks it up next, and the choice itself is worth thinking about — a freelancer, another agency and an in-house hire fail in different ways on an inherited codebase.
What have we built, and where?
We have built websites, e-commerce and business systems for clients including Delta Hospital & Research Center, Aama Jewellers, Himalayan Clean Energy, RM Agrotech, Fit and Fine, AOne Biz and Company Services Nepal — across healthcare, retail and jewellery, renewable energy, agriculture and professional services.
Our delivery record is currently international rather than UK-based, and we would rather tell you that plainly than imply a local portfolio we do not yet have. We are building a UK client base now.
What we can do is show you working systems and put you in a room with the engineers who built them, which is worth more than a case study PDF anyway. There is more of it on our work, and the scoping conversation is where you find out whether we are the right people for it.
The point
What we can do is show you working systems and put you in a room with the engineers who built them, which is worth more than a case study PDF anyway.
Do you work with businesses outside the West Midlands?
Yes. The company is registered in Oldbury in the West Midlands, but the work is not tied to a postcode. Discovery happens on site where possible, because watching the work happen is worth the travel. Everything after it — design, sprints, testing, training — runs through a staging environment you log into from wherever you are.
Two things are worth saying plainly rather than leaving you to assume them. Our delivery record so far is international rather than UK-based, which you can check against the systems we have already put into daily use instead of taking on trust. And where distance makes on-site discovery impractical, we say so and structure it as a remote session, rather than charging for travel that adds nothing. If proximity matters to how you buy, raise it on the first scoping conversation and we will give you a straight answer about whether we are the right people.
The point
Everything after it — design, sprints, testing, training — runs through a staging environment you log into from wherever you are.
How We Work
Discovery
On site where possible. We watch the work happen and talk to the people who will use the system, not only the people paying for it. The gap between the documented process and the real one is where projects fail.
Scoping and process mapping
We write down what we understood and show it back. Disagreements surface here, on paper, where they cost hours instead of months.
Fixed-price phase one
A written scope, a fixed price, a timeline, and an explicit list of what is excluded. Where the requirement is genuinely unclear, we propose a paid discovery phase rather than pricing a guess — a fixed price on an unclear scope protects nobody.
Design and prototype
Interface designs and a clickable prototype of the main screens before development starts. Changing a prototype takes hours.
Explore Related Services
Aama Jewellers
A modern storefront replacing an outdated site, with a shorter checkout and social campaigns feeding it — built and handed over as one piece of work rather than two suppliers pointing at each other.
View Case StudyFrequently Asked Questions
How much does bespoke software development cost in the UK?
Scope, not headcount. What moves the figure is how many distinct processes the system must handle, how many systems it integrates with and whether those have usable APIs, the state of your existing data, how many user roles and permission rules exist, and how settled the requirement is. Discovery maps all of it, and we quote from that.
Do you offer fixed-price quotes?
Yes, for a defined scope. We fix phase one after discovery and process mapping, because that is the point at which a fixed price means something. We will not fix a price on a vague brief, which only produces a padded number. Where the requirement is unclear we propose a paid discovery phase, whose fee comes off the build.
What information do I need before you can quote?
Less than you think. A description of the problem, a rough sense of who will use the system and how many, which existing systems it must talk to, and any hard deadline. You do not need a specification, because writing one is part of what we do. A spreadsheet and a frustration is a perfectly good starting point.
Will we own the source code and intellectual property?
Yes, on final payment: the source code, the database schema and the designs, with the repository transferred to an account in your name. We do not licence your own system back to you and there is no release fee. Ask every developer you are speaking to the same question, because not all of them answer it this way.
How long does a bespoke software project take?
A focused tool is typically six to ten weeks. A full business system is three to five months. Platforms run longer. Two things move the date more than anything else: how quickly decisions get made on your side, and how clean your existing data turns out to be.
Can you integrate with the systems we already use?
Usually. Xero, Sage, QuickBooks, Microsoft 365 and Google Workspace all have workable APIs. Industry-specific and older systems vary: some have a proper API, some a database we can read, some neither, in which case a scheduled file route may work. Where the integration is the whole point, it belongs in a browser-based application your team logs into.
Can you take over a project another developer started?
Often, yes. We start with a code review and an honest assessment: sometimes the existing work is a sound foundation, sometimes the fastest route is to rebuild. We will tell you which, with reasons, before you commit anything. We have no interest in inheriting a codebase we cannot stand behind.
What happens if our requirements change mid-project?
They will, and that is not a failure. Working in two-week sprints exists precisely so that change is manageable. Small adjustments get absorbed. Anything that materially changes scope gets a written change note with a cost and a timeline impact, agreed before we build it. What we will not do is quietly absorb changes and then present a surprise invoice.
Do you use generative AI to write our software?
We use modern development tooling, including AI-assisted coding, in the same way the industry does — as an accelerator, with every line reviewed by the engineer responsible for it. What we do not do is generate a system and hand it over unexamined. If you have a policy on this, tell us at scoping and we will work to it.
Let's Build Something That Matters.
Tell us what you're trying to achieve and we'll help you find the right solution.