Custom Software
Custom software built around how your business works.
Software made for your own workflows, instead of reshaping the business around a generic product. Depending on what you need, that is an internal business application, a workflow or approval tool, an operational dashboard, a customer or employee portal, or a system that connects the tools you already use.
Scoped from how the work runs today: who does what, where information lives, and what breaks.
Where it starts
Problems you may recognise, before any software is named.
These are common starting points, not promises. Discovery decides which of them a system should carry, and which are better left alone.
- 01Scattered information
The same details live in several spreadsheets and inboxes.
No single copy is clearly the current one · A simple question means asking around
- 02Manual re-entry
The same data is typed in more than once.
Orders, requests or records copied between tools by hand · Repetitive admin that takes time and invites mistakes
- 03No single view
Nobody can see who is doing what.
Status lives in messages and in people's heads · Hand-offs between people or teams get lost
- 04Outgrown tools
The operation outgrew spreadsheets or generic software.
Workarounds now outnumber the features in use · Each new person or branch adds more manual steps
- 05The wrong fit
The software you use does not match how you work.
Your team bends its process to fit the tool · Steps that matter to you have no place in it
What we build
Five kinds of system, each scoped from your requirements.
A project is one of these or a combination, depending on what you need. Each is built on Next.js, with a database schema and a typed codebase that end up in your repository.
- Internal business applications
One place for the work your team does every day.
- Records, tasks and documents your staff create and update
- Screens shaped around your own steps and vocabulary
- Your data in a database schema you own
- Workflow and approval tools
Requests that move through the right people, in order.
- Each step assigned to a role
- Status visible to everyone involved
- Rules you set, such as amounts that need a second approval
- Operational dashboards
The figures your operation runs on, in one view.
- Figures drawn from the records the system already holds
- Views for each role, so each person sees what their work needs
- Filters and exports for the questions you ask every week
- Customer or employee portals
A signed-in place for the people you work with.
- Accounts with roles and permissions
- Records, documents and requests in one place instead of email threads
- Built around the steps those people already take with you
- Connecting existing tools
The tools you already use, working together.
- Payment gateways, CRMs, accounting tools and third-party APIs
- Data passed between systems instead of typed twice
- Each integration reviewed during scoping, before it is priced
How a requirement becomes a system
The same five phases, each one signed off by you.
Every Altruvex project runs these phases in this order. Your proposal fixes the timeline and dates for your scope.
- 01 — Discovery1 session
The initial project consultation call covers how the work runs today: who does what, where information lives and what breaks. The proposal that follows sets scope, price and timeline, and what is out of scope.
What you decide: Whether the proposed scope, price and timeline are right, before you sign.
- 02 — Wireframe2 – 5 days
The roles and what each one can see and do, the main screens, and how a record moves from one step to the next.
What you decide: Approve the roles, screens and flows. Everything after is built on them.
- 03 — Design2 – 7 days
The interface on that structure, with 3 included revision rounds.
What you decide: Approve the design. Development starts after your approval.
- 04 — Development3 – 22 days
Built on a live preview link you can open at any time, on the data model, roles and integrations agreed earlier. The milestone payment falls at the point named in your proposal.
What you decide: Review the preview with the people who will use it, and send feedback as you go.
- 05 — Launch2 – 5 days
Hosting set up and the build on staging for your review; after the final payment, production deploy and handover of code, schema and documentation.
What you decide: Approve the launch. The final payment is due before production launch, and ownership passes to you at that payment.
Beyond the screen
What a system has to handle beyond its screens.
We plan the data, roles and screens before writing code. These are the parts a screen does not show; we plan them before writing code.
- In the drawing: the relations between the records.
A structure for your records that can grow.
- Records and how they relate, designed before the screens
- A database schema and its migrations, handed over with the code
- Your data in a schema you own, not locked inside a platform
- In the drawing: the Role entity.
Each person sees and changes what their work needs.
- Roles agreed in the wireframe phase, before anything is built
- Access enforced by the system, not only hidden in the interface
- In the drawing: the missing value on Request.
What happens when input is wrong or a step fails.
- Empty, incomplete and duplicate records planned for
- Input validated before it reaches your data
- A clear message when something cannot be saved
- In the drawing: the External service entity.
Connections scoped before they are priced.
- Each external service reviewed during scoping
- How the system behaves if that service is unavailable, agreed during scoping
- In the drawing: the lock on Person.
Part of the build, not an afterthought.
- Security headers, input sanitisation and dependency audits as part of the build
- Authentication flows built against current OWASP guidance
- In the drawing: the title block, schema · migrations · docs.
Written for the next developer who opens it.
- Strict TypeScript and a component-based structure
- Documented API endpoints, an environment and secrets guide, and deployment documentation
- Another developer can take over; the handover is written for that
Is it the right answer
When custom software fits, and when it does not.
Building software is the right call only when nothing simpler fits. We would rather say so before a proposal than after it.
The way you work is what the software has to carry.
- Your operation runs on spreadsheets, email and manual steps a system could carry.
- Generic software makes your team work around it.
- You need roles, approvals or records that are your own.
- You want to own the code, the data and the accounts instead of renting a platform.
Something simpler already fits.
- An off-the-shelf product already fits how you work. Use it.
- The problem is not defined yet. Start with the free initial consultation call, before any build.
- A website is what you need. That is website design and development.
- An existing system needs a decision, not a rebuild. Start with the technical audit.
No. Describe how the work runs today and what goes wrong. The initial project consultation call and the proposal that follows turn that into a written scope, including what is out of scope.
You do. The source code, database schema and documentation are handed over in your repository, and code, designs and accounts pass to you at the final payment. There is no licence fee and no lock-in. Our own reusable components and open-source libraries keep their licences; you may use them in this system.
Often, when the tool offers a way to connect, such as an API or a data export. Each integration is reviewed during scoping, before it is priced, and access to those systems is part of what you provide. If a system offers no reliable way in, we say so before you sign.
The proposal sets scope, price and timeline, and its figure is binding for that scope. Minor changes, within 5% of the agreed effort, are included. Moderate changes, 5-25%, are agreed in writing before work starts, at a fixed price from the same published ranges or at 800 EGP per hour. Major changes, over 25%, are quoted as new work or a second phase.
The estimator gives an indicative range before the first call, and the price is fixed in the proposal. Payment is split 50% to start, 30% at a development milestone, and 20% before production launch.
A 30-day warranty covers critical fixes after launch. Ongoing maintenance is a separate, optional agreement with its own defined scope. You can also pay for changes as needed, or hand the system to your own team with the documentation it needs.
Next step
Describe the work the software has to carry.
Tell us who does what today, where the information lives and what breaks. We reply with the next step.