Just today, I was thinking back to when I was the CTO of a brand-new start up in the geolocation space.
It was about 13 years ago, and we had grand visions of changing the world (we didn't), but the experience stuck with me. Granted, there's been a lot of water under the bridge since then, but what I remember more than anything was the fluid nature of, well, almost everything.
Our most critical pacing factor wasn't the main product application, but the constantly-changing applications we built to support the main app. The product was the product, but there were probably another 4 or 5 custom applications that supported the various bits and pieces of operations, finance, sales, and marketing.
Essentially, we built our support apps at the same time we were envisioning the business model (read: constantly). However, at the velocity we were moving, we were lucky if most support applications were within 2 or 3 iterations of the current business model state at any given time. Naturally, the main app was the dog while everything else was the tail.
It was like changing the tires on a car rolling down the street. Our dev teams never gave up, but could never keep up.
Not surprisingly, the OPS app-lag situation got worse over time, especially during the 90 days prior to launch. All our attention was product (and money) focused, while support applications ran a distant third in terms of importance. So, what we ended up with was a mess when our focus hard pivoted from product to monetizing the product and OPS apps became the priority.
So, today I tried to visualize the impact that a new low-code development platform like Quick Base would have had on our ability to iterate and maintain our operations applications.
I have to admit, it was striking.
Though we had really great DEVOPS teams, during 2005 and 2006 their go-tos were .NET and some full-stack application frameworks. This meant that much of the daily change load we'd throw them at the end of each day never really got completed—or was obsoleted by the next day's events.
Regression bugs were legend. Lather. Rinse. Repeat.
In the new world of low-code development, however, these same developers would have been able to code, test, and deliver our apps in a fraction of the time (along with a fraction of the regression bugs). Even better, many tech-savvy business folks would have been able to build or tweak much of the somewhat less complex stuff themselves in generally less time than it took to document for DEVOPS what we needed done.
The Low-Code, super-agile development model won't work for many apps that face the world, but for our internal OPS apps, POCs, and other non-client-facing stuff, low / no-code would have been simply magnificent.
Now, 13 years later, I’m proud to implement those learnings at VeilSun, the low / no-code development partner for a number of very high-growth agile companies. We're who they call when they need it—and they need it yesterday.
If you need rock-solid, secure, and high-performing low / no-code applications in hours and days (not weeks and months), let us help you discover the low / no-code advantage.
Ping us anytime to chat about your organization’s Low-Code transformation.
