Service — Software
When a business outgrows its spreadsheets, the problem is rarely the spreadsheet — it is that the process now lives in six places at once. Promiq Agency builds the software that puts it back in one, designed around how your business actually operates.
When custom software starts making sense
There is a recognisable moment. The spreadsheet has become the system of record, but three people keep their own copy. Somebody has to be asked before anything can be confirmed. The same number is typed into four places and one of them is always wrong. New staff take months to learn a process that exists only as habit.
At that point the cost is no longer the software you are missing — it is the hours, the mistakes and the dependence on whoever happens to know how it works. Custom software is worth considering when the process is specific enough that no off-the-shelf product fits it, and important enough that getting it wrong actually costs you.
Build or buy — an honest answer first
Not every problem deserves custom software. If a standard package covers eighty per cent of what you need and you can live with the rest, buying it is almost always cheaper and faster, and we will say so.
Building earns its place when your process is the thing that makes you competitive, when the available products force you to work in a way that costs more than it saves, or when the real problem is that four systems do not talk to each other — in which case the answer is often a thin layer joining them rather than replacing any of them.
We go through that at the start, before a quote exists. It is a short conversation, and it has talked plenty of people out of a project that would not have paid for itself.
Software shaped around your process
The advantage of building is that the software can follow the work instead of the other way round. Your terminology, your steps, your exceptions — including the ones that make no sense to an outsider but exist for a reason. Staff recognise their own process on screen, and that is most of what makes a tool get used rather than quietly abandoned.
It also means the tool can stay deliberately small. Internal software fails more often from doing too much than too little, so we build the part that is actually used, get it into people's hands, and extend from what they do with it rather than from a specification written before anyone had tried it.
Built to still be maintainable later
Custom software is only an asset while somebody can change it. We build on mainstream, well-documented technology, keep the code readable, and write down how it is deployed and how it is backed up. If you ever hand it to another developer, they should be able to pick it up without an archaeology project.
You own the code and the data. No licence that expires, no format only we can read, and an export path for everything in it. Making it easy to leave is what makes it reasonable to stay.
What we build
Every build is specific to one business. These are the shapes the work usually takes.
Internal business tools
The system that replaces the shared spreadsheet, with roles, history and one version everybody is looking at.
Dashboards and reporting
Your real numbers in one place, updating on their own instead of being rebuilt by hand each month.
Customer portals
A logged-in area where clients see their orders, documents or status without having to email and wait.
Booking and scheduling
Availability, reservations and reminders for businesses running on appointments, capacity or rentals.
Inventory and orders
Stock, suppliers and order status tracked in one system rather than reconciled across several.
Quoting and invoicing tools
Documents generated from your own pricing rules, consistent every time and numbered without gaps.
Integrations between systems
A layer that gets your existing tools talking, so the same data stops being entered more than once.
Web applications
Full browser-based products for teams or customers, working the same on a laptop and on a phone.
Roles and access control
Who may see and change what, with an audit trail, so sensitive data is not simply open to everyone.
Data migration
Your existing records moved across and checked, so launch day does not start from an empty system.
How a software project runs
Delivered in working increments, so you are using something real long before the project is finished.
Discovery
We sit with the people doing the work, map the process and its exceptions, and agree what the first version must cover.
Specification
Scope, screens, roles and data written down, with anything deliberately left for later marked as such.
Iterative build
Working software in stages, reviewed as it is built, so corrections land while they are still cheap.
Launch and support
Data migrated, your team trained, documentation handed over, and support while real use settles in.
Frequently asked questions about custom software
Is custom software not far more expensive than a standard package?
Up front, usually yes. Over a few years it depends on how well the standard package actually fits, what per-user licences add up to, and how many hours go into working around the gaps. We put both numbers side by side before you decide, and we have recommended the standard package plenty of times.
Who owns the software you build?
You do — the code and the data. It runs on infrastructure in your name where you want it to, and everything in it can be exported. There is no licence that stops working and no format only we can read.
What happens if we stop working together?
You keep the code, the documentation and the access. We build on mainstream technology precisely so another developer can take it over, and we hand over properly rather than making it difficult to leave.
How long does a project like this take?
A focused internal tool is usually a matter of months rather than years, because we deliberately ship a working first version rather than a complete one. How fast it grows after that is your call, and the first version is normally in daily use well before it stops changing.
Can it work with the systems we already use?
That depends what those systems allow. Many have an API or an export we can build against; some are closed, and then the honest answer is a workaround or nothing. We check what is genuinely possible early, because it changes what is worth building.
Will our team actually use it?
That is a design problem as much as an engineering one, which is why we build around your existing process rather than an idealised version of it. People are involved during the build instead of being handed a finished system, and training and documentation come with the launch.
Can you take over software somebody else built?
Sometimes. We start by reading what exists and telling you what shape it is in. Taking it over is realistic when the code is readable and the technology is current; when it is neither, continuing to patch it can cost more than replacing it, and we will say which of the two we think you are facing.
