You glance at the Slack message that just came in.

Approval for the launch on Monday is go.

Out of habit, your eyes dart to the corner of the screen. 1:30pm. The day’s already more than half over.

This morning everything in Staging was golden. Everything worked, was tested, and the launch was green-lit.

BUT, one of your last minute tests revealed that the data failed to pull from one of the CRMs. You tested it manually, worked just fine. Again. Again. But then every so often it just times out.

You spend the next few hours troubleshooting, checking your code, and testing different approaches. Fed up, you load up the web portal of the CRM and hit F5 like 23 times and eventually see ISE 500. That system is under too much load for whatever reason that has nothing to do with your app.

“Monday launch might have to be delayed until IT resolves that,” you think to yourself. You send a Slack reply to let everyone know.

And that’s kind of how this project has been lately. One thing after another kept popping up that had to be fixed. Numerous functions had to be reworked. One 3rd party service had to be switched out due to limitations. The list goes on.

But in reality though, that’s how every project is, am I right?

Not just development, not just technology—but everything.

There’s a difference between “It works,” vs “We’ve stress-tested everything for 2 weeks, it’s good to go.”

“I finished editing the promo video,” vs “It’s been recorded, edited, color corrected, bumpers added, audio has been remixed, rendered, exported to 4k, 1080p, mobile vertical, uploaded to the video platform with SEO taken into account, given a title, descriptions added, tagged, and embedded on the landing page.”

You’ve heard of the Pareto Principle, if not by name, then by its other name, “The 80/20 rule.”

• 80% of output is done by 20% of the people.
• 80% of your revenue comes from 20% of your customers
• Etc.

In a way, the principle applies to the above scenario too. The first 80% of a project takes X amount of time. The last 20% of a project is much more difficult and therefore also takes the same X amount of time. At least that’s how it feels.

“Everything costs twice as much money and takes twice as much time than you anticipate,” said someone’s wise mom.

It’s always the last 20% that’s the hardest. The last 20% to get the thing out the door. That’s when the bugs pop up, the issues arise, the delays, the ISE 500s.

It’s like this:

Easy Mode With Decoupled Software

Eliminating Hard Mode is not possible.

Well, it is and it isn’t, depending on your perspective. Let me explain.

How hard is it to stand up a form on a web page? Easy. There are 100 drag and drop tools that will do this for you—decoupled from whatever else you’re trying to build. In the OLDEN days of the internet, it was hard—real hard, but now that’s been relegated to Easy Mode.

So, has hard mode been eliminated? Yes, if we are merely talking about standing up a form on a web page.

But…

• What if you need complex forms?
• What if that form is connected to an app, 3rd-party service, or legacy system?
• What if you need a LOT of forms that need to be managed?
• What if you want to reuse forms you’ve already built, but for different contexts?
• Where does the data get stored and how do you access it with other software?

When one problem is solved and made easier, new problems present themselves as considerations to be made easier. We start increasing scope, in an ever expanding drive to solve the next problem in the sequence. That’s innovation.

The more functionality that is decoupled from traditional application development, the faster you can build and innovate for your users and customers.

That’s what we do for developers.

So your next development project can look like this:

“Just like that you can blaze through the building of your infrastructure with just a few clicks. Front-end, back-end and database all found in one solution.”