Software
Build it last, not first.
Custom software is the most expensive answer and occasionally the only right one. The value of asking properly is that most of the time the answer is cheaper than building.
When should a business build custom software?
A business should build custom software when the process is a genuine competitive difference, when no product fits without damaging workarounds, or when the cost of bending the business to available software exceeds the cost of building. CompanyWRX assesses buy, configure, integrate and build in that order — and recommends building only when the first three have failed honestly.
What the work involves
- Test the alternatives first, properly: can this be bought, configured, or integrated instead?
- Establish what the software actually has to do, by following the real work rather than collecting a feature wish list.
- Build in usable stages, so something is in people’s hands early rather than at the end of a year.
- Write it to be maintained by someone else — documented, tested, and with no dependency on a single person.
- Hand over the source, the infrastructure and the knowledge.
What you hold afterward
- Working software your people use, deployed on infrastructure you own.
- The source code, the documentation and the deployment process — all yours.
- A maintenance path that does not require us.
The expensive part of custom software is never the building. It is the ten years afterward.
When this is the wrong thing to buy
If you want to build because evaluating the alternatives is tedious, do not. Custom software is a permanent operating commitment — it needs hosting, updates, security patching and someone who understands it. If nobody in the business will own it, buying is the better answer even when it fits worse.
Questions
Custom software, in practice.
Do we own the code?
Yes. Source, infrastructure and documentation. We do not build software that only we can maintain.
What does it cost to maintain?
Budget for it as an ongoing operating cost, not a one-off project. Hosting, dependency updates, security patching and small changes are continuous, and pretending otherwise is how custom systems become the legacy problem five years later.
Can you take over software someone else built?
Often. The first step is an honest assessment of what is there — sometimes the right recommendation is to keep it, sometimes to rewrite the part that is failing, and occasionally to replace it. We will tell you which before quoting the work.
Where this usually leads
This rarely arrives on its own.
You pay for eleven systems and your team still keeps the real numbers in a spreadsheet.
If the outcome is what you are after
- Build custom softwareNothing on the market fits without damaging workarounds, and the thing your company does differently is exactly the thing the software cannot do.
- Modernize a businessThe business runs well and looks like it did in 2014. Customers ask questions the website should have answered, and your team keeps a spreadsheet because the system cannot do it.
Usually done alongside
- Software integrationConnecting the systems you already run so data moves between them automatically — instead of a person re-typing it from one screen into another.
- Software stack auditA full review of every system you pay for: what it costs, who uses it, what it duplicates, and what could be removed, replaced or made to work properly.
- Business intelligenceDashboards, KPIs and management reporting built on numbers that agree — produced the same way every time, from the systems that hold the truth.
Not sure this is your problem?That is usually the most useful thing to find out first.
Answer thirteen questions about how your company actually runs and get a reading on each area — brand, website, search, reviews, software, automation, payments, operations, people, data and continuity.
Typically owner-led companies from first idea to around 500 people.