Custom software
for the way you work.
Custom software is built around one business and one way of working, so the decisions made before any code is written matter as much as the code. This hub collects what we have written on those decisions: how to brief a developer, how to read a quote, who owns the result and how to test it before you accept it.
Our custom software
services.
Each service has its own page with what is included and common questions.
Custom Systems
Bespoke business systems for the processes off-the-shelf software does not fit: bookings, jobs, approvals and more.
View service
Consulting
Architecture reviews, technical strategy and technology roadmaps that turn business goals into a plan you can act on.
View serviceStart with the guides, then look at the services if you want to talk about your own project.
14 guides on
custom software.
Invoicing system or spreadsheet: when to switch
A spreadsheet works until it does not. The signs you need an invoicing system: duplicate numbers, late payments, VAT errors and no view of who owes you.
APIs explained for business owners: how your systems talk to each other
An API lets one system ask another for information or send it an instruction. What that means for connecting your shop, CRM and accounting software.
Build or buy software: how to decide
Buying is faster and cheaper to start. Building fits unusual processes and avoids per seat fees. A clear way to compare the two over three years.
How to brief a developer so you get what you meant
A good brief states the problem, the users, what success looks like and what is out of scope. A one page structure that prevents most misunderstandings.
How to choose a software development partner in another country
What to check before you hire a remote software team in another country: communication, ownership, references, process and how they handle problems.
Software outsourcing risks and how to reduce them
The common risks of outsourcing software, from unclear scope to lost knowledge, and the simple habits that keep a project under your control.
Fixed price or time and materials: which suits your software project?
Fixed price suits a clear scope. Time and materials suits work that will change as you learn. How each works and how to choose between them.
How to write a software requirements document that developers can use
A short, clear requirements document saves time and money. What to include: the problem, users, must have features, rules, integrations and success measures.
What affects how long a software project takes
Scope, decisions, feedback speed, integrations and testing set the timeline more than the amount of code. How to keep a project moving.
Who owns the code? What to agree before a software project
Ownership of code, data and designs should be written down before work starts. The points to settle with any developer, and when to ask a lawyer.
How to review a software quote before you accept it
A good quote lists what is included, what is not, how changes are handled and what happens at the end. Questions to ask before you say yes.
User acceptance testing: how to check software before you accept it
Before you accept new software, test it with real tasks. A simple plan for user acceptance testing: who tests, what they test and how problems are tracked.
When to move from a spreadsheet to a database
Spreadsheets are flexible but fragile. The signs that you have outgrown one: several editors, duplicate data, broken formulas and no history of changes.
An online booking system for a small business: what to look for
Online booking saves phone calls and no shows. What to look for: availability rules, reminders, payments, calendar sync and a simple way to change bookings.
When is custom software better than an off the shelf product?
When your process is unusual, when per user fees grow faster than your team, or when the system must connect to many others. Our build or buy guide compares them over three years.
How do I start a custom software project?
Write down the problem, who will use the system and what success looks like, then talk to a developer. A short brief and real examples of your forms and spreadsheets are enough to get a useful first conversation.
Talk to us about your project.
Tell us what you need and we email you a detailed quote, usually within one business day.