Picking the right development stack for a project can be difficult, especially if you are learning as you go. Lately, I have been playing with a few Headless CMS. Sadly, I find some didn’t quite cut it. Realizing this inspired me to write this post. Whether you working on a new innovative project as a freelancer, in-house developer, or just for fun, below are factors to consider.

Knowing The End Goal

Start off by understanding a high-level overview of the main successful user flow. Easy enough. Afterward, go into more details as to the workflow, but not too low where you begin speaking about UI designs. That’ll be a limiter throughout development.

Then you will have to pry deeper to foresee points of failure and establish a correction workflow for them. Correction workflows are basic steps of the user (or app) that will take if something goes wrong and how it’ll be rectified. Keep in mind that you may need to also do correction workflows for your correction workflows… Going through workflows with a client will help him/her to understand the complexity of work.

Establish deadlines and budget you have. If these aren’t established before development, then later down, “something” can happen and may force you to take shortcuts. This can be good or bad depending on how it’s handled. As for deadlines, you may set weekly, bi-weekly, or monthly milestones. Either case, a good understanding of the technology stack being used is needed to balance user deadlines and how long it’ll take to build features. With that said, you may have to come back to this step after addressing the below factors.

Documenting these will help keep development on track and to provide a clear picture of where you are and where you need to be.

Development & Maintenance

Cost, cost, cost, cost… In the end, if not enough money is there, then a number of things can easily fall apart. You’ve got to support yourself and your family, your client needs the money to survive, support the application’s infrastructure maintenance costs, fund future development, etc.. At least a cost-benefit analysis should be done.

No matter the environment, there must be an efficient way to debug and reproduce bugs as they happen. Not saying you are a bad programmer! But they will happen, and if you aren’t able to fix the issue in a timely manner, then fingers are typically pointed to developers. While the blame game works itself out, you can focus on being the hero and fix the bug.

You can’t forget about security! By default, all modern applications need to be built in a way that does NOT prone to vulnerabilities listed in OWASP Top Ten. To the very least, your tech stack needs to be able to defend against them. Otherwise, the technology is not mature yet, or you just haven’t found a way yet. Keep in mind that you should not ignore the 3rd party libraries/packages being used!

What does development look like? This is up to you. Loosely typed languages like NodeJs are fun for small projects. The trouble, however, creeps in as the code base grows larger over time. Type checking, IntelliSense tools, etc. are not as helpful as for strongly typed languages like C#. Therefore, it takes longer to debug. If this is the case for you, then you should use a different language or just allocate more time within estimates for debugging. Again, you also have to consider what working with 3rd party tools will be like. To see a few more factors to consider, read this quick post

One language or framework may not always be best for the project, multiple may be needed. After looking at the trade-offs you may decide that using DotnetCore would be best for building an API and Python for web scraping jobs. The only downside is that you will have to manage runtime environments, SDKs packages, etc. for both in development and production.

Must have strong documentation and support. One of the biggest traps developers fall into is believing that new and trending tools are the best! By nature, it seems developers are early adopters of tech, so it makes sense. Yes, new tools are “suppose” to be better than older tools, but it’s crucial not to overlook the need for strong documentation and community support. The documentation has to be very detailed and must address all components on how they work, integrate with other components, along with best practices. When documentation fails, community support should be the next place for help. If you see a lack of information or poor support (Red Flag!), then chances are you may have to get a specialist for your project or what you want to achieve is not possible. This applies to libraries and packages (core and 3rd party).

Lifetime support is ongoing and consistent. It doesn’t make sense to use SDKs, run time environments that are no longer being supported in the near future, right?

TL;DR;

1. Know exactly what you want to achieve for your project:
   • Establish timelines and budgets before development begins.
   • Main successful workflow established.
   • Corrective workflows should something go wrong.
2. Development and Maintenance:
   • Keep costs within budget.
   • Be able to debug and reproduce bugs, especially ones found in production.
   • Make sure the tech stack is safe against OWASP Top Ten vulnerabilities & can deliver according to deadlines.
   • Strong documentation and support exist.

This best solution is not black and white, there will be some gray areas, but the best we can do is to minimize this area by looking at different trade-offs.