Fulcrum Dynamic Earns First Review on Clutch

Technology plays a crucial role in maintaining and scaling your businesses. You need the right tools to accomplish these goals.  But in an ever-evolving landscape, it can be nearly impossible to keep up with all the available technologies you need to help your business to succeed.  That’s where we come to help you.

Fulcrum Dynamic is a small design and development company based in Round Rock, Texas. Established in 2019, our company goes above and beyond to make sure you have what you need to save time, resources, and effort. We bring world-class solutions to help you streamline your processes and lessen mundane concerns.

Working with an expert to wrangle the wild world of technology is vital, but choosing the right partner is almost as hard as figuring out the technology itself.  Who can you trust?

As we aim to prove the quality of our services to the public, the news that we’re about to share excites us. Most recently, Fulcrum Dynamic made its official debut on Clutch and received amazing client feedback for our work.

What is Clutch?

For those who aren’t familiar with them, Clutch is a B2B review and rating platform designed to help browsers navigate through the IT, development, marketing, and business services fields. The site is trusted by millions of corporate buyers and service providers, and it’s home to a massive collection of data-driven client reviews.

For our first-ever review, Dan Francis, the owner of StepStone Realty, LLC, wrote about our web development services. StepStone has been a long-time partner over the years, and the review was published on September 09, 2021.

Our main responsibilities involved API integration, middleware integration, and ensuring security upgrades for their platform. We worked closely with the client to make sure everything ran smoothly despite the challenges brought by the pandemic last year.

In the results and feedback section, the client wrote this when asked about what was the most unique aspect of our team:

“They were easy to work with, understood the goals, and easy to read code, allowing them a successful partnership.” — Owner, StepStone Realty, LLC

This is such an amazing review. This is an important milestone for us and we look forward to gaining traction on Clutch soon. If you’re curious about the full scope of this project, you may check out our profile on Clutch for further details.

With that being said, the whole Fulcrum Dynamic team sends their sincerest appreciation and thanks to StepStone Realty, LLC for helping us with our first review. As for our other clients, you can help us in this journey by providing us with your insights.

Making Waves in the ECommerce Space

The present and the future lies in eCommerce. As businesses take on the massive industry, Fulcrum Dynamic is stoked to be a trusted partner. Just recently, we’ve been made aware that Top Design Firms recognized us for our professional eCommerce development work.

To get you up to speed, Top Design Firms is a new B2B website that showcases the work and projects of industry experts like ourselves. According to their latest findings, Fulcrum Dynamic is among the top eCommerce web design and development companies in 2021.

We could not be more grateful for this overwhelming recognition. Our team is pumped to help more companies venture into the vast eCommerce market. Thank you Top Design Firms, our team, and our valued clients! Work with us and let’s help you reach your business goals. Don’t hesitate to drop us a line and tell us more about what projects you have in mind. Harness the power of technology with Fulcrum Dynamic.

Case Study: Custom Android Tablet Application for Oil Field Logistics Service Company


Our client is a market leader in oil field logistics and transload services.  They own and manage a nationwide network of transload terminals where they store and move millions of pounds of proppant (frac sand), crude, and other materials to and from trucks, railcars, silos, and other containers.  Their services are a critical element in the energy supply chain in North America.

One of the client’s transload terminals. Product is brought in by railcar. The railcars can be stored on-site, or product can be loaded into silos, as shown in the background.

In addition to managing transload terminals, our client has expanded their services, to become a full, end-to-end multi-modal logistics provider. They have added their own trucking fleet and proprietary proppant frac sand storage and delivery system for the well site.


The company’s custom frac sand storage and delivery solution is a game-changer for well site operations. It is a mobile solution that can easily be set up on well sites at remote locations. Where well operators previously managed small, pallet-sized sand containers with a forklift, their system provides modular storage with a maximum capacity of over 3 million pounds, all of which is belt-fed directly to the frac mixer, dramatically reducing downtime during drilling.

These portable containers are setup at the well site. The angle allows them to feed a conveyor by gravity, simply by opening a gate valve.

