This article was featured in the Journal Technologies Insider, a free quarterly publication from Journal Technologies. If you'd like to subscribe to the Insider, you can do so by clicking here.
Kaushik Mehta is the Chief Technology Officer at Journal Technologies, and Anthony Rochon is the Director of Court Implementations.
Q: Balancing core features, configuration, and customization seems to be a hot-button issue for courts and justice agencies as we move through 2026. Why is that?
KM: The reality is that courts are making technology investments expected to last a very long time. These systems aren’t just supporting today’s operations: they need to adapt to future legislation, staffing changes, and evolving expectations around access and efficiency. What often gets overlooked is how early design decisions affect everything that comes later.
AR: From the implementation side, we see that firsthand. Decisions made early in a project – often months or years before go-live – can shape how easy or difficult the system is to support over time. Courts are under pressure to modernize quickly, and that’s understandable. But speed without strategy can introduce risk that isn’t always obvious at the outset.
Q: Let’s level-set for readers. How do you define core features, configuration, and customization?
KM: Core features are at the heart of our platform. We’re talking about built-in functionality that is fully supported, tested, and enhanced as part of Journal’s regular release cycle. These are generally universal, workhorse capabilities; they’re designed to be versatile and upgrade-ready.
Configuration sits on top of that foundation and allows courts and agencies to create organization-specific workflows, forms, rules, and reporting without changing the underlying code or compromising upgradeability. There’s plenty of supported flexibility here that is often underutilized.
AR: By contrast, customization is different. That’s when you extend or modify the system’s code to meet requirements that can’t be addressed through configuration or core features. Customization isn’t inherently wrong, but it introduces additional complexity, higher costs, and increased long-term oversight. As such, it’s important to determine if a custom “requirement” is a want or a true need.
Q: If configuration is often the safer path, why do organizations still gravitate toward customization?
KM: It often comes down to familiarity. Organizations are used to the way they’ve done things in the past – which can be sensible – and there’s a natural desire to replicate legacy processes in a new system so it’s familiar to users. Customization can feel like the quickest way to achieve that, especially if there’s already a prototype or mock-up in hand or it’s a perceived requirement to do exactly a certain way.
AR: There is also a perception gap. Sometimes people assume that if a requirement is unique, it must require custom code. The reality is that many needs can be met through configuration or process adjustments that better leverage available platform features.
Q: What risks come with leaning too heavily on customization?
AR: One of the biggest risks is introducing fragility. Custom solutions often depend on very specific assumptions about data, workflows, or user behavior. When those assumptions change even slightly, the system can break in unexpected ways.
KM: From a technology standpoint, customization introduces new system overhead. Every custom element must be tested, maintained, and revisited during upgrades. Over time, that can slow upgrades, increase support costs, and make it harder to take advantage of new core features that are delivered as part of the platform.
Q: What are the cases where customization does make sense?
KM: Customization can be appropriate when there are legal or regulatory requirements that simply can’t be met through configuration or core functionality. In those cases, the key is being intentional and disciplined about how customization is applied.
AR: The most successful examples tend to be narrowly scoped and carefully thought out. We’ve seen good outcomes when teams extend existing entities rather than introducing entirely new structures, or when they add targeted fields instead of rewriting workflows. Those approaches meet the business need while preserving alignment with the platform.
Q: How do you decide whether a requirement truly justifies customization?
AR: We encourage customers to step back and ask a few questions. Is this requirement legally mandated, or could it be reconsidered if it means maintenance costs increase significantly? Can the underlying goal be achieved through configuration or a process change? And what happens to this solution three or five years down the road?
KM: It’s also important to look at total cost of ownership. Customization isn’t just about the initial build, it’s also about ongoing support, testing, and upgrades. If a solution creates long-term friction, that cost can outweigh the short-term benefit.
Q: What advice would you give customers currently planning a new implementation or enhancement? And what broader takeaways?
AR: Organizations should never assume their legacy process embodies the gold standard or the only way to achieve an outcome. Securing buy-in for a more transferable and upgradeable process may require additional effort in the short term, but it can significantly reduce long-term effort compared to defaulting to customization.
KM: And as Chief Technology Officer, I’d be remiss if I didn’t say this: lean on the platform! We have a lot of belief in the flexibility of our eSeries platform, and we built it this way for a reason: it’s designed to evolve. Strategic reliance on core functionality and configuration keeps systems adaptable and futureready.
AR: Exactly. Enterprise software deployment is an ongoing process, not a one-time event. Our goal is to help customers implement systems that are stable, supportable, and capable of adapting to evolving technologies and operational needs. Thoughtful design decisions today can make the difference between perceived system success and failure over the long term.