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

Service

Custom plugins and themes, built to be inherited

When the functionality you need does not exist as a maintained plugin — or exists in three plugins that each do a third of it — we build it properly, document it, and write it so the next developer can read it.

  • Custom plugins for functionality that must survive a theme change
  • Custom themes built to WordPress coding standards
  • Replacement of abandoned or bloated third-party extensions
  • Documentation and update path handed over with the code
Discuss a buildAll services
A close view of a circuit board representing structured technical components

Should functionality go in a plugin or a theme?

Anything that must keep working if the design changes belongs in a plugin: custom post types, integrations, business logic, shortcodes and admin tools. Anything purely presentational belongs in the theme: templates, layout, styling. The common failure we inherit is business logic buried in a theme's functions file, which means the site's functionality dies the day someone changes the design.

  • Plugin: data structures, integrations and behaviour
  • Theme: templates, layout and presentation
  • The split is what makes a redesign a design job rather than a rebuild

What we build

Typical plugin and theme work

  • Custom plugins

    Purpose-built functionality: custom post types, admin screens, business rules, front-end features and integrations.

    • Built to WordPress standards
    • Namespaced and self-contained
    • Documented and versioned

  • Custom themes

    Templates written for your content model, with no page-builder dependency and no purchased-theme inheritance.

    • Per-template layouts
    • Editor-safe content fields
    • Accessible and responsive

  • Extension replacement

    Replacing an abandoned, insecure or oversized plugin with a lean equivalent that does only what you use.

    • Feature audit first
    • Data preserved
    • Reduced page weight

  • Integration plugins

    Connecting WordPress to a CRM, ERP, booking system or internal API, with proper failure handling.

    • API integration
    • Scheduled synchronisation
    • Error logging

  • Admin tooling

    Internal screens, bulk operations and reports that make a large site manageable by the people who run it.

    • Custom admin screens
    • Bulk actions
    • Capability checks

  • Code review

    Assessment of custom plugins you already have, for security, performance and maintainability.

    • Security review
    • Performance profiling
    • Written findings

Standards

How we write WordPress code

These are not preferences. They are the difference between code you can hand to another developer and code that has to be replaced.

Security

  • Output escaped according to context, every time
  • Input sanitised and validated on the server
  • Nonces on every state-changing request
  • Capability checks before any privileged action

Structure

  • Prefixed or namespaced to avoid collisions
  • Hooks and filters rather than core modification
  • Assets loaded only where they are used
  • Uninstall routine that cleans up after itself

Maintainability

  • Readable naming and inline documentation
  • Semantic versioning and a changelog
  • Translation-ready strings
  • No dependency on a specific theme

Before we build

We will tell you when not to build it

Custom code is a permanent commitment. Somebody has to maintain it, test it against every WordPress release and understand it when you eventually change developer. That is entirely worth it for functionality central to your business, and rarely worth it for something a well-maintained plugin already does.

So the first thing we do is check whether the thing already exists. If a maintained plugin covers eighty per cent of it, the honest answer is usually to use that plugin and build only the missing twenty per cent. We would rather write a smaller invoice than sell you a maintenance liability.

  • Existing solutions checked before custom work is quoted
  • Custom code kept to the part that genuinely does not exist
  • Maintenance implications stated before you commit
  • Ownership of the code transferred to you on completion
Program code shown close up on a screen during a code review

Questions

Plugin and theme questions

Will the plugin survive WordPress updates?
That is what building against documented hooks and APIs is for, rather than modifying core or depending on another plugin's internals. Nothing is permanently future-proof, which is why we hand over a versioned, documented plugin and recommend a maintenance arrangement that includes testing against new WordPress releases.
Can you take over a custom plugin someone else wrote?
Usually. We start with a code review covering security, performance and structure, and give you a written assessment of whether it is safe to build on. Occasionally the answer is that it should be replaced, and if so we will explain exactly why rather than just asserting it.
Do you sell your plugins publicly?
No. Work is built for the client who commissioned it, and the code is transferred to them. That means no licence to renew, no feature you rely on being removed in a future public release, and no shared codebase carrying other people's requirements.
Can a plugin replace several we currently pay for?
Sometimes, and we will do the arithmetic honestly. If three subscriptions cost more over two years than one focused build plus its maintenance, replacement makes sense. If not, keeping the subscriptions is the better call and we will tell you so.
What do we get at handover?
The source code, a written description of what it does and how it is structured, a changelog, and any configuration notes needed to install it elsewhere. The intention is that another competent developer could pick it up without contacting us.

Related services

Often paired with this

Need functionality that does not exist yet?

Describe what it has to do and what you have tried. We will tell you whether it needs building, or whether something maintained already does the job.

Discuss a buildSee all services