Additionally, their system tracks inventory in real-time, automatically requesting more proppant from a company-owned loading facility, delivered by company-owned trucks. With this system in place, our client is able to take full responsibility for the provision of proppant at the well site. However, with this responsibility comes liability. The logistics company contracts with its clients to guarantee availability of proppant at the well site, similar to a Service Level Agreement for a mission-critical IT service or system. Drilling an oil well requires the coordination of multiple teams of people from different companies on-site, operating millions of dollars worth of equipment. If the logistics company’s equipment malfunctions or they fail to deliver enough sand in time, the logistics company must compensate their client for the lost productivity of their people and equipment on site.

The sand delivery system has proven to be exceedingly reliable. However, any system can malfunction, especially when operating in extreme conditions, like outdoors in a remote location, in very cold or very hot weather, as is common in the oil fields.

On the left, you can see the conveyor moving sand deposited from the containers. In the background are a control module and a belt loader for loading the containers. In the foreground is one of the client’s fleet of proppant trucks, with their special trailer design which can carry more sand, unload it faster.

They needed a way to track any of these down time events, for billing, as well as for analysis to prevent future issues. Additionally, they needed to be able to track down time events for which they were not liable, in case the client made an erroneous claim.

Initially, these events were phoned in to the dispatch team, and logged in a spreadsheet. However, this was time-consuming and error-prone. They needed to be able to track exact start and end times for these down time events, to categorize them effectively, for later analysis. They needed to have the operators on site be able to log such events directly themselves. And they needed to collect a sign off from a representative of the client, in case the issue was disputed later. Also, while data needed to be recorded on site at remote locations with unreliable network connectivity, the data needed to be stored in a central repository in the cloud for easy access to use in billing, reporting, and analytics.

An operator on site monitors the system with a ruggedized tablet.


The bulk sand operators on site were already using ruggedized Android tablets to access equipment maintenance schedules, the company time clock app, and other resources, so we built a mobile app that could be deployed to these existing devices.

The app used our custom Fulcrum Framework platform, which combines best of breed technologies for an extremely flexible solution. We provide a flexible UI that looks great on phones, tablets, and desktops. Our framework allows us to build a single application code base which can be deployed to nearly any platform: including Windows, Mac, and Linux desktop applications; Android and iOS mobile applications; and of course web browsers as a Single Page App (SPA) or Progressive Web App (PWA). And we use a cloud-hosted NoSQL database to provide a flexible back-end data store in the cloud.

First, we had to structure the application so it could function completely autonomously while offline, in case the tablet being used does not have network connectivity at the time. We used PouchDB to store all application data locally on the device and then sync it to a CouchDB datastore in the cloud. While running online, data will appear in the datastore almost immediately, as syncing runs automatically. But when the app is offline, it will store the data locally and wait for a connection to be restored. Once the connection is restored, syncing automatically resumed. We configured the syncing to run every 5 minutes, rather than continuously, in order to conserve bandwidth, since these devices often connect to the Internet through slow and expensive satellite connections. However, we also provided an interface in the UI to see when the app was last synced, and initiate a manual sync if needed.

The app is integrated with the client’s other existing systems, including their employee database, allowing the operators to use a shared login. Once logged in, the operator is presented with a list of ongoing events which are causing downtime, and which might cause downtime in the future. They can also see past events, and log new ones. This allows for a smoother handoff between shifts, which is important since well sites run 24 hours a day, and employees need to be able to go home and get some rest.

The app is also integrated with the client’s equipment and job site data. This allows events to be tied to a particular job, and when an event relates to a particular piece of equipment, the user can select it from a list of the components deployed at that job site.

Once an event is resolved, the operator can mark it complete, and record the time. All completed events are presented in a report which the operator can show to the customer representative. Both the operator and the customer representative electronically sign off on this report.

The events, categories, start and end times, and signatures are all synced to the cloud, where they can be fed into the client’s reporting and analytics systems. Management can easily see all open events across the operation, or for a particular client or region. They can look for patterns, like the same piece of equipment malfunctioning repeatedly. And they can accurately track any down time liability they incur, in order to compensate the customer.


