Custom Software Development: A Practical Buyer's Guide
Commissioning custom software for the first time? A plain guide to build vs buy, discovery, pricing models, team shape and what a good software company hands over.
Commissioning custom software is a significant decision, and most people only make it a few times in their career. Proposals from different vendors are hard to compare, the terminology is unfamiliar and the risks are not obvious until something goes wrong.
This guide is written from the other side of the table. We are a software development company with offices in Delaware, Sarajevo and Doha, working with clients in the UK, Germany, Switzerland and Qatar. Here is what we would want a client to know before choosing any partner, including us.
Build or buy?
The cheapest software is software you do not have to build. Before commissioning custom software development, check honestly whether an existing product would do the job. A rough guide:
- Buy when the process is standard (accounting, payroll, basic CRM), when an off-the-shelf tool covers most of your needs, and when the process is not what differentiates you.
- Build when the software is the product you sell, when it encodes a process that gives you an edge, when you need integrations no vendor offers, or when licence costs at your scale exceed the cost of owning it.
- Combine in many cases: buy the commodity parts and build the layer that connects them and carries your specific logic.
A good partner will tell you when not to build. If a vendor never questions whether you need custom software, treat that as a signal.
Start with discovery, not a quote
Any fixed quote produced from a two-page brief is a guess. A short paid discovery phase, typically a few weeks, turns that guess into a plan. It should produce:
- A clear statement of the problem, the users and how success will be measured.
- A prioritised scope, separating what is needed for a first release from what can wait.
- Key user flows and wireframes or a clickable prototype for the riskiest parts.
- A proposed architecture and technology choice, with reasons.
- A delivery plan with milestones and a realistic budget range.
Discovery is also the cheapest moment to find out whether you work well with a team. If communication is difficult during discovery, it will not improve during delivery.
Fixed price or time and materials?
Fixed price works when scope is genuinely well defined and unlikely to change: a clearly specified integration, a migration, a small tool. The vendor carries the estimation risk and prices it in, and any change goes through a change request.
Time and materials works better for products that will evolve as you learn from users, which describes most new software. You pay for the team's time and keep control of priorities. The risk is open-ended spending, which you manage with a budget cap, fortnightly demos, a visible backlog and the right to stop at any milestone.
A common, sensible pattern is fixed-price discovery followed by time-and-materials delivery in agreed phases.
What a good team looks like
The size of the team matters less than its shape. For a typical web or mobile product, a capable core team includes a product or delivery lead who owns communication and priorities, a designer for at least the early phases, two to four engineers covering frontend, backend and mobile as needed, and QA built into the process rather than bolted on at the end.
Ask who will actually work on your project, and whether those people stay for its duration. Senior names in the pitch who disappear after kick-off are a common source of disappointment.
Nearshore delivery for the UK, Germany and Switzerland
Our engineering hub in Sarajevo works in Central European Time, the same time zone as Germany and Switzerland and one hour ahead of the UK. In practice that means full overlap for daily stand-ups, workshops and quick calls, which is the main advantage of nearshore over far-offshore delivery. Travel for kick-offs and workshops is a short flight.
We have delivered for clients in these markets, including a community platform for towns across Germany (Dorfleben) and work within the Volkswagen Group ecosystem for Volkswagen and Škoda. Clients in Germany and Switzerland often have specific expectations around data protection and documentation; GDPR-aware design and clear written handover are part of how we work by default.
Working with clients in Qatar and the Gulf
Our office in Doha supports clients in Qatar and the wider Gulf. Projects there often bring requirements that should be raised in discovery rather than discovered late: Arabic and English interfaces with proper right-to-left layouts, local data residency or hosting preferences, integration with local payment providers and government systems, and a working week that differs from Europe's. With a team on the ground in Doha and engineering in Europe, time-zone overlap is good, and in-person workshops are straightforward to arrange.
What you should own at the end
Whoever you choose, make sure the contract and the working practice give you everything needed to continue without them. A good software development company hands over:
- Source code in a repository you own, from day one, not at the end.
- Infrastructure and accounts (cloud, app stores, domains, third-party services) registered to your organisation.
- Documentation: architecture overview, setup instructions, deployment process and key decisions.
- Automated tests and a CI/CD pipeline, so another team can change the code safely.
- Clear intellectual property terms assigning the work to you.
- A handover period with your in-house team or a new vendor, if you choose to move on.
Red flags when choosing a vendor
Most failed software projects show warning signs early. Be cautious if a vendor:
- Gives a confident fixed price for a large product without discovery.
- Cannot name the people who will work on your project.
- Keeps the code in their own repository until final payment.
- Offers no regular demos of working software, only status reports.
- Agrees with every requirement and never pushes back on scope.
Talk to us
If you are weighing up a custom software project, we are happy to give you an honest view, including when buying is the better option. Read about our custom software development service, see what custom AI development can add, or contact us to arrange a call.