The $500 button

Every engineer, once in a while, will run into an issue that just takes way too long to solve. One that seems like it should be trivial — maybe 15 minutes of work — but turns into an hours-long project. These types of issues haunt software developers. They’re the reason everyone is afraid to commit to a timeline and why the phrase “that’ll be an easy fix, right?” from a non-engineer makes our heads want to explode. While working on the checkout flow for Hopscratch recently, we decided to calculate the cost of one of these situations…


On our checkout page, we wanted the “Next” and final “Place Order” buttons to be within a sticky footer, on the bottom-right of the page. The idea was to make their positions consistent so users could easily get through the pages and complete the checkout process without having to hunt for the buttons to do so. It was consistent — users always knew where the buttons where — and, since they were separated from the page, attention was drawn to those actions. The final comps looked beautiful, so we went into development.

The initial comp for our sticky footer

We immediately ran into an issue in that we could not keep the button within the main form element since it needed to live within a sticky footer element. Because of this, the button couldn’t directly submit the main form or execute any type of validation prior to submission. To make the issue more interesting, the form button was part of a plugin we previously decided to use for all forms on our site (Visual Composer). All button styles and content were dynamically generated by the plugin and placed right below the form… where we didn’t want it.

The first task was to write a bit of JavaScript (using jQuery) that would copy the button dynamically inserted by the plugin into our footer element and hide the original one. This way, all styles and content were properly set. Next, we had to bind the click event of the button and explicitly handle validation and form submission. There was some Stripe integration work here, too, but that needed to be done regardless, so the extra cost to do it isn’t as embarrassing.

We’re already a few hundred dollars in at this point and it’s working! We have a pretty button in a slick footer that changes states, validates, and submits the form properly… finally.

A few weeks later, we enable Intercom on this part of the site and, lo and behold, the chat icon sites RIGHT on top of our new button! We hadn’t accounted for Intercom in the original designs and weren’t in a position to build the components necessary to lose the default Intercom icon. The button had to go.

The decision was to lose the sticky footer globally and go with inline buttons. In addition to being blocked, it was potentially blocking other components like social icons or remaining form data.

The new button — a basic button underneath the form

An hour or so of development later and we had completely removed the sticky footer, deleted the code that copied the form button there, and restored the original button that the plugin was building into the page. The button in the form was right where it had begun and it worked great.

Trying to find some humor out of this whole ordeal, we counted the time it took in development and discussions to sort everything out and came to a total cost — our checkout button cost us $500 to implement.

It may not be the prettiest, smartest, or tallest button in the world, but it’s ours and we love it as if it’s perfect.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.