Why building small apps with a long-term mindset is a bad idea

Creating a minimum viable product for a startup is a skill that is quite lacking in this world. Over a decade working for startups, I took notice of patterns that might be damaging in the short or long term. In this series, I will share some stories and my two-and-a-half cents.

Lego pieces: third-party poopers

I resist Bootstrap and avoid it like the plague, but I had to comply with this particular client’s request. After less than a year of working and creating the first version, Bootstrap updated to version 4.0. Updating a CSS framework would never make it to our list of high-priority tasks. We were now stuck with an old CSS framework. We should have had our in-house CSS framework.

Gulp was the weirdest thing I ever had to adopt. It still does not make sense on many levels. But I needed to gulp-task my processes. I ended up installing all the plugins needed to get the process going. Little did I know that soon I would have to pull all gulp scripts out of every production repository I had, for a simple reason: they were no longer maintained by their owners.

What can go wrong?

Lego pieces are great for coming up with creative structures. But those structures remain exactly that: Lego pieces. When we put together an app using third-party libraries, we are essentially creating a structure of small pieces that do nothing special on their own. If that is the business model we are after, it should be fine. Rarely is it the case, however.

Misuses of libraries

I have seen libraries tweaked to do things other than what they are supposed to do. This is usually a junior’s mistake; the library is well documented, but the real native feature is not. Nor is it easy to use. The time spent tweaking libraries will undoubtedly add to a developer's knowledge. But it is quite destructive to your project.

Too many invitations

Everyone is invited to a library. Good library authors accept everyone with whatever theme they choose for the party. Great library authors dictate the theme and target a specific need. To make matters worse, the one scenario you want for your next project isn’t covered.

What can we do about it?

Using third-party libraries is sometimes unavoidable. We can at least take some steps to avoid future mishaps.

Research

It pays off to spend some time creating proofs of concepts for different libraries, to test and assess them. Keep challenging every new third-party framework or library to find out if you really, really need it. Weigh your options well. Why would you adopt Bootstrap? Does it really save time? Or add overhead and dependency?

Reduce levels of abstraction

When a library is first released to the public and made popular, more often than not, tons of feature requests come in to satisfy more use cases. To allow for maximum customization, the library authors add extra layers of abstraction. Sometimes to a ridiculous point. Abstraction bloat code, and infect performance. What you can do is seed the source code and remove any extra features you do not need.

Lookout for native as soon as it becomes available

I used to use one Material control: the Date control. It made sense to let someone else do the heavy lifting. I was never satisfied, however. Always wanted to change something. In one particular project, I needed a completely different calendar—this is still painful. When HTML date control was finally treated with respect by browsers, I stopped using the Material CDK. Native is always better for one reason: Jakob’s Law.

So those were my two and a half cents. Shall spend a dime in the coming weeks. Let me know what yours are.