Custom software – platforms, integrations, configurators, middleware – is where projects are most unique and where problems are hardest to predict in detail. In general, though, the same patterns keep appearing. We have delivered fewer custom software projects than websites, so this list is based on our team's experience rather than statistics.
1. Scope that grows during development
The most common problem in our experience. The idea evolves while it is being built: a new user role, an extra report, a messaging feature "that users will expect". Each addition is reasonable. Together they double the project.
How we handle it: every project has an explicit version-one scope and an equally explicit out-of-scope list. New ideas go on a version-two list, not into the current phase. When something truly must be added, we re-plan openly: what moves out, or how the timeline changes.
2. Business rules defined too late
Software needs rules: who can see what, what happens when a payment fails, how a booking is cancelled, which status comes after which. Often these rules are only defined when the client sees the first working version.
How we handle it: we write the main rules down during scoping as simple scenarios ("when a user does X, then Y happens") and get them confirmed before building. Remaining open questions are tracked with owners.
3. Missing assets block progress
Some features cannot be built without input from the client. In a 3D product configurator project, CAD files had to be converted into web-ready 3D models and materials created as textures; the asset count scales with every product and finish. Nothing could be rendered until the files arrived.
How we handle it: we identify asset dependencies in scoping, request them first, and build other parts of the system while waiting.
4. APIs fail silently
Integrations with external services – lead sources, couriers, CRMs, listing systems – break when a key expires, a service is down or the API changes. The worst case is a silent failure: data simply stops flowing and nobody notices.
How we handle it: error handling and alerts are part of every integration. In automation workflows, error-trigger steps notify the team when something fails, rather than failing quietly.
5. Emails that never arrive
Platforms send many emails: confirmations, notifications, password resets, receipts. In one platform build, QA found that payment confirmation emails were not arriving. Customers would have paid without receiving confirmation.
How we handle it: every system email is part of the test plan, sent through an authenticated transactional email service, and checked in real inboxes.
6. Paid APIs and running costs
Features that call external paid services – data enrichment, AI, maps, SMS – have per-use costs that grow with users. A prototype that is cheap to run with ten users can be expensive with a thousand.
How we handle it: we estimate running costs during scoping, minimise paid API calls, and cache where possible.
7. Built in one environment, deployed in another
Systems developed in our environment later move to the client's server, with different versions, permissions and network rules.
How we handle it: we clarify the target environment early, use containerised setups where possible (for example Docker with a reverse proxy), and plan the migration as its own step.
8. Ownership and IP questions
In larger projects, it matters who owns what: project-specific code, pre-existing components, third-party libraries.
How we handle it: contracts define ownership per phase, distinguishing background technology from project deliverables.
Summary
| Problem | Our standard measure |
|---|---|
| Growing scope | Out-of-scope list, version-two backlog |
| Late business rules | Written scenarios confirmed before build |
| Missing assets | Dependencies requested first |
| Silent API failures | Error handling and alerts |
| Missing system emails | Transactional email, full email test plan |
| Running costs | Cost estimate, minimal paid calls |
| Environment changes | Early clarity, containers, planned migration |
| Ownership | Defined per phase in the contract |
Communication rhythm
A problem that sits underneath several of the above is irregular communication. Long silences followed by large batches of feedback lead to surprises on both sides. On custom projects we work with a fixed rhythm: a short weekly update with what was done, what is next and which decisions are open, plus a demo of working software at the end of each phase. Clients see progress early, and misunderstandings surface while they are still cheap to fix.
The common thread
Almost none of these are purely technical. They are about clarity: what exactly should be built, with what inputs, under which rules, running where, owned by whom. The earlier those questions are answered, the smoother a custom project runs.
FAQ
How do you prevent scope creep without being rigid?
By making changes visible. New ideas are welcome; they are discussed and placed in a phase, rather than added silently.
What if we do not know all the rules yet?
That is normal. We start with the core journey, confirm rules for it, and track open questions. Later phases fill in the rest.
Do you test with real users?
We test all roles and scenarios internally and recommend a small group of real users before a wide launch.
Why do custom software projects need an out-of-scope list?
Because new ideas appear as soon as people see working software. In our experience, writing down what is not in the first version is what keeps an MVP on schedule.
How do you test custom software before launch?
On a staging environment with real sample data, followed by a test round with the people who will use it daily. Edge cases from real data find more issues than scripted tests alone.
Planning a custom software project?
If you want a realistic plan for your own project, book a short call with our team and we will walk you through the phases, what we need from you and where projects like yours usually lose time. You can also browse finished work in our custom software portfolio.
Comments