How I work with you
Custom software development
Custom software development is building a system around the way a business actually works, instead of changing the way it works to fit a product someone else designed. It earns its cost when the process that makes the money is the part no off-the-shelf tool models properly — a many-to-many mapping between customer orders and supplier purchases, stock that moves around on vans, a landed cost that has to be allocated fairly across a shipment. I build those systems whole: business analysis, architecture, development, deployment, and the operations tooling the people running it need from the first week.
Business systems built around the way your operation actually works, for when the standard product would need the operation to change shape to fit it.
Who needs a custom business system?
Custom software is for a business whose core process is the thing that makes it distinctive, and where the available products either model something adjacent to that process or require the operation to change shape to fit them. If a standard tool does the job, buy it. The case for building starts when the workaround has quietly become the process.
The situations where that is usually true:
- The process lives in chat threads, supplier emails, and spreadsheets, and answering a customer question means one person reconstructing the story from four places.
- Nobody can answer a basic operational question — which outlets were visited, what is moving in which territory, how much cash is outstanding with whom — while there is still time to act on the answer.
- Work happens where there is no network, so connectivity cannot be assumed.
- One order means several different things as it moves through the business, and a single record has been forced to represent all of them.
- The true cost of an order is only known well after it has been delivered.
I work with startups, SMEs, and growing businesses, mostly across the Gulf and the wider MENA region, in Arabic and English.
What does a custom software project include?
A custom software project covers the full lifecycle rather than the build phase alone: business analysis and product planning, architecture and system design, development and delivery, cloud deployment and scaling, and App Store releases where the system has a mobile surface. Concretely, on a custom business system:
- The domain model — the objects your business actually has, separated honestly. A customer order and a purchase order are different things with different lifecycles; modelling them as one record is the mistake that makes everything afterwards painful.
- The lifecycle definition — every state, every transition, and what triggers it, including the awkward states everyone would rather not discuss.
- Derived status, computed from events that happened rather than a field someone has to remember to update.
- The business rules that are genuinely decisions — cost allocation, currency and rate at each stage, credit and limits, conflict resolution — surfaced and agreed rather than assumed by the code.
- Integrations with the external systems the process depends on, each behind one boundary, with idempotency wherever money or an irreversible step is involved.
- Offline capability and a sync model where the work happens away from a network, including conflict rules and document numbering that survives partition.
- The back-office and operations tooling — reconciliation, corrections, exception handling — specified as part of the system, not bolted on.
- Deployment, environments, and the observability needed to diagnose a problem in production rather than argue about it.
How does a custom software build run?
A custom software build starts with the model, not the screens. The lifecycle gets defined and written down with the business before any interface exists, because every feature afterwards is either straightforward or impossible depending on those decisions — and because the questions involved are business questions in technical clothing. Is a customer order the same object as a purchase order? Which currency was this denominated in, and which rate applies at which moment? When a phone and the server disagree about a day’s sales, who wins?
Then the lifecycle in order:
- Business analysis and product planning — what the business does, who actually uses the software, and which constraints are already fixed: a market you operate in, a provider you must integrate, a system that has to keep running throughout.
- Architecture and system design — the domain model, the boundaries, and the decisions that would be expensive to reverse.
- Development and delivery — a modular monolith by default: real boundaries between modules, one thing to deploy.
- Cloud deployment and scaling — environments, and the traces that make production answerable.
- App Store releases where there is a mobile surface.
Throughout, one rule decides what gets automated: automate the reconciliation, not the judgement. The system removes the copying and the arithmetic; the decisions that need a person stay with the person, surfaced with the information needed to make them. That rule is the practical form of the claim this whole practice rests on — I understand the technical system and the business it has to serve, which is why the model gets argued out with you before anything is built on top of it.
Where I've done this
Offline-first van sales for FMCG distribution
Van sales and distribution for an FMCG operation — reps sell, invoice, and settle from a phone on the route, offline, and the back office sees it when they reconnect.
Cross-border order management system
One order lifecycle from customer request through international purchasing to shipping and local delivery — replacing a process that lived in chat threads and spreadsheets.
Questions about this work
When is custom software the right answer instead of buying a product?
If a standard product does the job, buy it — the cheapest system is the one you did not have to build, and I will tell you so. The case for custom starts when the workaround has become the process: when the tool models something adjacent to your operation and the gap is filled by spreadsheets, chat threads, and someone's memory. The test I use is whether the mismatch sits in the part of the business that makes it distinctive. Reporting formats and approval steps rarely justify a build. An order lifecycle that no product represents correctly usually does, because every workaround around it costs you daily and compounds.
Can a process that lives in spreadsheets and chat threads just be digitized as it is?
Not directly, and trying is the common failure. A process that grew in spreadsheets encodes assumptions nobody has ever written down, and it usually contains one specific lie: a status field somebody is supposed to remember to update. The first real deliverable is an honest model of the lifecycle — every state, every transition, and who or what triggers it, agreed with the business rather than assumed. After that, status is derived from events that actually happened rather than typed in by a person. If status is manual, it is wrong.
Can a custom system work alongside the accounting or ERP software we already pay for?
Yes, and that is normally the right shape. Custom software is not an argument for replacing everything you run — it is usually the layer that models the part of your business nothing off the shelf models, connected cleanly to the tools that already do their jobs well. Each external system sits behind one integration boundary with a shared internal representation, so your domain model does not change shape every time a vendor does, and swapping a provider later is implementing an interface rather than rewriting the system.
What changes if our people work offline or away from the office?
Everything, and it has to be decided before the screens. If a rep in a warehouse basement or on a rural route has to keep working with no signal, the device holds real state — full catalogue, pricing, customer balances, stock on the van — which means sync conflicts are guaranteed rather than exceptional. Who wins a conflict, per entity, is a business rule that has to be agreed in writing, not settled by last-write-wins. Document numbering has to survive partition too, so several devices disconnected for hours cannot collide. Offline-first is architecture; it is very expensive to add to a system that assumed a network.
Do you build the mobile side as well?
Yes, where the work happens on a phone rather than at a desk. Field sales, deliveries, inspections, and service visits are mobile-first by nature, and in those systems the phone is frequently the source of truth rather than a thin view onto a server. App Store release is part of the lifecycle I cover rather than a separate engagement, so the person who designed the sync model is the person who ships the app that depends on it.
Who is a business system actually built for — the field users or the back office?
Both, and the back office is the half that gets neglected. Reps, drivers, and agents are the visible users, but the value is realized by the people reconciling stock, cash, and exceptions — and someone will need to split an order, reassign an item, or correct a cost allocation in the first week. If that capability only exists in the database, the business pays for it every week afterwards. I treat operations tooling as a feature with a specification, not as an admin screen added at the end.
Custom software development — tell me what you're working with.
Start a conversation