Included in a typical proposal
- Discovery and build labour for the named first release.
- Integrations listed in the proposal.
- Acceptance tests for the agreed paths.
SOFTWARE DEVELOPMENT
Custom software development
in Dubai & the UAE.
Build an application around a workflow your existing tools cannot handle well. We map the process, define what users need and develop against agreed acceptance criteria.
WHAT THIS SERVICE IS
A plain explanation of the work.
Custom software development is building an application for a workflow that generic tools handle badly: too many exceptions, too many roles, or data that has to stay in a shape your staff already understand. It is not a rewrite of Microsoft Excel for its own sake, and it is not a product you will resell unless that is a different brief (see software product and SaaS pages).
We map the current work, including the unofficial steps people take in WhatsApp. Those unofficial steps are often the real process. Ignoring them produces a tidy application that nobody uses. The first release should complete one job end to end, even if later phases add reporting or extra roles.
Technology choices follow the team who will maintain the result, the integrations that are actually documented, and the hosting you can pay for. We will not pick a stack because it photographs well in a case study we are not writing.
A CLEAR PICTURE
A labelled diagram, not a decoration.
-
Sit with the people who do the work
Not only with the sponsor’s summary.
-
Write the first release as a checklist
A user can complete item one without item seven existing yet.
-
Build and connect in the open
Regular reviews beat a six-month reveal.
-
Prove it on a real case
Then document how to ship a change.
WHO IT IS FOR
The situations this page is written for.
Operations teams with a process that has outgrown shared inboxes, firms whose industry software misses a local requirement, and owners who have a spreadsheet that has become a liability.
- Businesses that can nominate users for workshops and testing.
- Teams that know which system is the source of truth for each field.
- Managers who can live with a first release that is narrow but real.
- IT contacts who can grant access to the systems we must connect.
TYPICAL SCOPE
What a proposal usually names.
01
Workflow discovery
Interviews, sample files, and a written path including exceptions. If two departments disagree, that is a decision for you, not for the code to guess. We record the decision.
02
Roles and first slice
Permissions, the screens for the first release, and acceptance examples. A prototype is used when the interaction is unfamiliar. Decorative UI kits are not a substitute for the real fields.
03
Development and integration
Build against the agreed interfaces. Where an API is unofficial or rate-limited, that risk is in the proposal. We do not scrape a vendor’s screens as a hidden integration unless you accept that fragility in writing.
04
Testing and handover
The acceptance paths, a deployment note, and who owns production. Test data should not be live personal data if a copy can be used. Training is the roles you booked.
INCLUDED AND QUOTED SEPARATELY
Labour versus things that sit on their own line.
Quoted separately
- Extra phases, extra roles and extra reports not in the release.
- Licences, cloud bills and vendor API fees.
- Migrating decades of dirty data beyond an agreed import.
- App-store publication, unless this is combined with the mobile page.
AFTER HANDOVER
What you should hold when the work is done.
Source code, environments and credentials follow the agreement. Third-party components keep their licences. A runbook that only exists in one engineer’s head is not a handover; we will write the boring parts.
Change requests after acceptance are maintenance or a new phase. That is not hostility. It is how the first release stays a first release.
PRACTICAL NOTES
Details that usually affect the proposal.
Environments matter: a place to try a change that is not production. If you have only a live server, the first extra we will often recommend is a staging copy. Skipping that to “go faster” is how a small fix becomes a morning of downtime. The proposal should name how many environments you are buying.
Data quality sets import labour. Ten thousand rows with three spellings of every customer is not a weekend job. We can import a clean subset and leave the rest until you have a rule. Pretending the mess will sort itself inside the new application is how go-lives disappoint finance.
PLANNING THE WORK
Questions worth asking.
Can you start coding next week?
Only if the workflow is already written and the access is ready. Otherwise discovery is the first week’s work and it is not optional decoration.
Will we own the code?
Bespoke work is described in the contract. Libraries, themes and cloud services stay under their own terms. Read that section before we start.
What if the process changes mid-build?
We pause the checklist, write the new decision, and re-scope. Silent process change is how dates evaporate.
CONNECTED SERVICES
Explore the next piece.
LET’S BUILD WHAT’S NEXT
Your next step starts
with a conversation.
Tell us what you want to improve, build or simplify. We’ll help you define a practical way forward.
Discuss your project