The OnBase Custom Quote Checklist Nobody Gave You

If you've ever submitted a vague custom development request and received a wildly inaccurate quote back, you're not alone. It's one of the most common friction points in ECM projects, and it costs everyone: the vendor spends hours scoping something they still don't fully understand, and you end up with a number that either balloons mid-project or gets revised so many times it becomes meaningless.

This post is about how to fix that. Not by following a generic template, but by understanding what information actually drives accuracy in a custom OnBase quote, and why each piece matters.

The Real Problem is That Scope Is a Moving Target Until You Nail It Down

Most custom development quotes go sideways not because vendors are bad at estimation, but because the request itself is underdetermined. 'We want automated approvals' could mean a two-day Unity Form build or a six-month workflow engine overhaul. 'We need integration with our core system' could mean a REST API call or a complete bidirectional sync with real-time error handling and audit logging.

The more specific your input, the more useful the output. Here's what actually makes a difference.

What to Include in Your Request (And Why It Matters)

Your Current OnBase Environment

Version number, licensed modules, and how your system is deployed (cloud, on-prem, hybrid) are not just IT trivia. They define what's technically possible without major upgrades. A feature that's native in OnBase 25 might require workarounds in 19.

A module you don't have licensed might be the entire solution.

So be sure you include:

•      OnBase version and patch level

•      Licensed Modules AND Licenses actively in use (Workflow, Unity Forms, Advanced Capture, etc.)

•      Deployment model (Hyland Cloud, on-prem, hosted)

•      Any third-party integrations that are already in place

What You're Trying to Accomplish (Not Just What You Want Built)

This is the one most people skip, and it's perhaps the most important. 'We want a document approval workflow' is a feature request. 'We need to reduce our loan closing package review cycle from 5 days to same-day' is a business objective. The second one gives a developer context to design something that actually solves the problem, not just check a box.

Describe the current state, the pain, and the desired outcome. Let the technical person ask clarifying questions. That conversation is where the best solutions get found. A viable and usable solution should involve clear exploration of how things work now, why they work that way, and how you would like them to work.

The Systems You Need to Talk To

Integration work is almost always where custom quotes get anchored wrong. 'Integrate with Salesforce' sounds simple. Whether it's simple depends entirely on: which Salesforce objects, which direction data flows, whether you need real-time or batch, what auth method is in place, and whether Salesforce has a working sandbox available for testing.

For every system that needs to connect to OnBase, provide:

•      System name and version

•      What data needs to move, and in which direction

•      API availability (REST, SOAP, proprietary SDK, database-level)

•      Authentication method (OAuth, API key, service account, etc.)

•      Whether a test/sandbox environment exists

Compliance and Security Requirements

These aren't add-ons. They're design constraints. HIPAA-covered data requires audit logging, access controls, and sometimes specific infrastructure configurations. SOC 2 environments may require code review processes or data handling documentation. If you tell a developer about these requirements after the build starts, expect a change order.

List applicable regulations upfront: HIPAA, SOX, GLBA, GDPR, state-specific requirements. And don't forget to flag any internal IT security policies that govern third-party integrations.

Your Timeline (Honest Version)

'As soon as possible' is not a timeline. Neither is 'Q3' without a year or specific milestones. If you have a hard go-live dependency (a core banking conversion, a regulatory deadline, a board presentation), say so. If you're flexible, say that too.

Compressed timelines affect resource allocation, testing depth, and sometimes architecture choices. A vendor who knows about your deadline upfront can design for it. One who finds out at kickoff has to retrofit around it.

Questions Worth Asking Any Vendor

Before you select a partner based on price alone, ask a few things that reveal how they actually work:

•      How do you handle scope changes mid-project? (Look for a clear change order process, not 'we're flexible.')

•      What does your testing and QA process look like? (Unit testing, UAT support, regression coverage.)

•      What happens after go-live? (support SLAs, training, documentation handoff.)

•      Have you built something like this before, and can we talk to someone who used it?

•      How do you handle data migration or cutover risk?

These questions won't guarantee a perfect engagement, but they'll surface red flags faster than any RFP scoring matrix.

One More Thing: The Quote Is Not the Contract

A custom development quote is an estimate based on what's known at the time. Even a thorough one carries assumptions. The best vendor relationships treat the quote as a starting point for a real scoping conversation, not a final price.

If a vendor hands you a fixed price quote on a complex custom build after a 30-minute call, be skeptical. Real complexity takes time to understand. The vendors willing to ask more questions before quoting are usually the ones who build something that works.

Datum Evolve is a Hyland Authorized Partner specializing in OnBase consulting, workflow automation, and content services for financial services organizations. We're happy to talk through your project before you formalize anything.