Custom software development services

Custom software or off the shelf: how do you decide?

Build when the process is how you compete or when you intend to sell the software. Buy when the process is the same at every company in your industry. When an existing product does most of it, extend that product instead of replacing it, because building the missing ten percent costs a fraction of building the hundred.

The trap is the middle row of that table, where a product does eighty percent of what you need and the missing twenty is genuinely important. Teams in that position often decide to build everything, and then spend a year rebuilding the eighty percent that already worked. Extending, integrating or scripting around the existing product is almost always cheaper and almost always less satisfying, which is why it gets rejected for reasons that sound technical and are not.

When should you not build custom software?

Do not build when nobody can describe what a good day looks like for the user, when the requirement is a process problem rather than a software one, when the budget covers the build but not two years of running it, or when the thing you want exists and works and you simply dislike the interface.

When the requirement is really a process problem. If three teams disagree about who approves something, software will encode the disagreement rather than resolve it. We have watched a six month build fail because the approval workflow it automated was one that nobody actually followed.

When the budget is for the build only. Software is a running cost, not a purchase. If the money covers delivery with nothing left for the year after, you are buying an asset that will quietly rot. See the cost of ownership section below for realistic figures.

When nobody will own it internally. Every custom system needs a person who answers questions about what it should do. Not a committee, a person. Without one, every decision comes back to the developers, who will make it based on what is easiest.

When you cannot describe the user's day. Not features, the day. Who opens this, at what moment, under what pressure, and what happens if they do not. If that paragraph cannot be written, more discovery is cheaper than more code.

We say this on sales calls and it costs us work. It costs less than a failed project costs both of us.

What do custom software development services cost?

Build cost depends almost entirely on scope, so any figure before a conversation is a guide. The number that gets missed is the running cost: budget roughly 15 to 20 percent of the build each year for maintenance, plus hosting, before you add a single new feature.

The maintenance figure surprises people, so it is worth being plain about where it goes. It is not developers idly improving things. It is the framework that reaches end of life, the payment provider changing an API, the library with a published vulnerability, and the browser that stops supporting something you relied on. None of that is optional and none of it shows up in a demo.

If you want a number for your own scope before talking to anyone, our free MVP cost estimator gives an indicative range in about a minute. It is deliberately a range, because a single number at that stage would be false precision.

Why are software estimates so often wrong?

Because the uncertain parts get averaged into one number, and because the hardest work is usually against someone else's system, which nobody can inspect until the build starts. The fix is not better guessing. It is estimating the parts separately, spiking the risky one early, and re-estimating after discovery.

There is one honest question worth asking any vendor, including us: which part of this estimate are you least sure about? A vendor who names a part is doing the work. A vendor who says the whole thing is well understood has either built this exact system before or has not looked closely.

What happens in discovery, and is it worth paying for?

Discovery turns an idea into a scope somebody can quote and build against: the users, the workflows, the systems it must talk to, the data it holds, and what is explicitly out of scope. It is worth paying for when the project is large or touches systems nobody has documented. For a small, well understood build, it is overhead.

A useful discovery produces four artefacts and nothing else. A list of the workflows the software supports, written as what a person does rather than as features. A map of every system it reads from or writes to, with a note on which of them has a usable API. A data model sketch, because this is the decision that is most expensive to change later. And an explicit out of scope list, which is the document that prevents the awkward conversation in month two.

What a discovery should not produce is a hundred page specification nobody reads. If the output cannot be summarised on two pages, it was a billing exercise.

What about web application development specifically?

Web application development is custom software delivered in the browser, which removes installation, makes updates instant and puts the same version in front of every user. It is the right default unless you need offline work, device hardware, or performance that only native code reaches.

Most business software should be a web application. The reasons are unglamorous: one codebase, no app store review between you and a fix, no version fragmentation, and the ability to change something at four in the afternoon because a customer called at three.

The cases where it is the wrong answer are specific. Software that must work with no connectivity for hours. Anything needing deep device access, such as background location or sustained camera processing. And workloads where rendering or computation genuinely demands native performance. For a field team with poor signal, we would build a mobile app with local storage and sync, which is a different service and a different budget.

Modern web applications also blur the line. A progressive web app can work offline, be installed to a home screen and send notifications, which covers a reasonable share of what used to require a native build.

What is different about enterprise software development?

Enterprise software development adds constraints rather than complexity: existing systems that cannot be changed, access control that must satisfy an auditor, procurement that outlasts the build, and users who did not choose the tool. The engineering is often simpler than a startup product. Working around the constraints is the job.

Three things reliably decide whether an enterprise project goes well, and none of them are technical choices.

Who can give an answer. In a small company that is the founder. In a large one it may be four people in three departments, and the build moves at the speed of their calendars. Establish this in week one and plan the timeline around it honestly.

What the legacy system will allow. An older platform with no public API is not a blocker, it is a design input. A read only database view or a nightly export is often the right answer, and it is cheaper than a project to modernise something that works. We cover the practical options on our ERP integration page.

