• Working worldwide
  • 14 years of development experience
info@deviec.com
DEVIEC
Start your project

Service

When off-the-shelf software does not fit the job

Some requirements are not a website. They are a portal, a dashboard, a booking engine or a workflow that three departments depend on. We build those, in plain PHP or Laravel, scoped through discovery rather than guessed at.

  • Client portals, staff dashboards and internal tools
  • Booking, quoting, calculation and approval workflows
  • Integrations between systems that were never designed to talk
  • Fixed-price discovery before any build commitment
Plan your solutionAll services
A developer working through application logic at a desk with a monitor

When do you need custom development rather than a website?

When the thing you are describing has users who log in, data that changes state, rules about who can do what, and a process that has to be followed in order. A content management system can be bent into that shape, but it becomes fragile and slow. If your requirement involves roles, permissions, records moving through stages, or calculations that drive decisions, it is an application, and building it as one is usually cheaper over its life.

  • Users, roles and permissions rather than just pages
  • Records with a lifecycle, not just content with a publish date
  • Rules and calculations that must be right every time

What we build

Typical custom systems

Each of these is a real category of work rather than a hypothetical. The specifics are always different; the shape is not.

  • Client portals

    A logged-in area where clients see their own documents, job status, invoices or reports, without a phone call.

    • Role-based access
    • Document handling
    • Notification rules

  • Staff dashboards

    One screen that shows the state of the operation, replacing a spreadsheet that three people update by hand.

    • Live operational data
    • Filtering and export
    • Audit trail

  • Booking and scheduling

    Availability, capacity and rules that reflect how you actually schedule, including the awkward exceptions.

    • Availability logic
    • Capacity rules
    • Confirmation workflow

  • Quoting and calculators

    Pricing logic that produces the same answer every time, exposed to customers or kept internal.

    • Rule engine
    • Version control on pricing
    • PDF or email output

  • Approval workflows

    Records that move through defined stages with the right person notified at each one, and a record of who did what.

    • Stage transitions
    • Permissions
    • Full history

  • System integrations

    Getting your website, CRM, accounting package and operational software to agree on the same facts.

    • API integration
    • Scheduled synchronisation
    • Failure handling

How we scope it

Discovery first, and it is a paid piece of work

Custom projects fail when they are quoted from a conversation. The requirement always contains something nobody mentioned: a rule with three exceptions, a report someone runs every Friday, a system that must keep working during the transition.

So we run discovery as its own fixed-price engagement. It produces a written specification, a data model, a technical approach, a risk list and a build estimate. You own that document. If you decide to build it with someone else, or not build it at all, that is a legitimate outcome and you leave with something useful.

  • A written functional specification, not a proposal
  • Data model and integration map
  • Identified risks and the decisions that resolve them
  • A build estimate you can take to another supplier if you want to
A wall of sticky notes mapping out a system workflow during planning

Delivery

How a custom build runs

  1. 01

    Discovery

    Users, processes, rules, data, integrations and the constraints that will not move.

    You receive: Written specification and estimate

  2. 02

    Architecture

    Data model, permission model, integration approach and environment plan.

    You receive: Technical design

  3. 03

    Build in stages

    Delivered in working increments you can use and react to, rather than one reveal at the end.

    You receive: Reviewable staging releases

  4. 04

    Test

    Functional testing against the specification, plus security, permissions and failure-path checks.

    You receive: Test results and defect list

  5. 05

    Migrate and launch

    Data migration, user setup, training and a planned cutover with a rollback path.

    You receive: Live system and training

  6. 06

    Support

    Defined support arrangement, monitoring, error logging and an agreed route for changes.

    You receive: Support agreement

Stack

What we build custom systems with

Application

  • PHP
  • Laravel
  • CodeIgniter
  • Queues and scheduled jobs
  • Authentication and roles

Data

  • MySQL
  • MariaDB
  • Migrations
  • Reporting queries
  • Import and export routines

Interface

  • Server-rendered views
  • Tailwind CSS
  • Vanilla JavaScript
  • Accessible forms
  • Responsive tables

Integration

  • REST APIs
  • Webhooks
  • Third-party SDKs
  • Scheduled synchronisation
  • Retry and error handling

Questions

Custom development questions

How much does a custom system cost?
It depends almost entirely on how many rules and integrations it contains, which is exactly what discovery establishes. We will not give a build figure before discovery, because a number given at that stage is a guess, and guesses on custom work are wrong by multiples rather than percentages.
Can you build on top of our existing system?
Often, yes. Extending a system that works is usually better than replacing it. We will assess whether the existing codebase can carry the new requirement safely, and tell you plainly if it cannot — inheriting a codebase that should be replaced helps nobody.
What happens if we want to change the requirement mid-build?
Changes are normal. They go through a written change process: what it is, what it affects, what it costs and what it does to the schedule. Agreed changes are added to the scope; the point is that nothing gets absorbed silently and surfaces later as a delay.
Who owns the code?
You do, on final payment, along with the repository and documentation. We do not retain the code or make it dependent on infrastructure only we control.
Do you provide ongoing support for custom systems?
Yes, under a defined support arrangement covering response expectations, monitoring, error logging and an agreed allocation of development time. Custom systems need a named owner after launch; if it is not us, we will make sure whoever takes it on has what they need.

Related services

Often paired with this

Have a requirement that does not fit a website?

Describe the process, who uses it and what goes wrong today. We will tell you whether it needs a custom build or something simpler.

Plan your solutionSee all services