Get the Umbraco site that actually does what your business needs it to do.
Off-the-shelf themes and stock plugins only stretch so far. When your requirements don't fit the mould, we build custom Umbraco functionality that fits your business, not the other way round.
If your requirements don't fit a template, neither should your build.
Whether you're the CTO scoping technical feasibility, the Digital Lead who inherited a platform nobody else understands, or the Marketing Director justifying spend to a sceptical board, custom development only works if it's built to be handed over, not locked to one supplier.
We scope every custom build against your existing site architecture first, then develop property editors, content types or integrations using Umbraco's own extensibility points, never bolted-on hacks that break at the next upgrade, and never anything only we can maintain. That's Umbraco development services built around your actual requirement, custom solutions rather than generic website design or off-the-peg website development stretched to fit a problem it wasn't built for.
Why Teams come to us?
“Our site can't do the thing we actually need it to do.”
We build the specific property editor, content type or integration your workflow needs, using Umbraco's own extension points rather than a hacky workaround.
“Every plugin we try is a compromise, not a fit.”
Off-the-shelf packages get evaluated against your actual requirement first. If nothing fits properly, we develop bespoke functionality instead of forcing a mismatch.
“We've got a brief no template can handle.”
We scope your requirement against Umbraco's actual capabilities, then build exactly what's missing, whether that's one property editor or a full custom package.
“We've outgrown our CMS and can't untangle it.”
Migrations, integrations, custom features, whatever the mess looks like, we've untangled worse. You don't need the technical answer before you call us, just the problem.
The Gecko Way™
Our approach to successful projects
Custom development starts with the requirement, not the platform. We sit down with whoever actually knows the process, your ops lead, your CTO, sometimes someone from finance or compliance, and map out exactly what the site needs to do that it currently can't. For an existing Umbraco build, that means reviewing the current version, any legacy custom code already in place, and where the technical debt sits. For a new build, it means working out early whether the requirement is genuinely custom or whether a well-configured content type gets you there without writing a line of bespoke code. Either way, nothing gets built until we understand the actual business problem behind the brief. We also look at the wider content architecture and the user experience your editors need within Umbraco CMS day to day, not just the specific feature that prompted the conversation.
Not every custom requirement needs the same answer. Sometimes it's a single custom property editor, sometimes it's a bespoke content type or element type, sometimes the right call is a properly packaged plugin your team can reuse elsewhere, and sometimes it's an integration with a system you already run. We weigh each option against your Umbraco version, your upgrade path, and how much ongoing maintenance it'll actually create. This is also where we give you a number that holds. No "we'll firm it up later" once you've had to defend a budget internally. If something's genuinely hard to scope precisely, we say so upfront rather than let the invoices creep once you've signed off. We'll also confirm early which of Umbraco CMS's own development tools and deployment workflows the build needs to sit inside, so nothing gets developed outside the way your team already works.
Build happens inside Umbraco's own extensibility points, not around them. That means composers to hook into the pipeline properly, property editors registered the way Umbraco expects, and document types and element types modelled so content editors can actually use what we've built without a manual. If the brief calls for a full package, we develop it as one, versioned and structured, rather than a scattering of files bolted onto the site. Everything is built and tested against your actual content and your actual traffic patterns, not a blank demo install. We'd rather catch an edge case in a test environment than have your team find it live. Where it's needed, that includes working with Umbraco's own MVC concepts and Composition, using Dependency Injection to wire up services cleanly rather than hard-coding them into a property editor. Backoffice extensions, including custom section views and components from Umbraco's own UI Library and UI utilities, get built the way Umbraco intends its extension system to be used, not hacked in through global stylesheets. And where a project calls for it, that stretches to headless architecture too: serving content through Umbraco's Content Delivery API so it runs as a headless CMS, feeding an API-driven architecture rather than a traditional Razor front end.
Custom code is only useful if someone other than us understands it. Every build comes with documentation written for a human, not just code comments, covering what we built, why we built it that way, and how to change it later. If you've got an internal developer or a technical lead, we walk them through it directly rather than leaving them to reverse-engineer our work from a git log. This matters because we hear it constantly: being the only person who understands how the site actually works is exhausting and risky, whether that's you or whoever comes after you. Custom development that only we can touch isn't custom development, it's a dependency.
Once it's live, custom code needs looking after differently to a standard build, because there's no community package maintainer keeping it compatible with the next Umbraco release. We test custom work against new versions as they land, not just when something breaks, so an upgrade from 13 to 17 doesn't quietly take out the one feature that mattered most. If you're on a support agreement, this happens as a matter of course. If you're not, we'll still tell you honestly when something needs attention rather than letting it rot until it fails in front of a client or a board. It's your code and your site, but we stay close enough to catch problems before you do. That includes performance tracking and flagging compatibility issues before they become a problem, whether the site sits with us or your existing hosting provider, and keeping security features up to date as part of the same routine. It's the support and maintenance that helps you stay ahead of the next Umbraco release, not scrambling to catch up once it lands.
What's Included in Custom Umbraco Development
Custom Property Editor Development
When the built-in data types don't match how your content actually works, we build a property editor that does. That could be a data picker pulling from an external source, a specialist input type for a regulated industry, or an editor experience simpler than the generic options Umbraco ships with.
We register editors properly, either through a package manifest or as part of a wider composer, so they behave like native Umbraco functionality rather than a bolt-on. Where the stored data needs converting into something usable on the front end, we write the value converter too, so content editors get a sensible interface and your templates get clean, structured data to work with.
That covers everything from a bespoke WYSIWYG editor tailored to how your content team writes, to a custom media assets picker that pulls from your own library instead of Umbraco CMS's default view.
Bespoke Content Type & Data Modelling
Most Umbraco projects that feel wrong on the back end come down to content modelling, not code. We design document types and element types around how your team actually creates and manages content, not a generic blog-and-page structure stretched to fit.
That might mean building composition-based content types that share structure across a product catalogue, or element types purpose-built for the block editors your team uses daily. Good modelling now is what stops a rebuild in two years. We map data relationships properly from the start, so search, filtering and any future integration work has something sensible to query against, rather than years of workarounds bolted onto a structure that never quite fit.
Good content architecture and content model design are what make content creation genuinely easier for your team, not just tidier behind the scenes for us. We'll typically build in the fields your content management system needs for search engine optimisation too, custom URLs and meta descriptions included, rather than leaving that as an afterthought bolted onto a generic content type.
Package & Plugin Development
Sometimes the right answer isn't one feature, it's a properly built package: versioned, documented and installable, so it can be reused across a site estate or handed to another developer without a walkthrough. We build these as genuine Umbraco packages, structured with a clear manifest, rather than a folder of loose files that only makes sense to the person who wrote them.
This is Umbraco CMS development in the fullest sense, C# and .NET underneath, a considered interface on top, and none of the plugin sprawl that ends up costing more to untangle than it would have cost to build properly the first time. If an existing plugin gets you most of the way there, we'll say so rather than rebuild it from scratch for the sake of it.
Think of it as extending the development tools already in your Umbraco toolkit: custom plugins and custom packages built to the same standard as anything shipped by Umbraco itself.
Third-Party & API Integrations
Your Umbraco site rarely needs to work in isolation. We build integrations with the systems your business already depends on: CRM platforms, booking and payment providers, finance systems, or an internal API nobody outside your business has ever had to explain to an agency before. Each integration is built to fail gracefully, not silently, so if a third-party system goes down, your website doesn't go down with it.
Where sensitive data moves between systems, we build with that in mind from the start rather than patching security in afterwards. The result should feel invisible to whoever's using your site. They just see the right information in the right place, without needing to know how many systems are talking to each other behind it.
That covers CRM and finance systems as much as it does e-commerce platforms, payment gateways or stock feeds, and any system integration services your business already relies on. Third-party integrations like these get built with proper security features and data handling discipline from the start, not treated as a bolt-on afterthought.
Custom Block Editors & Templates
Umbraco's Block List and Block Grid editors cover a lot of ground, but a genuinely custom layout or interaction usually needs a custom view built for it. We develop bespoke block views so your content editors get an experience that actually matches what they're building, not a generic preview that looks nothing like the finished page.
This is where a lot of Umbraco web development projects stand or fall: the front end can look brilliant, but if the person updating it dreads opening the page, that experience erodes fast. We build templates and block views together, so what your editors see in the backoffice is a genuine reflection of what visitors see on the site, not a guess.
We'll also plan Umbraco templates and wider template strategies alongside the block editors themselves, so the content editing experience your team gets in the Umbraco backoffice actually matches the page they're building, not a separate front-end decision made without them.
Umbraco Upgrade-Safe Custom Code
Custom code that only works on one Umbraco version is a liability waiting for the next upgrade cycle. We build and test custom functionality with the current wave of Umbraco 13 to 17 releases in mind, so what we deliver today doesn't quietly break the first time you upgrade.
If you've inherited custom code from a previous developer or agency, we can also audit and modernise it, identifying what's still doing a genuine job, what's dead weight, and what's become a risk because nobody's touched it in years. This isn't a rebuild for the sake of it. It's making sure the custom parts of your site are as maintainable as everything else we build, so an upgrade stays a routine task, not a six-month project.
That's different to spinning up an Umbraco Starter Kit and calling the result custom. A starter kit is a fast way to get a demo site running, not a foundation for bespoke functionality that needs to survive several major upgrades. We build in performance optimisation as part of any audit too, so an ageing custom feature isn't quietly dragging down system performance as well as risking the next upgrade.
What's Included in Custom Umbraco Development
Custom Property Editor Development
When the built-in data types don't match how your content actually works, we build a property editor that does. That could be a data picker pulling from an external source, a specialist input type for a regulated industry, or an editor experience simpler than the generic options Umbraco ships with.
We register editors properly, either through a package manifest or as part of a wider composer, so they behave like native Umbraco functionality rather than a bolt-on. Where the stored data needs converting into something usable on the front end, we write the value converter too, so content editors get a sensible interface and your templates get clean, structured data to work with.
That covers everything from a bespoke WYSIWYG editor tailored to how your content team writes, to a custom media assets picker that pulls from your own library instead of Umbraco CMS's default view.
Bespoke Content Type & Data Modelling
Most Umbraco projects that feel wrong on the back end come down to content modelling, not code. We design document types and element types around how your team actually creates and manages content, not a generic blog-and-page structure stretched to fit.
That might mean building composition-based content types that share structure across a product catalogue, or element types purpose-built for the block editors your team uses daily. Good modelling now is what stops a rebuild in two years. We map data relationships properly from the start, so search, filtering and any future integration work has something sensible to query against, rather than years of workarounds bolted onto a structure that never quite fit.
Good content architecture and content model design are what make content creation genuinely easier for your team, not just tidier behind the scenes for us. We'll typically build in the fields your content management system needs for search engine optimisation too, custom URLs and meta descriptions included, rather than leaving that as an afterthought bolted onto a generic content type.
Package & Plugin Development
Sometimes the right answer isn't one feature, it's a properly built package: versioned, documented and installable, so it can be reused across a site estate or handed to another developer without a walkthrough. We build these as genuine Umbraco packages, structured with a clear manifest, rather than a folder of loose files that only makes sense to the person who wrote them.
This is Umbraco CMS development in the fullest sense, C# and .NET underneath, a considered interface on top, and none of the plugin sprawl that ends up costing more to untangle than it would have cost to build properly the first time. If an existing plugin gets you most of the way there, we'll say so rather than rebuild it from scratch for the sake of it.
Think of it as extending the development tools already in your Umbraco toolkit: custom plugins and custom packages built to the same standard as anything shipped by Umbraco itself.
Third-Party & API Integrations
Your Umbraco site rarely needs to work in isolation. We build integrations with the systems your business already depends on: CRM platforms, booking and payment providers, finance systems, or an internal API nobody outside your business has ever had to explain to an agency before. Each integration is built to fail gracefully, not silently, so if a third-party system goes down, your website doesn't go down with it.
Where sensitive data moves between systems, we build with that in mind from the start rather than patching security in afterwards. The result should feel invisible to whoever's using your site. They just see the right information in the right place, without needing to know how many systems are talking to each other behind it.
That covers CRM and finance systems as much as it does e-commerce platforms, payment gateways or stock feeds, and any system integration services your business already relies on. Third-party integrations like these get built with proper security features and data handling discipline from the start, not treated as a bolt-on afterthought.
Custom Block Editors & Templates
Umbraco's Block List and Block Grid editors cover a lot of ground, but a genuinely custom layout or interaction usually needs a custom view built for it. We develop bespoke block views so your content editors get an experience that actually matches what they're building, not a generic preview that looks nothing like the finished page.
This is where a lot of Umbraco web development projects stand or fall: the front end can look brilliant, but if the person updating it dreads opening the page, that experience erodes fast. We build templates and block views together, so what your editors see in the backoffice is a genuine reflection of what visitors see on the site, not a guess.
We'll also plan Umbraco templates and wider template strategies alongside the block editors themselves, so the content editing experience your team gets in the Umbraco backoffice actually matches the page they're building, not a separate front-end decision made without them.
Umbraco Upgrade-Safe Custom Code
Custom code that only works on one Umbraco version is a liability waiting for the next upgrade cycle. We build and test custom functionality with the current wave of Umbraco 13 to 17 releases in mind, so what we deliver today doesn't quietly break the first time you upgrade.
If you've inherited custom code from a previous developer or agency, we can also audit and modernise it, identifying what's still doing a genuine job, what's dead weight, and what's become a risk because nobody's touched it in years. This isn't a rebuild for the sake of it. It's making sure the custom parts of your site are as maintainable as everything else we build, so an upgrade stays a routine task, not a six-month project.
That's different to spinning up an Umbraco Starter Kit and calling the result custom. A starter kit is a fast way to get a demo site running, not a foundation for bespoke functionality that needs to survive several major upgrades. We build in performance optimisation as part of any audit too, so an ageing custom feature isn't quietly dragging down system performance as well as risking the next upgrade.
"When we build a custom property editor, we hand over the documentation too, so the client's own team can change it without waiting on us."
Marlon Dedakis, Lead Developer at Gecko
Custom Development Case Study
(Placeholder) [CASE STUDY NAME] came to us with a workflow no off-the-shelf plugin could handle: [BRIEF DESCRIPTION OF THE REQUIREMENT]. We built [a custom property editor / a bespoke content type / a full package] that gave their editorial team direct control over something they'd previously had to ask a developer to change every time. The result was [KEY METRIC, e.g. "X hours saved per month" or "X% faster content updates"], with documentation handed over so their own team can maintain it going forward.
Configuration is arranging what Umbraco already gives you: existing property editors, standard content types, built-in block editors. Custom development is building something that doesn't exist yet, a property editor, a package, an integration, or a content structure specific to how your business actually works. Most projects are a mix of both, and part of our job is telling you honestly which parts of your brief are configuration (fast, cheap) and which genuinely need custom code (more time, more cost, but the only way to get what you actually need). We'd rather have that conversation upfront than let scope creep in later.
We start with the requirement, not the tool. If an existing, well-maintained package genuinely does the job, we'll say so, there's no benefit to building something custom just to prove we can. But if your requirement is specific to your business, a particular data structure, an integration with a system nobody else uses, an editing experience your content team actually needs, off-the-shelf usually means a compromise somewhere. We'll walk you through the trade-offs plainly: cost, maintenance, and how tied you'd be to one plugin's own upgrade schedule versus your own. You make the call with the full picture, not a sales pitch for whichever option we'd rather build.
It can, if it's built badly or never tested against new releases. That's exactly what we build against. Custom work is developed using Umbraco's supported extensibility points rather than hacks that reach into the core, and we test it as new versions land, not just when something breaks. If you're on a Gecko support agreement, this checking happens as a matter of course. If you're not, we'd still recommend a compatibility check before any major upgrade, custom or not. The honest answer is that no agency can promise zero risk forever, but properly built custom code ages a lot better than a quick fix ever does.
Usually, yes. Most of the custom development we do is on existing sites, not new builds. We'll review your current Umbraco version, any custom code already in place, and how the new requirement fits around it, then scope the work as an addition rather than a rebuild. Occasionally the existing build is genuinely too fragile or out of date to extend safely, and we'll tell you that plainly rather than force a fix that won't hold. But that's the exception, not the assumption we start from.
We scope custom work properly before quoting, not after you've signed off. That means understanding the requirement in enough detail to give you a number that holds, rather than an estimate that grows once development starts. If something turns out to be genuinely harder to scope precisely, a legacy integration with undocumented behaviour, for example, we'll flag that as a specific risk before you commit, not discover it three invoices in. We know what it's like to defend a number to a board that's already sceptical of marketing spend, and we'd rather be the agency that made that conversation easier, not harder.
No. Everything we build is documented properly: what it does, why we built it that way, and how to change it. If you bring in another developer or agency down the line, they should be able to pick up our work without needing us on a call to explain it. We build this way deliberately. Custom development that only the original developer can maintain isn't really custom development, it's a dependency with better branding. Your site and your code should work for you, not for whoever happened to build it.
Both, depending on what actually solves the problem. Where a well-maintained, actively developed package genuinely fits, we'll use it rather than reinvent it. Where your requirement is specific enough that no package fits properly, we build custom C# and .NET development on top of Umbraco's own architecture, using composers, property editors and package manifests the way Umbraco intends them to be used. As an Umbraco development agency, we've got no reason to pad a project with unnecessary custom code, and no reason to force-fit a plugin that's close but not quite right either. You get whichever option actually solves it.
It depends entirely on what's being built. A single custom property editor might take a couple of weeks from scoping to sign-off. A full package with several integrations, proper documentation and testing across multiple Umbraco versions can run to a few months. We'll give you a realistic timeline once we've scoped the actual requirement, not a generic range that sounds good in a pitch. If a deadline's driving the project, a board meeting, a launch date, tell us early. It changes how we sequence the work, not whether we can do it. We'd rather help you move fast without cutting corners than rush something that ends up needing fixed six months later.
Tell us what's not working, or what you need your site to do that it currently can't. We'll ask a few questions to work out whether it's genuinely custom development or something simpler, then scope it properly before you commit to anything. The best next step is a short call so we can hear the actual problem in your words, not just a spec sheet. Book a Discovery Call and we'll take it from there.
