Custom systems
Custom web systems in Oman.
The work that starts with a sentence like "there is no software that does this the way we do it." Internal tools, client portals, dashboards, and the connections between systems you already pay for.
When custom is the answer
Four signs you have outgrown off-the-shelf.
A spreadsheet is quietly running the business.
One file, several people, no history of who changed what. It works right up until it does not, and by then everything depends on it.
Staff copy the same data between systems.
Something is entered in one place and re-typed in another because the two do not talk. That is an hour a day and a steady source of errors.
You pay for software you use a tenth of.
A large platform bought for one feature, with your actual process bent to fit it. The licence renews whether or not it fits any better this year.
Clients keep asking you for status.
Requests for updates that a portal could answer without anyone replying — where their job stands, what has been paid, what is next.
What gets built
Systems shaped to one business.
Custom does not mean elaborate. Most of these are deliberately small — the point is that they fit exactly, and that nothing in them exists for someone else's use case.
How custom projects start
Scoping first, because guessing is expensive.
-
Step 01
We watch the current process
What actually happens, including the workarounds nobody documents. This is where most of the real requirements are found.
-
Step 02
We agree the smallest useful version
The part that removes the most work first. Everything else is written down for later rather than built now.
-
Step 03
Build, with your team using it early
Real users on real data as soon as possible, because that is when you learn what was actually needed.
-
Step 04
Extend once it has proven itself
The next piece gets built after the first is genuinely in use — not while it is still theoretical.
Worth saying
Custom is not always the right call.
If an existing product does eighty per cent of what you need for a monthly fee, buying it usually beats building it. Custom software has a real ongoing cost: it is yours to host, maintain and change as the business changes.
It is worth it when the twenty per cent that does not fit is the part that makes you money, or when the workaround is costing more in staff time each month than a build would. If we think you should buy something instead of hiring us, we will tell you what to buy.
Questions
About custom builds.
How do you price something that does not exist yet?
We scope it first as a small, paid piece of work, and that produces a fixed price for the build. Quoting a number before anyone understands the process is how custom projects go wrong for both sides.
Who owns the system you build?
You do — the code, the data and the hosting account. If you later want another team to take it over, they can. We would rather that be possible and never used.
Can it work with software we already use?
Usually, if that software offers a way in — an API, an export, or a database we can reach. Where a system is genuinely closed, we will tell you before you commit, not after.
What happens to our existing data?
It gets migrated, and that is often the largest single piece of work. Years of spreadsheets usually contain inconsistencies that have to be cleaned before they can be trusted in a system.
Will our staff actually use it?
Only if it is faster than what they do now, which is why we start from watching the current process. A system that adds steps gets quietly abandoned no matter how well it is built.
What if we need changes later?
Expected — a system that fits a business has to change as the business does. Changes are quoted individually, and you are not tied to us to make them.
Start here
Describe the process that is not working.
What your team does by hand, where the delays are, and which systems refuse to talk to each other. That is the beginning of a scope.