Where downtime events were previously claimed by the logistics company’s clients, this system allows the client to be proactive instead of reactive, reporting downtime to their customers, instead of receiving reports from them. They also have accurate start and end times, along with other details about the event, so they don’t have to take the client at their word if the report is exaggerated. Best of all, they are able to analyze the data and prevent downtime events before they start.

Case Study: Bill of Lading Edit Interface using AngularJS for Logistics Company


Our client is a market leader in oil field logistics and transload services.  They own and manage a nationwide network of transload terminals where they store and move millions of pounds of bulk sand, crude, and other materials to and from trucks, railcars, silos, and other containers.  Their services are a critical element in the energy supply chain in North America.

A silo installation at one of the client’s transload terminals. Product is brought in via rail, and loaded into the silos with a bucket elevator. Trucks drive under the silos to be loaded, before delivering proppant the last mile, to the actual well site.


The client runs transload facilities across the country, with an especially high concentration in the Southwest. At these facilities, they load, unload, and store bulk materials for their customers, primarily frac sand to be used in drilling oil wells. When material is loaded and shipped out from the terminal via truck, the driver is issued a bill of lading. The client manages all of the operations at their terminals with their custom terminal management application, which we helped them build.

A sand truck, waiting to be loaded.

All load actions are tracked in the application, arrival and departure weights for the trucks are captured from the on-site truck scales, and a signature is captured electronically from the driver. The application uses all this data to automatically generate a correct and accurate bill of lading, which is printed out and handed to the driver. A copy is also stored in the cloud as a PDF for later reference.

The bill of lading is automatically generated as a PDF, which can be printed. The driver’s signature is captured electronically and placed on the appropriate section of the document.

The process is highly efficient and allows them to quickly process trucks at their sites, and maintain uniform processes at every location across the company. In fact, the system worked so well that another company approached our client about licensing their system to manage their own terminals. However, the partner company had certain specific feature sets which they required before implementing the system at their own facilities.

The most significant feature request was an easier way to modify bills of lading after the fact, as well as tracking those modifications. The bill of lading contains a large assortment of data about the load: customer, service company, product, tare and gross weights, purchase order number, driver name, signature, etc. One strategy used in the terminal management system to eliminate data entry errors is to provide dedicated screens for different steps in the loading process. These dedicated screens only allow entering the specific data relevant to that step (entering order data, receiving a new truck, loading the truck, collecting the final weight and dispatching the truck), and a series of statuses ensures that only the trucks at a given step can be accessed on that screen.

While this structure is very effective at preventing errors, on the rare occasion that an error did occur, resolving the issue was a bit cumbersome. A user with administrative access would have to manually revert the statuses on the truck to edit the different fields. As the client’s business continued to grow, even a steady low error percentage inevitably grew to a larger administrative task, and for their partner, it was a non-starter. They needed a way to edit all the relevant details about a truck on a single page.


Making a single page form with all the relevant fields for a truck is trivial. However, the system provides numerous checks to make sure that the order matches the customer, the job matches the order, the product matches all these things, and so on. Additionally, the quantity for each draft (load event) needed to total up to match the net weight calculated from the gross and tare, and vice versa. Since every piece of data could be modified, every other piece of data needed to be checked in real-time to make sure things still added up. Additionally, there were a series of dependent select fields (drop-down menus), where the user’s choice in one menu would affect the available options in other menus.

The core terminal management system was built as a web application, running in the cloud, backed by a relational database, with the user interface rendered in the browser with HTML. Additional UI enhancements were implemented using JavaScript. However, the level of interactivity required for this page would have been an overly complex mess to implement. Instead, we opted to use Angular.

Angular is an open-source JavaScript UI framework built by Google and used by a wide range of organizations around the world. Angular allows you to define a scope, a set of JavaScript variables. You can then reference those scope variables in your page template, in functions you write to call on that page, and in event triggers. The variables in the scope are shared around the page, so any time the variable is updated, the references to it are automatically updated as well.

Weights are automatically recalculated based on user input.

