When a custom widget is the right answer
- A repeating block driven by real content — a case-study grid, a team list, a product feed — that should update the moment a new item is published, not when someone remembers to duplicate a container.
- A design section stock controls can’t reproduce without a stack of five nested containers and a page of overrides.
- Something the client must edit but must not be able to break. Fields in a panel, not a layout they can pull apart.
- A pattern used across many pages where you want one place to change it.
- Performance pressure — a purpose-built widget emits the markup the design needs and nothing else.
What a widget from me includes
- Full Content and Style tabs with native Elementor controls — typography, colour, spacing, responsive values — so it behaves like a first-party widget, not a black box.
- Responsive controls on anything that needs to change per breakpoint.
- Repeaters where items are variable in number.
- Escaped, translatable output and sanitised input throughout.
- Packaged as a plugin, so it survives theme changes and updates independently.
- Readable, commented code you or any other developer can pick up later.
How it works
- You describe the section — a screenshot, a Figma frame, or a link to something similar.
- I come back with the control list: exactly which fields your editors will see, before any code is written. This is the part worth getting right, because it decides how the site feels to run.
- I build and test it on staging, against your real content rather than placeholder text.
- You get the plugin file, the source, and a short note on how to extend it.
Built on this site
The portfolio you’re reading runs on a custom plugin of exactly this kind. Its widgets — a hero, a proof-stats panel, a case-study grid pulling from a custom post type, and a section header — replace what would otherwise be dozens of hand-built container stacks. The case studies are populated by the grid widget: publishing a new one makes it appear, with no layout editing at all.
The reasoning behind building this way, from a handover point of view, is in my notes on Elementor client handoff.
What drives the price
Quoted per widget as a fixed price once the control list is agreed — scope first, number second, no hourly meter. Four things decide where a widget sits:
- Presentational or content-driven. A widget that renders fields someone types in is a small job. One that queries a custom post type, with filtering, ordering and pagination, is a substantially larger one.
- How many controls the editor needs. Every control is a small piece of design work as well as code — and a panel with forty options is worse for your team than one with eight well-chosen ones. I’ll push back on scope here, not inflate it.
- How much styling is exposed. Hard-coding the design is cheapest. Exposing typography, colour and spacing as native Style-tab controls costs more and is usually worth it, because it stops the next change coming back to me.
- Whether it has to integrate with something you already run — a CRM, a booking system, an inventory feed.
Describe the section and you’ll get a control list and a real number, not a range.
