Custom Business Systems
A custom system holds the work your company already does in one place, with the statuses, rules and permissions that match how you actually operate rather than how a generic tool assumes you do.
When the spreadsheet stops holding
Almost nobody decides to build a business system. They arrive at one. A single spreadsheet becomes four, the four get copied and emailed, someone introduces a colour code that only they can read, and the actual state of an order ends up in a message thread rather than in a field. On any given day none of this is broken enough to stop and fix, which is precisely why it survives for years.
The cost is real but indirect. Time spent working out which version of the file is current. Jobs that slip because the person tracking them was away. Simple questions such as how many orders are open right now that take somebody twenty minutes to answer, and are stale by the time they have. When those symptoms are routine rather than occasional, the process has outgrown the tools carrying it.
What a custom system changes
The core of it is unglamorous. Information that currently lives in several places lives in one, and the rules that currently live in people's heads become part of the system.
That has a few consequences that matter more than any feature list. There is one current state of every job rather than several plausible ones. Status changes leave a trace, so questions about what happened stop being reconstructions. Access can be scoped, which becomes important the moment the data includes client details or pricing. And because the structure reflects your process rather than a generic one, reporting stops requiring an export and a pivot table.
None of this makes work disappear. It makes the work visible and stops the same information being entered three times.
The honest comparison with off-the-shelf
There is a real case against building. If your process closely resembles what an established product already does, buying it is usually cheaper and always faster, and we would rather tell you that early than discover it together halfway through.
Custom development earns its keep in two situations. The first is when the process is genuinely specific to how you operate, especially when it is part of why clients choose you. Bending that process to fit a product means giving up something you charge for. The second is when the off-the-shelf option technically fits but only after a stack of integrations, plugins and manual steps hold it together. That arrangement has a maintenance cost too, and it is usually invisible until something in the chain updates.
The question worth asking is not whether custom is more expensive than a licence. It is what the workarounds are already costing, and who is currently paying that in unrecorded hours.
Building it without stopping the business
We do not attempt a full replacement in one release. The first delivery covers one process end to end and goes into real use, because a narrow system people actually use tells you far more than a complete specification does.
From there each module is prioritised against what the previous one revealed. Historical data is migrated in stages, and where a mistake would be expensive the old process runs in parallel for a while. This is slower on paper than a single cutover. It also means no date on which your operations depend on everything being right at once.
Living with it afterwards
A system you own for years is a different object from one you buy for a quarter. We choose boring, well-supported technology for exactly this reason, keep the data model comprehensible, and write down the decisions that would otherwise only exist in the heads of whoever was in the room.
You get the repository, the infrastructure and the documentation. We stay available for the changes that follow, because a system that reflects a living process will need them. The goal is a tool that keeps being useful as the company changes, rather than one that has to be replaced the next time the process does.
What you get
Order, project and production management
One record per job, with the statuses your team already uses in conversation made explicit in the system. Everyone sees the same current state instead of reconstructing it from messages.
Internal operational dashboards
Views built for the questions your team asks daily, such as what is late, what is unassigned and what is waiting on a decision. Numbers come straight from the underlying records, so there is nothing to compile by hand.
Document workflow and approvals
Requests move through defined approval paths with a full history of who approved what and when. Approvers get what they need to decide without opening five other tools.
Planning of work, resources and deadlines
Capacity, assignments and dates in one schedule, with conflicts surfaced when they are created rather than discovered the week they bite.
Roles and permissions
Access is scoped to what each role actually needs. This matters most when the system holds client data, pricing or payroll-adjacent information.
Migration from your current files
We import the history that is worth keeping from your spreadsheets and legacy tools, and agree explicitly on what does not come across.
How we work
- 01
Map the process as it runs today
We sit with the people doing the work and follow one real job from start to finish, including the informal steps nobody documented. The exceptions are usually where the value is, and they are always where naive systems break.
- 02
Agree the data model
What counts as an order, a client, a task, a stage. This sounds abstract but it is the decision that determines whether the system can answer your questions in two years, so we settle it before writing screens.
- 03
Build the first working module
One process end to end, in production, used by real people. A narrow system that is genuinely used beats a complete one still in review.
- 04
Migrate and run in parallel
Historical data is imported and, where the risk warrants it, the old way runs alongside the new one for a period so nothing depends on a single cutover date.
- 05
Extend and maintain
Later modules are prioritised against what the first one taught you. We hand over documentation and access, and stay available for changes as the process evolves.
Tools and technology
Where a solid open-source tool exists, we choose it over a closed one. No lock-in to a single vendor, and costs you can actually predict.
- TypeScript
- Next.js
- React
- Node.js
- PostgreSQL
- Supabase
- Prisma
- Redis
- Metabase
- Docker
- Playwright
- Vercel
Frequently asked questions
Related work
More services in this category
Web Applications and Online Tools
A web application runs wherever your clients and team already are, in a browser, with nothing to install and one version to maintain.
E-commerce Systems
Online sales is more than a storefront. Most of the work sits in the processes behind it, and that is usually where the manual handling and the errors accumulate.
Integrations and Process Automation
If data lives in several tools and someone has to move it between them by hand, that work can be done by the systems themselves, reliably and without the errors that copying introduces.
Read testimonials from companies that trusted us
Delivered well ahead of the deadline.
ZanReal's individual approach is impressive.
Knowledge and business intuition make them a valuable partner.
Quick solutions that reduced costs by 99%.
Latest
Technical guides, security insights, and what we've learned building with AI.
Ready to move your process out of spreadsheets?
Message usDescribe the process you still track by hand, orders, approvals or planning, and we will suggest which module to build first.
Can't keep up with changes in AI world?
Let us do the heavy lifting. Every week we distill the most important AI developments into a focused 5-minute briefing — so you stay ahead without the noise.
Find out more