We used these capabilities to automatically update the gross tare and net weights based on the total of the drafts, keeping the net weight matched to the sum of the drafts. We built a integration to allow Chosen.JS’s searchable select boxes to interact with Angular scope variables. Any time a value was updated in a drop-down menu (Customer, Order, Job, Product) we could automatically trigger updates elsewhere in the form. When a change in value caused the available options in another select box to be modified, we would pull an updated option list from the API via AJAX.

The entire truck loading process laid out on a single screen for easy editing.

One particularly challenging component was dealing with transient load sources. The system tracks which container is used to load each draft in the truck. That way, if there is a contamination or other quality issue with the material on that truck, the system can easily tell you where it loaded from, in order to locate and mitigate the source of the problem. However, trucks are often loaded directly from railcars, which by their nature are mobile. Every day, empty railcars are removed from the facility, and full ones arrive to replace them. The system provides a list of railcars, silos, and other containers that are available to load from and have the matching product for the truck. However, if you are editing a BOL from a truck that has already left, the current list of load sources may be different from the list at the time that truck was on site. And if you modify the arrival and departure timestamps for the truck, the list of available load sources will change again. We had to extend the load source API so that you could query based on timestamps and lookup which load sources were on-site during that window of time and contained the specific product at that time (because a container might be emptied of one product, and refilled with another). Any change to the truck’s arrival and departure times would trigger another query to this API, causing the list of available load sources to be updated in real-time.

Each draft (load event) is listed, along with quantity, timestamp, and load source (asset). All this data can be edited, and the system will handle the business logic seamlessly.

All of these changes are managed exclusively on the client-side, without modifying the database. Once the user is happy with their changes, they submit the edits to the system. A series of validation checks are run, to make sure the business rules are applied correctly, and the bill of lading is updated in the system. A new PDF is generated and stored in the cloud for future reference.

However, since this modified BOL is different from the document the driver signed, and was handed during dispatch, the modified BOL document does not bear the driver’s digital signature. Instead it contains a note indicating that the BOL has been modified, as well as an attached log, listing all the changes made to the document.

This BOL has been edited, so the driver’s signature is replaced with a note indicating the change.

The system stores the original BOL document, as well as every revised version, with the attached change log. Each version can be downloaded on demand from the application.

All revisions are kept for reference, allowing users to see the entire history of the BOL through each edit.


This project was a huge time saver for the administrative support team tasked with handling these BOL modifications. Changes that were once a considerable headache could be handled in a matter of seconds. Because there were fewer opportunities for error, much of this work was able to be delegated back to the terminal operations team, which dramatically reduced turn around time, since the fix could be made by a manager who was physically on-site, rather than submitted to a queue with a host of other issues to be resolved by the support team, who would previously have to call the terminal and investigate the issue to determine exactly what the correct data would be.

The revision history showing previous versions, and listing the corrections, provided traceability in case of any questions down the road.

Additionally, the same single-page interface also allowed us to implement a “Manual BOL” process. If a facility loses Internet access, they cannot access the terminal management system, since it is hosted in the cloud. However, trucks still need to be loaded and processed. Delaying loads could cause well site operations to stop, which can be extremely costly for our client’s customers, and might even lead to canceled contracts. Thus, if a facility’s Internet access is down, they must revert to a paper BOL form, a copy of which is kept in a file at the terminal. Once Internet access is restored, the paper BOL can be scanned, and the relevant data is entered on the “Manual BOL” screen. This screen is basically the same form as the BOL editing interface, except a new bill of lading is created, rather than modifying an existing one.

Finally, this feature was a non-negotiable requirement for our client’s partner who licensed the system, and implementing this allowed this strategic partnership to move forward. This lead to deploying the client’s custom terminal management system to over 40 locations across the US and Canada, and opening an entirely new revenue stream for the business. It also strengthened the partnership with that client, leading to additional future projects.

CIG Billing Reports UI

Case Study: Billing Reports for Oil Field Logistics Provider


Our client is a market leader in oil field logistics and transload services.  They own and manage a nationwide network of transload terminals where they store and move millions of pounds of bulk sand, crude, and other materials to and from trucks, railcars, silos, and other containers.  Their services are a critical element in the energy supply chain in North America.

