5 Reasons Why Developers Can’t Lead the Documents-to-Data Revolution

Business-to-Developer (aka B2D) is a very fashionable business model these days, and means that the product is designed for developers and sold to developers. The idea is to get a developer experimenting with your product via an easy-to-use API, perhaps on a hobby or side project, and when the company needs a solution, the developer will sell their boss on yours.

Here at GLYNT we thought we might have a B2D business model too. But after studying the documents-to-data problem closely and working through deployment issues with our customers, we’re strongly in the standard B2B business model camp.

We built a product for everyday business use. It is sold to managers. It is used by Business Users, folks that are spreadsheet jockeys, data analysts and ready to put results into Tableau or Power BI. Business Users don’t code.

To summarize how we came to this conclusion, here are our Top 5 Reasons Why Developers Can’t Lead the Documents-To-Data Revolution.

1. Documents that seem alike often are not.

Let’s take the familiar paystub. One from Wisconsin will have different taxes applied than one from California. And there is often a difference in how federal taxes are displayed too. Are you expecting your developer to untangle this? Lots of luck. We’ve found that coders hate this fine-grained data normalization work.

2. Incoming document flows are always changing

Companies change vendors. New customers and products are added. People move. And so on. Document flows are almost living, breathing organisms. This constant change means a developer has to constantly update the mapping from documents to target data schema. Coders hate this task too.

3. Relying on developers holds up projects.

Suppose you did ask your development team to do the first two tasks. And because they don’t like to do it, they procrastinate. Other tasks always jump to the top of the list. Meanwhile, your documents are still a manual data entry operation. Who wants to live like this??

4. Developers can’t do the hobby project on your document solution.

To experiment with a documents-to-data solution, one needs documents. Developers seldom have the authority to submit documents, which contain sensitive information, to a third party. They need approval. So the premise of B2D, which is off-hours developer experimentation, just doesn’t happen.

5. Developers are terrific at technical validation.

We’ve found that once the business manager says “Let’s give GLYNT a try!”, the developer jumps in and loves the experience. API integrations are simple and quick. Then it is time to build a customized AI model. It’s fun time! Using GLYNT’s point & click UI, the developer gets an AI model going, sees the results, and sighs with satisfaction. Technical validation done, play with new toy complete, it’s back to coding.

Don’t get us wrong, the GLYNT team is full of high-powered and skilled developers. And we love working with developers on our customers’ teams. But be advised that the documents-to-data revolution will stall if developers must make the first move.

Want to help your developers? Want to get your documents-to-data revolution going? Talk to GLYNT. We are a B2B business model because that just makes sense.