Build it, borrow it, tweak it: Not every block needs to be bespoke

Now the question is: can we build this using standard tools, or do we need to go custom?

At Juizi, we get this a lot. And we love that question—because it means you’re thinking strategically. So let’s walk through how we figure it out, together.

First stop: does this already exist?

Before writing a line of code, we always check: has someone already built something like this?

With Plone, that’s more common than you’d think. Between core features and a wide range of add-ons, the community has created some brilliant solutions over the years. We know where to look, and what to trust.

If there’s something out there that’s reliable and close to what you need, we’ll suggest starting there. That saves time, avoids unnecessary cost, and may mean less maintenance later.

But what if the existing options just don’t quite fit?

Is it business-critical—or just nice to have?

Next, we ask: is this feature essential to how your site works, or would it just be a “cool extra”?

If it’s core to your site’s purpose or your team’s workflow, custom development might be the right move. But if it’s cosmetic or something editors can easily work around with existing tools, we might advise holding off.

Custom should always be purposeful. That’s how you make sure it’s worth the investment and the ongoing upkeep.

Can we adapt something instead of starting from scratch?

Here’s where things get interesting. Sometimes the best solution sits between “standard” and “custom.”

Let’s say Plone has a great base block that almost works. We might tweak how it looks, how it pulls in content, or how it behaves (without reinventing the whole thing). That gives you something tailored, but still grounded in existing, trusted code.

This approach also keeps future upgrades easier. And if we think the tweak could help others, we can share it back with the Plone community.

That’s the beauty of open source: you benefit from others, and others benefit from you.

Is it reusable?

We also look at how many times this element might show up across your site. Is this a one-off homepage hero, or will editors want to use it in lots of different places?

If it's going to become a key part of your content strategy, customising it properly is worth it. We design reusable blocks that are simple for editors, flexible for designers, and easy to maintain.

And again, when it’s something that solves a common problem, we contribute it back upstream. That means others can benefit from your investment too. It’s how open source stays strong, and how your site becomes part of something bigger.

What’s the long game?

Here’s the final checkpoint: will this still make sense a year from now?

We’ve seen too many sites saddled with overly custom components that no one knows how to update. So when we build custom, we build clean. No unnecessary dependencies. No clever tricks that only one developer understands. Just straightforward code with a long shelf life.

Because we’re not just building for launch day. We’re building for every edit your team makes after that.