Internal business applications
The tools a specific team needs to do specific work - replacing the spreadsheet that became load-bearing.
Custom Enterprise Software
Software for problems that don't fit inside a standard product.
Another subscription sometimes does not solve the actual problem. The workflow that makes your business work is usually the one no product was designed for.
ProjectData designs and builds custom enterprise software: internal business applications, mission-critical operational platforms, workflow systems, enterprise integrations, cloud applications and legacy modernisation - normally as a focused layer over the systems a company already runs.
The decision
When custom software makes economic sense.
Not as a philosophy. As a calculation about where cost and constraint actually sit.
-
The workflow is genuinely yours
How you price, allocate, schedule, fulfil or underwrite is specific to your business and part of why customers choose you. Forcing it into a generic product removes the advantage and adds workarounds.
-
The integration is the product
The systems exist; the problem is that they do not talk to each other. The thing that needs building is the orchestration between them, and no vendor sells that for your particular combination.
-
Generic software is creating manual work
People export, re-key, reconcile and chase because the standard tool does not cover a step. That labour has a cost, and it usually grows with volume.
-
It is a strategic internal platform
The system is core to how the company operates or differentiates. Owning it - the data, the logic, the roadmap - matters more than the speed of buying.
-
A legacy system is the constraint
An important process is limited by something old that cannot change fast enough, and the business is designing around the software instead of the other way round.
-
The last 20% is the part that matters
Off-the-shelf covers most of the process. The remaining part is where the margin, the risk or the customer experience actually lives.
When we will tell you to buy instead
If a mature product covers the process, the workflow is not a differentiator, and the integration burden is manageable, buying is the better decision. We would rather say that at the start than build something you should not own.
Shape of the work
Custom rarely means rebuilding everything.
In most engagements the ERP stays, the CRM stays, and what gets built is the missing layer between them.
- ERPStays as system of record
- CRMStays as customer record
- WMS / POSStays operational
- LegacyWrapped, not replaced
- SaaSKept where it works
Custom layer The workflow, the orchestration and the interface that did not exist.
Capabilities
What we build.
From internal tools used by a single team to platforms the business cannot trade without.
Mission-critical platforms
Systems where downtime or a wrong result has real consequences, built with the operational rigour that implies.
Workflow & process systems
Multi-step, multi-role processes with approvals, states, exceptions, audit trails and handovers between departments.
Enterprise integrations
Reliable connections between ERP, CRM, WMS, POS, e-commerce, finance and third-party systems - including the unglamorous failure handling.
Cloud applications
Applications designed for the environment they run in, with deployment, observability and cost behaviour considered from the start.
Legacy modernisation
Incremental replacement of the parts that constrain the business, without a high-risk rewrite of everything at once.
Complex platform engineering
Systems with demanding scale, reliability or data requirements, where architecture decisions determine whether it works in three years.
Customer-facing systems
Portals, booking and ordering systems connected to the operational reality behind them, rather than to a separate copy of the truth.
Principles
Built to be owned, not to create dependency.
- Your repositories, your cloud accounts, your code
- The smallest system that solves the problem properly - scope discipline is a design skill
- Working software in front of real users early, not a single delivery at the end
- Documentation and handover treated as part of the build
- Boring, well-supported technology unless there is a specific reason to do otherwise
- An explicit answer to “who maintains this in two years” before we start
FAQ
Common questions about custom software.
When should a company build custom software instead of buying SaaS?
Buy when the process is standard and the product is mature: accounting, payroll, email, helpdesk, core ERP. There is no advantage in owning a worse version of something thousands of companies use.
Build when the workflow is genuinely specific to how you operate and that specificity is part of why you win; when the gap between what the product does and what you need is being filled by people and spreadsheets; when the integration between several systems is the actual product; or when licence and per-seat costs for a workflow you barely use have overtaken the cost of owning it.
Can ProjectData integrate existing enterprise software?
Yes - it is most of what we do. We integrate through APIs where they exist and through databases, files, message queues or middleware where they do not, including with older systems that were never designed to be connected.
The engineering discipline that matters here is failure handling: what happens when the other system is down, slow, or returns something unexpected. Integrations that only work on the happy path create more manual work than they remove.
Does custom software require replacing current systems?
Usually the opposite. The most common shape of our work is a focused layer that sits on top of existing systems and makes them work together - keeping the ERP as the system of record while giving a specific team the workflow they actually need.
Replacing a core system is a large programme with its own risk profile. It is occasionally the right answer, but it should be a deliberate decision, not the default response to a workflow problem.
How long does a custom software project take?
Scope, the number of integrations and the complexity of the workflow determine delivery time - we will not quote a standard timeline, because the honest answer depends on what the system has to do and which systems it has to talk to.
What we can commit to is shape: we scope the first useful version deliberately small, put it in front of real users early, and extend from there rather than delivering everything at the end.
Who owns the code?
You do. Source code, infrastructure definitions and documentation belong to the client, in your repositories and your cloud accounts where you want them there.
We build systems your own engineers can take over. Handover is a design constraint from the start, not a final phase.
What happens after launch?
Business software is never finished - processes change, systems around it change, and usage reveals what the design missed. We agree the support model before launch: whether your team takes over, we continue under an ongoing arrangement, or something in between.
What we avoid is a system nobody can maintain. That is a design failure, regardless of who is holding the pager.
Where is your process working around the software?
Describe the step where people compensate for the system. That is usually where a focused piece of software pays for itself.