Dynamsoft Blog

The leading provider of version control solutions and TWAIN SDKs

Building a Document Management Solution: Do it from Scratch or Use 3rd Party SDKs?

Buy or Build

Buy it or build it? Today, this is an age-old question in the IT world. The mere outcome of one versus the other can yield grand differences in the scope of desired benefits, cost, and time to accomplish. This major decision is one many organizations also face when deciding upon a document management solution (DMS). So, should you really build your own DMS application entirely from scratch? Buying one is likely simple enough but, it also can limit you on desired features. So, if one opts to build a DMS, is help available to undertake such a task?

Other Initial Questions
There is a lot to figure out when you’re just starting out with deciding to buy or build a document management solution. You must understand, at a strategic level, what core competencies you expect from the application. This is in addition to comprehending tactical underpinnings that will make up the underlying processes for achieving common tasks. Of course, you also need to consider time-to-market or time-to-first-use. For time-to-market, can you build it all from scratch and meet your development deadlines? If it’s time-to-first-use, you have to consider how urgently you need to start using it. You’ll want to weigh these things against the necessary time and resources to properly execute the software.

Once you elect to start building it, even more questions start to pop up. Have you allocated enough R&D resources to do the related work? For example, will you need to adopt and implement technology standards and if so, do you have a full understanding of those standards? If not, how much time will need to be spent educating oneself on necessary standards to correctly implement them? With document management solutions, many standards come into play, from image acquisition interfaces to file extension types. You have to also thoroughly understand and make sure you know your true cost of ownership over the lifecycle of the software. For example, can you accurately account for staffing six months or a year or more from now? It’s critical because the staff needs to provide continuous technical support for each component of the software. As we all know, the cost to build or own software extends beyond initial development or purchasing. Technical support, upgrades, scalability – all of these elements can add surprise long-term costs.

Going It Alone But, With Help
Those that opt to build their own solution often do so for obvious reasons, one of which is flexibility to customize as needed. It’s important to note that one can opt to purchase certain pre-built components. This can save extensively on development costs and time while still allowing the full flexibility of custom-built solutions. If you’re building a house from scratch, you’ll probably purchase pre-built windows, doors, and fixtures. This saves extra money and time you would have otherwise spent on extra sanding, cutting, measuring, etc. Just the same, software developers commonly opt to use an available off-the-shelf database to not fuss around with trying to design one. One might also use software development kits (SDK) for other components, such as for the interface to conduct document scans and processing. Building your own database and image capture module can be daunting. For image capture there are industry standards to comprehend that are hundreds of pages long. You really shouldn’t even begin to code without full comprehension of these standards. Then there is the code itself – it can be hundreds to more than a thousand lines of codes of additional work. Building an image capture component yourself can add months of extra development time and costs.

Let’s get more specific. The TWAIN application programming interface (API) is one of the most popular communications protocols to regulate interfacing between software and digital imaging devices. So, there’s work to be done to know how to properly support this one standard. You’ll start by learning the 600+ pages that make up the TWAIN specification. This is so you can become familiar with how to use TWAIN to talk to imaging devices, such as scanners. Understanding TWAIN to develop related scanner programming is essential. So, it’s no wonder many programmers opt to use SDKs for specific components. This is a very common practice in the document management software market. The use of a document imaging SDK, such as Dynamic Web TWAIN, can allow the programmer to implement just a couple of lines of code to start calling the TWAIN API for scanning in a web application. It turns months of work into just hours or a few days. It also helps keep coding clean – the use of an SDK can reduce your code development to just a few lines. If you’ve opted to build your own software, SDKs make very convenient options when time or costs are a concern.

Maintain Focus
Another key reason many organizations opt to use SDKs is that it allows them to maintain focus. Often, a document management solution is the request of a client to a software development shop. That shop might, for example, provide expertise in software tailored to an industry, such as healthcare or finance.

So, while their healthcare client has requested a document management solution from them, building every component can pull them away from their focus on healthcare software and services. For example, coding together a document scanning module is likely not a core competency. So, building this might defocus a shop and add a lot of undesirable cost to the project. In this way, an SDK vendor lets a shop stay focused and keep client costs low.

Pointers on SDK Selection
OK. You’ve decided to build the document management software and use an SDK to help implement the image capture component. So, how can you be sure you pick the correct SDK? There are a few things to consider. One obvious thing to do is to check the background and stability of the SDK vendor. Do they have plenty of customer referrals and how long has their solution been available (is it mature)? Make a checklist for features you want and check it twice. Does the SDK support all or most of the features you need? What about integration? How easy can the SDK be integrated into your new or existing document management software workflow? Do the SDK’s image acquisition capabilities have library support for the essentials, like TWAIN, scanner, webcam, .NET, etc.

Finally, you need to check out support options for the SDK as well as migration paths to newer versions. Remember that standards come and go. For example, the use of NPAPI plugins for browsers are being displaced in favor of HTML5 versions. What side of the fence will your software sit on and if you jump the fence, will your SDK provider allow you to seamlessly migrate?

Scratching Your Head
Building completely from scratch can ultimately leave one scratching their head – why did I opt to go this route? It’s not uncommon that critical and time-consuming steps are forgotten or even abandoned because of their difficulty. Remember, developing from scratch without an SDK will mean hundreds to thousands of more lines of code and many more months of work. You then have to thoroughly test your solution prior to deployment, then test it again after deployment and with each update. Don’t forget about training staff, from the development stages to the usage stages. You have to also make sure your resources are up to the task. Will adding months more in work to finish the solution defocus you too much and are certain staff going to be okay with this? Will management be okay with taking people of core tasks? What about when you have to support the software? Are you up to the task to provide continuous technical support? Have you considered if you might be better off with key components instead being fully supported by a reliable SDK vendor?

