Discover: mapping a system across a wall of diagramsDiagnose: reading dashboards to locate the problemDesign: wireframes and interface work for the solutionDeliver: shipping the finished productEvolve: continuous improvement after launchCustom software taking shape from code to application
Scope · Build · Hand over

Custom software development

Software written for the way your business actually works, when the off-the-shelf option would mean changing the business to suit the software. We scope it in phases that each stand alone, so the first one ships before the second is agreed.

  • Phase
    Scoped and quoted
  • Live
    Before phase two
  • Yours
    Code and accounts
  • Docs
    Dated at handover

Sectors that trust us

What is custom software?

Custom software is built when the process you are supporting is the thing that makes you money, and bending it to fit a package would cost more than writing one. The test is not whether a product exists; it is whether using it would change a decision you are good at.

Custom or configure?
Configure first, every time it is possible. Custom software earns its cost only where your process is a genuine advantage rather than an accident of history, and telling those apart is most of what scoping is for.
Who owns the code?
You do, from the first commit, in a repository inside your own organisation, with the cloud accounts in your name. There is no licence back to us.

Key takeaways

  • Standalone phases: each one ships and could be the last.

  • Hardest part first: built while you can still stop.

  • Tests included: in the same phase, never a later one.

  • Quoted before start: priced before the phase begins.

  • Yours at the end: code, accounts and dated documentation.

Why builds overrun

Where custom builds overrun, and how we scope them.

How they overrun

  • One big scope, nothing usable until the end.

  • Estimated before the hard part is known.

  • Tests are a later phase that is never funded.

  • Handover is a conversation on the final Friday.

  • Requirements gathered from managers, not operators.

  • The vendor keeps the repository and the accounts.

How we scope

  • Phases that each stand alone and each ship.

  • The hardest part is built first, on purpose.

  • Tests ship with the feature they cover.

  • Handover is written as the work happens.

  • The people doing the work shape the screens.

  • Repository and accounts in your name from day one.

What we build

Custom software, built and shipped one phase at a time.

  • Operations tools

    The screens your team lives in.

  • Customer portals

    Self-service for what arrives as calls today.

  • Workflow and approval engines

    Approvals and routing, with a complete trail of who decided what.

  • Pricing and quoting

    Versioned rules, so old quotes explain themselves.

  • Reporting surfaces

    The few numbers people read, computed once.

  • Admin and audit

    Roles, permissions and a record of every change that mattered.

Where we have built

Sector knowledge built in, not bolted on.

From clinical tools to lending systems, the rules of the sector shape the build.

  • Banking and fintech

    Ledgers, onboarding and the audit trail regulators ask for.

  • Healthcare

    Scheduling, records and care-team tools built with clinicians.

  • Logistics

    Tracking, routing and warehouse systems.

  • Retail and e-commerce

    Storefronts, stock visibility and order flows.

  • Government

    Citizen portals and case management, Arabic first.

  • Real estate and more

    Property, insurance, energy and education platforms.

What we build with

Boring where it should be, current where it counts.

  • TypeScript
  • Next.js
  • NestJS
  • PostgreSQL
  • Redis
  • Kafka
  • Flutter
  • Docker
  • Kubernetes
  • AWS

How it works · our method

The SiaSol five-phase method, applied to this service.

  1. 01

    Discover

    Most technology projects fail long before the first line of code — they fail at the question.

  2. 02

    Diagnose

    Every slow process has an owner and a cost.

  3. 03

    Design

    Architecture is a set of decisions you live with.

  4. 04

    Deliver

    Software not in production is just cost.

  5. 05

    Evolve

    The handover is the point, not the end.

Where we work

Close where it counts, bilingual everywhere

  • Egypt: Cairo (HQ) and nationwide delivery

  • Saudi Arabia: Riyadh, with teams on client time zones

  • Gulf and beyond: Arabic and English, one delivery standard

Cost & engagement

Custom software: what each phase costs and what it buys

Cost is quoted per phase, and every phase is scoped before it is quoted. Scoping carries a fixed price of its own, because a free scope is simply paid for later, inside the estimate it produced.

  • Fixed · one to two weeks

    Scoping

    The phase plan, the risks named, and a number against each phase.

  • Per phase · fixed after scoping

    One phase

    Built, tested, deployed and in front of real users.

  • Monthly · dedicated

    Embedded team

    A standing team working through a roadmap of phases.

Why teams across the Gulf and Egypt choose SiaSol to build their custom software

We build from Cairo, Riyadh and Dubai for clients across the Gulf and Egypt, in Arabic and English, inside your working day. The first phase takes the piece we are least sure of and ships it to real users, and when a package would serve you better we say so before you pay for a build.

Proof

Software we have built, and what it changed

FAQ

What to ask about Custom software development.

01Should we not just buy a package?

Usually, and it is the first question we ask rather than the last. Custom software is worth its cost only where your process is a real advantage, and scoping exists partly to find out whether it is. We have ended scoping with that recommendation.

02How accurate are your phase estimates?

Accurate for the phase being quoted and deliberately rough beyond it. A phase is quoted after it has been scoped, which is why the number is fixed; later phases carry a range that narrows as earlier ones teach us what the system is actually like.

03Can we stop after the first phase?

Yes, and the phases are designed so that stopping leaves you with something working rather than a foundation. Two clients have stopped after phase one because it solved enough of the problem, which we count as the planning working, not as a loss.

04Who owns the code that you write?

You do, from the first commit, in a repository inside your own organisation. There is no licence back to us, no shared component you would have to keep paying for, and the cloud accounts are in your name rather than transferred at the end.

05What if our requirements change mid-build?

Between phases that is simply the next phase being scoped differently, which costs nothing. Inside a phase we say what the change does to the date and the number before doing it, so the decision is yours with the price visible, not discovered later.

06Do you work with our existing developers?

Yes, and it usually makes the handover better because there is someone to hand over to. They review our work on the same terms we review theirs, which surfaces disagreements about approach in week two instead of at the end of the project.

07What happens after the last phase?

A dated handover document, a walkthrough with whoever will maintain it, and a support arrangement if you want one. The support is optional on purpose: a system that can only be maintained by the people who built it has not been handed over at all.

08How long does a typical phase take?

Four to eight weeks, and we resist making them longer. A phase that runs past two months tends to stop being a phase and become a project with no checkpoint, which removes the one property that makes the arrangement safe for you.

Ready to scope the first phase?

Tell us the process that does not fit a package, and what it costs you today. We come back with phases and numbers.

Book scoping