Custom Web Application Development in Giza

The shape of the problem here

Operations spread across thirty or forty kilometres of Greater Cairo, coordinated by phone calls and a file somebody emails around. It works until the volume rises, then it stops working suddenly rather than gradually.

That is the moment most of these projects start.

What custom actually means

Software written for how this business works, rather than a product the business reshapes itself around. It is the right answer when the process is genuinely unusual and the wrong answer when it is not.

Most requests are better served by something that already exists.

When Wink says buy rather than build

Honestly and early, because it saves the client the most money.

• Accounting, payroll and standard inventory already have good products
• A store is a store, and building one from nothing is rarely justified
• Booking and scheduling have mature options worth trying first
• Custom is for the part of the business nobody else has

The problems that genuinely need building

Usually coordination across sites, and usually specific to the operation.

• Dispatch and delivery across zones with very different travel times
• Stock held in two places that has to read as one number
• Job tracking where a piece of work moves between locations
• Approvals that currently happen by phone and leave no record

Why travel time is the recurring design constraint

A system that treats all of Giza as one zone will schedule a delivery to Sheikh Zayed as though it were Agouza. Distance has to be part of the data model, not an afterthought in a report.

Building for the phone first

The people using these systems are drivers, storekeepers and site supervisors, and they are on a handset. A system designed on a desktop and squeezed onto a phone afterwards gets abandoned within weeks.

Arabic interfaces, properly

The staff using it read Arabic, so the interface is Arabic and laid out right to left from the start. Retrofitting that later is expensive and it always shows.

Working offline, at least partly

Connections drop between the desert road and the inner districts. A driver's screen has to accept an entry and send it when the signal returns rather than losing it.

How the project is scoped so it finishes

In stages that each deliver something usable.

• One process, chosen because it is the one currently failing
• A working version in weeks, used by real staff
• The second process only after the first is genuinely adopted
• No feature built because somebody might need it later

Why adoption decides the outcome, not the code

These systems fail in the office, not in the browser. If the storekeeper keeps a parallel notebook because the screen is slower than writing, the project has failed regardless of how well it was built.

Wink watches the first weeks closely for exactly that.

What it costs to keep running

Hosting, a support arrangement and somebody's time every month. That figure is stated before the build starts, because a system the business cannot afford to maintain is a liability rather than an asset.

What has to be planned from the start

Who owns it after handover, where the data lives, and how it is backed up. A custom system with no named owner degrades quietly until somebody rebuilds it.

What Wink does not do

Build a large system in one delivery. A twelve month build reaches a business that has changed, and the parts that mattered most were guessed at the beginning.

Where this connects

It sits on hosting and deployment, it needs maintenance and support, and it often follows corporate website development. The category view is website development.