In the end, most project managers and developers realize the best path is to stay focused on what you do best in-house and get help with the rest. It truly saves a lot in time, costs and headaches.

Dynamic Web TWAIN 10.0.1 Released

We are pleased to announce that Dynamic Web TWAIN 10.0.1 is now available.

Many exciting improvements are included in this minor update:

  • Enhanced robustness of WebSocket connection. The new version will automatically try re-building the connection in case it is inadvertently closed due to network problems.
  • Better support for Chrome 38. Such as downloading large files using the HTTPDownload method.
  • Shorter initialization time. When a user visits the scan page for the first time, the new version has a 71.4% faster performance to detect whether the client-side browser has Dynamic Web TWAIN installed.
  • Other bug fixes and tweaks. 

For more details, please refer to Release Notes of v10.0.1.

Try online demo to see the new version in action >> 

Download 30-day free trial >>

If you are ready to purchase a license, please visit our Online Store or send your order to sales@dynamsoft.com.

For any tech questions, please email support@dynamsoft.com

Dynamic .NET TWAIN 5.4 Released

Dear All,

We’re more than excited to announce that Dynamic .NET TWAIN 5.4 is released. Below are the main improvements we made in this version:

  • Improved 1D barcode reader performance
    Improved 1D barcode reader add-on in both barcode decoding accuracy and performance, especially for Code 39 and Code 128.
  • Improved speed for WPF control’s image displaying.
  • Improved speed for multi-page PDF loading and viewing.
  • Added new method ConvertPDFToImage(byte[], resolution) for converting PDF byte array to images.
  • Other minor fixes and tweaks.

To learn full features or try out the latest version, please visit at

If you have a valid software maintenance contract, or are using version 5, please contact sales@dynamsoft.com for FREE upgrade to this new version.

If you are ready to purchase a license, please visit our Online Store or send your order to sales@dynamsoft.com.

For any tech questions, please email support@dynamsoft.com

4 Trends for Image Capture in Document Management to Close Out 2014

Document Magazine
Dynamsoft contributed an article to Document Magzine that ran Sept 4, 2014. Start reading it below.

The image capture market encompasses so many applications: cameras, digital copiers, imaging equipment, scanners and more. These applications are now ubiquitously applied in mission-critical roles across different industries, including healthcare, entertainment, finance, government and many more. There is no doubt the image capture market is booming. One market seeing such successes is the document management market. Are there any likely trends to emerge or grow far faster within document management to close out 2014?

A continual improvement in optical device products, more advanced algorithms and cloud computing has truly ushered in an era of innovative imaging applications. They include advanced video conferencing from smartphones to conference rooms, camera applications, face detection technologies, barcode recognition and, of course, document imaging and management. Specifically for document management applications, enterprise content management (ECM) continues to be a booming market. Its success is easily explained because more and more organizations are seeking to shift from paper-based to digital document workflows.

One research firm estimate pegs the ECM market will blossom from $4.4 billion in 2012 to more than $7.5 billion in 2016. Those employed within the image capture market understand there is a transformative feeling going on. Image capture is truly changing the way people live and communicate at home. It’s also transforming the workplace with higher efficiency and performance in day-to-day workflows and communication. Four trends will continue this transformation to close out 2014.

The ECM market will blossom from $4.4 billion in 2012 to more than $7.5 billion in 2016.

1. It’s still all about mobile
The mobile market will close out 2014 by emerging as the new battlefield for document image capture and management. By one analyst’s estimate in 2013, mobile workers carried on average three devices–tablets, laptops, smartphones, phablets, etc. Businesses will come to better learn how to leverage mobile for image capturing. The banking industry is one example of how image capture can transform an industry. Almost everyone uses a mobile app now to snap a picture of a check for deposit. In fact, the Federal Reserve reported this year more than half (51%) of smartphone owners have used mobile banking in the past year. Another interesting find in the report was that 39% of people who made point-of-sale mobile payments did so by scanning a barcode…

Read More>>

Should developers opt to code for Web or native apps?

SD Times

Dynamsoft contributed an article to SD Times that ran Sept 4, 2014. Start reading it below.

Ever since Apple created the iOS ecosystem, countless developers moved to focus their energies on the mobile world. As a result, more and more content is being consumed and more apps are being used as routine parts of people’s daily lives. It seems mobile is dominant in every way.

However, according to Web analytics company StatCounter, mobile browser usage hit only 20% at the end of 2013, and personal computers accounted for the remaining 80%. Then again, according to comScore, for the first time starting in January 2014, more Americans use apps (46.1%) to access Internet data than they do from a desktop computer (45.1%). Such data only further fuels the now age-old argument: Should developers focus on Web or native applications?

Despite the conundrum, developers often pick sides: They stick to just Web or just native. It’s obvious that when users are on a desktop, they will tend to use their desktop browser to access their favorite applications. On mobile, users prefer dedicated apps for popular websites over mobile browsers.

But, consider that Microsoft and Apple appear to be retooling their desktop operating systems (Windows and Mac OS X, respectively) to be more mobile platforms than desktop platforms. So, for some developers, the answer is not so clear-cut. To some, it seems more difficult than ever to decide whether to develop a Web or native application.

There are obvious considerations to help make the decision, such as the number of your potential users on one versus the other. Another factor that helps sway a decision is the development time and maintenance time. Developers also have to come to grips with any new technologies on one platform versus another.

Regardless of all this, developers that pick sides are wrong. We must still develop for web and native applications. Let’s explore…

Read More>>

Copyright © 2014 Dynamsoft. All Rights Reserved. Privacy Statement | Site Map