This client operates transload facilities, where they transfer products between trucks, railcars, and on-site storage containers. They specialize in transloading frac sand for the oil and gas industry, particularly in the Southwest, although they handle a variety of materials at locations all over the country.

One of the client’s transload terminals.


The railcars, trucks, and materials they handle do not belong to the logistics service provider, but rather belong to their clients, who either produce and sell materials or consume them. Either way, they need to move large quantities of bulk materials using multiple modes of transport, which our client facilitates.

One of the logistics provider’s transload facilities. Sand is brought in via railcar and unloaded with the mobile conveyor in the center of the image. Trucks can be loaded directly from the railcar with this device, but product may also be unloaded from railcars and stored in containers like the ones shown on the right.

The client’s business is not based on the products they handle, but on the handling itself. As such, they bill their clients based on the weight transported, with rates varying based on location, customer, mode of transport, material type, container type (silo, hopper, warehouse, etc.), and various other factors. Some of these rates are set on a sliding scale based on volume. Some include minimum volumes that must be achieved within a certain time frame.

They also bill demurrage fees for railcars stored at their facilities, which vary based on the type of car. Most of these are actually charged by the railroad and passed through to the client. They typically have a certain number of free days, with a charge daily for each day after that threshold.

Many of our client’s customers are multi-billion dollar companies, and their requirements can vary greatly. As such, each contract is negotiated separately and will have different terms.

Because of all this, calculating exactly what each customer owes them at the end of the month is an extremely complex task. Data on every truck to visit each facility was being exported into a spreadsheet, and the accounting department would add all the various calculations, manually entering the more complex variations. But as the business grew, this became too time-consuming, and they simply could not keep up.


We built them a system where they could enter all the complex details of the billing agreement for each contract. Then we built a report generation system where they could grab all the transactions for each customer, have the fees automatically calculated, and quickly review them. Once reviewed, they would click a button and all the transactions would be exported to their accounting software, and an invoice would be generated. Later, as the client’s business grew, we modified the export to send the transactions to an enterprise ERP system instead.


This system allowed them to recoup lost revenue that would have been missed by the manual process, and easily generate accurate invoices for all their clients with only a couple of accountants, instead of an army of analysts, which they would need at this point.

Case Study: Industrial Automation (SCADA) and Web Application Integration for a Transloading and Logistics Provider


Our client is a market leader in oil field logistics and transload services.  They own and manage a nationwide network of transload terminals where they store and move millions of pounds of bulk sand, crude, and other materials to and from trucks, railcars, silos, and other containers.  Their services are a critical element in the energy supply chain in North America.

One of the client’s transload terminals.


This transload company contracted with one of their clients to install 4 200 ft silos to store frac sand and more quickly process inbound and outbound loads from one of their facilities. The silo installation included a pit and bucket elevator system for unloading railcars, truck scales and gate valves for loading trucks, and an automation system to control all this equipment remotely from an onsite scale house.

The top of a silo, taken from an adjacent silo. This is part of a four pack. These silos are actually at a different location, but are built to the same specifications, and are nearly identical in appearance.

The facility is owned operated by the transload provider, but the silos would be owned by the client and used exclusively for their product. The silos were constructed because this was one of the busiest terminals in the region, with an extremely high volume of trucks.

The facility is located in a small town on one of its major thoroughfares, and the long line of trucks waiting to be loaded had caused traffic blockage for the entire town, much to the annoyance of local residents.

The silos were designed to be managed using an piece of industrial automation software called a SCADA (short for “supervisory control and data acquisition”). This significant investment in mechanical equipment and software promised to increase throughput for the terminal. However, since the SCADA was provided by their client, the transload company had no control over the software, and limited access to its data.

The silos have a bucket conveyor system which carries product from ground-level, up to the top of the installations and deposits it in the appropriate silo with these conveyor legs.

Our client has a custom terminal management application, which we helped them build, and which manages inventory, bills of lading, transload billing, and all other aspects of on-site terminal operations. It also feeds data to report systems used by management and customers to make strategic decisions.

A view of the silo installation from below. The silos are just under 200 ft tall.

