The system your roadmap keeps postponing.
Discovery through production for customer-facing and internal applications — including the unglamorous parts: authentication, audit trails, reporting, permissions and data migration.
Overview
Why application projects fail after the demo
Anyone can show you a working application early on. What decides whether it survives contact with real users is the part nobody demonstrates: role-based permissions, audit history, error handling, reporting, and migrating the data that already exists in spreadsheets.
We estimate that work explicitly and build it early. Adding an audit trail to a system that is already live is the same work carried out under worse conditions, at greater cost, at the point in a project where there is least room to absorb either.
Scope of work
What the service covers
Customer-facing and internal systems, with role-based access, reporting and an audit trail present from the first release.
Cross-platform by default, with native builds where the product genuinely depends on platform capability or hardware.
Systems that integrate with ERP, CRM and finance, designed around the integration constraints you already have.
Where no product fits the process, and adapting the process to a product would cost more than building.
Outcomes
What you receive that a prototype does not include
Permissions, audit, error handling and reporting appear in the estimate, rather than in a later phase you discover after committing.
Real data moved in a full rehearsal before cutover, so go-live is not the first time the migration has been attempted.
Architecture notes, runbooks and decision records committed alongside the code, so onboarding a new developer does not require us.
The people who built it are the people on the support rota. There is no handover to a separate maintenance vendor who has never seen it.
What a demo shows, and what production requires
Prototypes are inexpensive because they omit the right-hand column below. We estimate it explicitly, which is why our figure is often higher than the one beside it, and why our dates tend to hold.
One user on the happy path, signed in as an administrator
Role-based permissions, invitations, deactivation and delegated access
A form that saves a record
Validation, optimistic locking, audit history and soft deletes
A chart drawn from sample data
Reporting at production volumes, export, and scheduled delivery
An empty database
Existing records migrated from spreadsheets, rehearsed before go-live
Built in the first sprints, not a later phase
Who changed what, when, and what it held before. Adding this to a live system afterwards is markedly more expensive and more disruptive than building it in.
Designed against your actual organisation chart, including the exceptions people tend to leave out of the requirements.
Structured logging and alerting, so failures surface to us before a user reports them.
A repeatable import that can be run again as often as needed, rather than a single script written once and discarded.
Source code, cloud accounts and repositories are registered in your name from the outset, as on every Candela engagement.
Delivery process
How engagements are run
Process mapping, integration inventory, data audit and a written problem statement both sides sign off.
Domain model, architecture, permission model, integration contracts and a costed release plan.
Two-week sprints with a Friday demo, staging open to your team throughout, and the audit and reporting layers built early.
Load and security testing, migration rehearsal on production data, then cutover with a rollback path.
Managed support with named engineers, monitoring, and a prioritised iteration backlog you own.
Tools and platforms
Chosen around your operations team, not ours
Java with Spring or .NET Core where you already run a Java or Microsoft estate, because your own people can support it. Node.js where iteration speed matters more than fitting an existing estate. PostgreSQL unless there is a specific reason for something else.
We avoid: rewriting a working backend in a different language
See the full technology page →In practice
Payroll and attendance across three locations, on one system
Six spreadsheets and an ageing system held employee records, attendance, payroll inputs and leave requests between them. Shift rules differed by site and none were documented, so we wrote them down before configuring anything, then built a single platform with employee self-service and migrated in stages with on-site training.
estimate
Fixed price where discovery and architecture are complete and the scope is genuinely knowable. Time and materials where the product is still being defined. We will tell you which applies before you commit, rather than quoting a fixed price on a scope that cannot yet support one.
Yes, following a review. We read the code, the deployment setup and whatever documentation exists, then set out what is worth keeping, what needs replacing, and what can be left alone for the time being. Occasionally the conclusion is that rebuilding costs less than repairing, and we would rather say so at the start than once the repair is underway.
Sprint planning is where changes are absorbed. Anything that alters the release plan or the cost is written up and re-approved before the work begins, so a change never reaches you first as a line on an invoice.
You do, from the first commit. Repositories, cloud accounts and domain registrations are in your name and we work inside them. There is nothing to transfer at the end, because none of it was ever ours.
Find out whether this needs building or configuring
Bring the spreadsheet, or the system you have outgrown, to the call. One conversation is usually enough to establish whether what you are describing is a build, or a configuration of something that already exists. We would rather tell you it is the second.