Access and audit, designed at the start. Role based access and an audit trail added at the end are a rewrite. Added at the start they are a day of design. If a SOC 2 scope or a customer contract governs who may touch production, say so before architecture, not after.

Should you rewrite the old system or improve it?

Improve it, in almost every case. A rewrite restarts the clock on every bug the old system has already found and fixed, and it delivers nothing until it delivers everything. Rewrite only when the platform is genuinely unsupportable, when the cost of change is rising faster than the business, or when a rewrite can be done one piece at a time.

The honest version of this decision rarely gets made on evidence. Engineers prefer new code because reading someone else's is harder than writing your own, and that preference arrives dressed as a technical argument. Ask for the specific thing that cannot be done in the current system, and listen to whether the answer is a capability or an aesthetic.

When a rewrite is genuinely right, do it in pieces. Put the new system in front of the old one, move one workflow at a time, and keep both running until the last one is moved. It is slower, less satisfying and far more likely to finish. Big bang rewrites that pause feature work for a year are the single most common way a healthy software team loses its reputation internally.

If your product was assembled quickly with AI tooling and now has real users, that is a specific version of this question and usually not a rewrite. We review what exists, fix the security and reliability problems and harden it in place, which is what our AI code security audit covers.

Who owns the code, and how do you avoid lock in?

You own it, from the first commit, in your repository. Avoiding lock in is mostly about boring choices: standard languages, a mainstream database, infrastructure as code, no proprietary runtime that only your vendor can deploy, and documentation written during the build rather than after it.

Lock in is rarely written into a contract. It is created by accident, through decisions that are convenient at the time: a deployment process only one person knows, environment variables that live in someone's laptop, a framework chosen because the vendor already had a template for it.

The test is simple and worth applying to any vendor, including this one. Ask what would happen if you took the repository to another firm tomorrow. If the answer involves anything other than reading the documentation and running the setup script, you have found the lock in before it costs you.

What happens after launch?

Four things, reliably. Something breaks that you did not change. Real users rewrite your priorities within a month. Data outgrows the original design before the code does. And whoever built it starts forgetting how it works. Plan capacity for all four rather than booking the team onto the next project the week after launch.

The practical version: keep roughly a fifth of your engineering capacity unbooked for the first two months after a launch. Teams that do this look responsive and competent. Teams that do not spend those two months explaining why a small fix is scheduled for next quarter.

What do you build with?

Mainstream, well supported tools, chosen so that another team could pick the work up. We are deliberately conservative about this, because the cost of an unusual choice is paid by whoever maintains it in three years, and that is usually not the person who made it.

We build with AI tooling every day and we are open about it, which matters here because it changes what you should expect. It makes the first version faster to produce. It does not make the architecture decisions, the authorisation model or the data design, and those are what determine whether the thing survives its second year. What you are paying for is the judgement, not the typing.

Which industries do you build for?

Operations heavy businesses, mostly: manufacturing, logistics and fleets, field service, healthcare administration, multi store retail and food processing. The common thread is a process currently held together by spreadsheets, chat messages and one person who remembers everything.

• ManufacturingShop floor logging, multi site stock, downtime capture
• Logistics and fleetsDispatch boards, proof of delivery, customer tracking
• Field serviceScheduling against skills, parts, van stock
• Healthcare operationsIntake, referrals, document automation
• Multi store retailStore tasks, stock visibility, replenishment
• Agri and food processingLot traceability, quality capture, yield

We are not specialists in any one of these and we would rather say so. What we bring is the engineering and the patterns that repeat across operations software. What you bring is how your plant, depot or clinic actually runs, which is never in a case study.

How do you stop a fixed price project going over budget?

Price changes before doing them, not after. Every project changes, so the question is never whether to allow it but whether each change is visible and costed at the moment it is requested. Absorbed changes are the reason fixed price projects end in arguments.

The mechanism is unglamorous and it works. Anything outside the agreed scope gets written down as a one line description with a price and a schedule impact, and you say yes or no before work starts. No change is too small for that, because the small ones are where a budget actually goes. Twenty half day changes nobody wrote down is two weeks that appear from nowhere at the end.

Two failure modes to watch for in any vendor, including this one.

The silent absorber. A vendor who says yes to everything and never raises a change request is not being generous, they are building a case for the final invoice or quietly cutting quality somewhere you cannot see. Either way you find out late.

The change request as a weapon. The opposite problem, where everything including an obvious omission becomes billable. The test of good faith is how a vendor treats something that was genuinely implied but not written. The honest answer is sometimes "that is on us", and a vendor who never says it is managing you rather than working with you.

The other half of this sits with you. A single person who can say yes or no to a change within a day keeps a project moving. A committee that meets fortnightly turns every ambiguity into a two week pause, and no pricing model protects you from that.

What is involved in migrating the existing data?