Any loads into and out of the silos needed to be tracked in the terminal management application in order to maintain accurate inventory, and to generate correct bills of lading. Additionally, the terminal management application needed to feed data into the SCADA system about the trucks being loaded through the silos, to ensure the correct product was loaded on each truck.


The SCADA system implemented at this site had limited integration capabilities. However, it was configured to write out a log of trucks unloaded and railcars loaded to a local MySQL database, in two separate tables. The system also had the ability to consume an XML feed of incoming trucks.

We had previously built the client a custom microservice service in Node.JS. It ran on an appliance installed at each of their facilities, and collected data from truck scales, interfacing with the terminal management application in the cloud through a REST API.

We modified this service, adding a microservice to provide the XML feed the SCADA required, pulling data from the terminal management application. We also added a service which would repeatedly poll the SCADA database for new and updated records in the relevant tables. Any new loads would be translated to the format required by the terminal management system’s REST API, and forwarded to that system, in as close to real time as possible.

Drafts loaded using the silo automation system are automatically imported into PropLogistics, and show up on the loading screen here.


This project had a very tight deadline but we were able to execute quickly and deploy our solution within just a few days. Our client’s operators on-site were able to run the automation system and load trucks far more quickly, increasing throughput while decreasing traffic.

The automation system received the truck and product data it needed to correctly assign products. The operations team was able to generate bills of lading through the terminal management application, utilizing all the optimizations already present in that system.

Since all load and unload events occurring at the silos were automatically logged in the terminal management application, they were able to track inventory without manual double entry, saving time and avoiding errors.

The transload provider was able to exceed expectations for their client, and the terminal became the most productive site in the client’s entire logistics network.

Case Study: Truck Scales Integration for Transload Company


Our client is a market leader in oil field logistics and transload services.  They own and manage a nationwide network of transload terminals where they store and move millions of pounds of bulk sand, crude, and other materials to and from trucks, railcars, silos, and other containers.  Their services are a critical element in the energy supply chain in North America.

Operators inspect a railcar at one of their transload facilities.


At each of the client’s loading facilities, they have operate one or several truck scales, industrial scales large enough to weigh an entire 18-wheeler, truck and cab.

A sand truck sitting on the scale platform, being weighed.

When a truck arrives on site, the facility operations staff weigh the truck in, then sends the truck to get loaded somewhere else on site. After loading, the truck is weighed again. So you have an initial weight (tare) and a final weight (gross). The difference gives you the weight actually loaded on the truck while it was on site (minus any fuel consumed during the time period).

The scales have a series of pressure-sensitive load cells, which are all connected to a metal box, called an “Indicator” which is located in the small office where the terminal operator sits, at a computer.

The client wanted to be able to have that scale value feed directly into their custom terminal management system, so the operator doesn’t have to manually type the number in, and risk incorrect entry. This application, by the way, is a web-based cloud application, not something running locally on the PC.

We found there was a wide variety of scale indicators from different vendors in use. Some were network-enabled with RJ-45 ethernet ports or even wireless ports, but a lot just had 9 pin serial ports. We found that if we connected a PC to the serial or ethernet port on the scale, via Hyperterminal, it was constantly streaming a steady flow of raw data. However, the format of that data varied, depending on the vendor.

In order to streamline development and testing, we built a little service in Node.JS that could simulate the output from various scales.


We ended up building a Node.JS service, which would open a socket to the scale indicator, and read the raw data stream. We built separate profiles for the different formats used by different scale vendors, so the service could interpret them. We also added logic to ignore variations caused by wind, and cut down network chatter. Then we deployed this service on a little headless appliance PC at each terminal.

Initially, the service simply provided a REST API to allow us to request scale weights on demand, but this required port forwarding at each location, which was not always possible, and when it was, made setup more complicated. Later, we reworked it so the service would push the weight data up to the cloud whenever there was a change.

If the scale management microservice is configured to push weight data, it simply makes a REST API call to PropLogistics when the weight is updated. However, the microservice also provides a simple REST API from which the current weight, along with other relevant data on the scale can be requested on-demand.

Either way, the terminal operator, sitting at the PC, entering data about the truck could simply click a button, and capture the weight from the scale inside the web application, cutting data entry errors down dramatically, and making the data entry process much smoother.