More than anyone expects, which is why it should be scoped separately rather than hidden inside the build. Real data is messier than its schema suggests: duplicates, blank required fields, dates in three formats, and records that only make sense if you know a rule nobody wrote down.

Migration is the single most common reason a launch date slips, and it is almost always discovered late because everyone assumes the export will be clean. It will not be. Plan it in four stages.

Profile the data before quoting it. Count the rows, count the distinct values, count the nulls in fields that are supposedly required. A day of this tells you whether migration is a week or a month, and it is the cheapest day in the project.

Decide what not to bring. Most systems carry years of records nobody will look at again. Migrating everything because it is there doubles the work and imports every historic data quality problem into a system that was supposed to be a fresh start. Agree a cut off and archive the rest somewhere readable.

Rehearse it, more than once. A migration that has only been run once will fail on the night. Run it against a copy, fix what breaks, run it again, and time it, because "it takes four hours" changes the cutover plan entirely.

Agree what happens to records that cannot be migrated. There will be some. Decide in advance whether they are rejected with a report, imported with a flag, or fixed by hand, and who is doing the fixing. Discovering this at two in the morning during cutover is how launches go wrong.

One rule worth holding to: never migrate into a system the users have not seen. If the first time anyone looks at their data in the new application is after the old one is switched off, you have no way back.

How much testing does a custom build actually need?

Enough that you can change the software six months later without fear. In practice that means automated tests on the logic that would cost money if it were wrong, a staging environment that matches production, and manual testing by someone who was not the person who built it.

Testing everything is as wrong as testing nothing, and it is a common way to spend a budget without buying safety. The useful question is not coverage percentage, it is which failures would actually hurt.

Test the things that cost money or trust. Anything touching payments, permissions, or calculations somebody relies on. If a bug there would mean a refund, a data leak or a wrong invoice, it gets automated tests and it gets them first.

Test the paths people cannot avoid. Sign up, log in, the main workflow. These break rarely and catastrophically, which is the exact profile automated tests are good at catching.

Do not chase coverage on glue code. A test asserting that a form renders a label is a maintenance cost pretending to be quality.

Have someone else try to break it. The person who built a feature tests the path they had in mind. Real users do not. An hour of someone deliberately misusing the software finds a different class of bug than any automated suite.

The practical standard we hold to: a new engineer should be able to make a change, run the tests, and know within a few minutes whether they broke something important. If that is not true, the test suite is decoration. This matters most at the point you have forgotten the details, which is roughly when every business needs its first significant change.

What should you have ready before the first call?

Less than you think. Who the software is for and what their day looks like, which systems it has to talk to, roughly what the budget range is, and what would make you call it a success in six months. You do not need a specification, and writing one before a technical conversation usually wastes the effort.

The four things that make a first call productive.

The user and their day. Not a persona document. One paragraph: this person opens this at eight in the morning, under this pressure, and today they do it in a spreadsheet that goes wrong in this specific way. That paragraph shapes more of the design than a feature list does.

The systems involved. Names are enough at this stage. We will find out which of them has a usable API, and that answer often changes the approach more than any requirement does.

A budget range, honestly. Not a number you are protecting, a range. It is the fastest way to find out whether we should be discussing a three month build or a two week one, and a vendor who refuses to design within a budget is designing for themselves.

What success looks like in six months. Ideally something countable: hours saved, errors reduced, a report that stops being assembled by hand. If nobody can name it, that is worth discovering before the build rather than after.

What you should not do is write a detailed specification first. Specifications written before anyone has looked at the technical constraints tend to lock in decisions that the constraints will overturn, and then the document becomes something to defend rather than a plan to follow. Bring the problem. We will write the scope together and you will own it.

How does Voliom run a custom software project?

Discovery first if the project needs it, then a fixed line by line quote, then weekly releases you can click. You see working software from the first sprint rather than a status report. If something is going wrong, you hear it from us in the weekly demo, not in a post mortem.

Four commitments that shape how it runs.

A fixed quote, not a range that drifts. After scoping you get a line by line number. If scope changes, we price the change before doing it, rather than absorbing it quietly and arguing about it at the end.

Weekly demos. Work that cannot be shown is work that has drifted. A demo every week is the cheapest possible early warning system, for both sides.

Your repository from day one. Not a handover at the end. You can see every commit as it happens, and you could take the project elsewhere at any point without a negotiation.

Documentation written during the build. Written at the end it is produced by someone who has mentally left, and it shows.

Indicative until we have scoped the work. We are a small remote team working US business hours, with engineering based in Pakistan. You can read about the team, which is the fairest way to judge an agency this size. If you need capacity rather than a delivered outcome, IT staff augmentation is the lighter option.

• SaaS developmentMulti tenant products built to be sold
• IT staff augmentationCapacity rather than a delivered outcome
• Mobile app developmentWhen the browser is the wrong place
• Systems integrationMaking existing systems agree