With the click of a button in the terminal management application, terminal operators can capture real-time weights from any scale connected to the Scaleman system.


The weights collected from these truck scales are used to automatically generate a bill of lading for each truck departing one of the client’s transload facilities. Feeding the scale data directly into the client’s custom web application, not allowed saved employees time improved truck processing efficiency, it also eliminated a source of errors, allowing the client to have confidence that the information printed on their bills of lading is correct.

Case Study: Signature Pad Integration for a Transload Company


Our client is a market leader in oil field logistics and transload services.  They own and manage a nationwide network of transload terminals where they store and move millions of pounds of bulk sand, crude, and other materials to and from trucks, railcars, silos, and other containers.  Their services are a critical element in the energy supply chain in North America.

One of the client’s transload facilities.


The client has a proprietary cloud-based operations management application they use to track all material and asset movements at each of their facilities.  A key part of this process requires capturing bill of lading signatures from truck drivers before they leave the facility. Different facilities require different configurations, based on available equipment, facilities, and staffing.  Some facilities use desktop PCs with a USB signature pad, while others use a ruggedized mobile device with a touchscreen.  Still others use custom-built kiosks with larger touchscreens.  No matter the hardware used, signatures need to be captured and stored in a consistent format, and must be easily retrieved later for auditing and verification purposes.

A USB signature pad can be plugged in to a desktop PC and used to collect driver signatures.


Using an open source jQuery signature plugin, and the proprietary SDK from the device manufacturer, we built a single, reusable component which allows signatures to be captured via any method: signature pad, touch screen, mouse drawing, and saved to the app’s datastore as a PNG file.

Trucks are weighed on a truck scale to capture the final gross weight before generating the bill of lading. Once this data is collected, the driver signs the BOL eletronically.

If the signature pad is installed, impressions are captured in real time, and rendered on the screen.  If the signature pad is not installed, the system will fall back gracefully.  A message informing the user on how to install the signature pad can be displayed.  Meanwhile, the other signature methods are still available.

Driver signatures are captured in the web app, along with the other truck data. This box supports both physical signature pads like the one pictured about as well as signing with a mouse or touch screen.


Our client no longer has to be concerned about signatures when planning deployments.  Any possible situation can be handled with minimal overhead, whether they are using desktop computers or mobile handhelds.  Not only that but some time after this solution was deployed, the transload company began installing kiosks with a large desktop-sized touch screen at certain facilities.  Because of the flexibility of the signature solution, the kiosks were able to support on-screen signature capture without any additional development.  Whether the facility uses touch screen kiosks, handheld devices, or a signature pad attached to a desktop PC, the application is able to handle it seamlessly.  Digital signature capture for Bill of Lading documents will be available in any scenario.

James Adams Technology Consulting is now Fulcrum Dynamic

When I started working for myself in 2013, I wanted to keep things simple.  I was one person, usually working for one client at a time, typically as a 1099 contractor.  And frankly, I wasn’t sure how long I would stick with it, or whether I would close up shop and go back to being an employee as quickly as I had begun this adventure.  So I didn’t see any compelling reason to form a legal entity for my company. Most of my sales and marketing consisted of word-of-mouth recommendations, so I wasn’t terribly concerned with branding.

Continue reading

Keep Track Of Your WooCommerce Orders Using Google Sheets And Zapier

WooCommerce is a WordPress extension that makes getting your online store off the ground much faster. It provides you with an eCommerce template, helps track orders, customers, and shipping, and a lot more! In this article, we’ll cover how to automatically add your WooCommerce orders to a Google Sheets spreadsheet using Zapier, which will make it even easier to keep up track of your online shop’s orders. 

Continue reading

How To Convert HubSpot Tasks Into Trello Cards For Your Team Using Zapier

Trello is an amazing resource for keeping your team’s assignments and tasks organized and readily accessible. Everyone on your team can view everything easily and keep up with their part, keeping all of the different assignments throughout your team centralized. In this article, we’ll cover how to automatically add your HubSpot tasks to your Trello board, further centralizing your team’s assignments while also saving yourself time and mistakes.

Continue reading