<img height="1" width="1" style="display:none;" alt="" src="https://dc.ads.linkedin.com/collect/?pid=60438&amp;fmt=gif">

As a software development company, we’re sometimes confronted with situations when the tools made by others simply aren’t satisfying our needs. That’s valid for both tools that could help us progress with our projects, as well as devices that could make our lives easier around the office. To avoid the compromises imposed by highly opinionated frameworks and counter-intuitive tools, we decided to combine our software development and project management skills, and develop our own instruments, which we’re going to detail over a series of blog posts.

The first of them isn’t a tool per se, but more of a collection of components that help us in the initial stages of any project, be it a mobile app or web platform. ‘A way,’ as we like to call this collection, enables us to set up the architecture and the structure of the project so that future building blocks can be added to a firm foundation. By referring to this collection as ‘a way’ and not ‘the way,’ we wish to emphasize two aspects. First of all, there are changes in the industry that could determine the creation of more such ways, and secondly, this is not a one-size-fits-all solution. 

What Exactly Is a Way and Why Do We Need One?

In the past, each project required a different framework for the backend, frontend, and the mobile side of things. In the case of a web application, for example, the back end (BE) is represented by servers with no graphical user interface (GUI) that store and process the data, communicate with other services, and send emails. The second component is a browser app that represents the app’s front end (FE). Its GUI enables the user to interact with the backend. On top of all that, there might be a mobile app with similar functionality but with a different user interface. Depending on the nature of the product, more components could be added, some that feature a GUI, and others that don’t.

The problem with third-party frameworks is that they’re strongly opinionated. What that means is that they lock software developers into one way of doing things. Since each of our projects has its particularities, the third-party frameworks’ standard way is not always entirely fit for what we need. Differences might occur in how the files are structured, where they need to be stored, and how the code should be written.

Our way combines all the required components and a method of using them, and since it’s created by us, it has two immediate advantages. On one hand, it’s a custom solution that’s tailored according to the needs of the project. On the other hand, it leaves no room for the compromises we would otherwise have to make when using third-party frameworks.


The one that’s currently in the works is called Earendil, and while it isn’t exactly built from scratch, it has the daring mission to “Be a light in dark places, when all other lights go out.” If you’re familiar with fantasy books and/or the movies inspired by them, the name and the mission of our first tool should sound a bit familiar.

The purpose of this way, like any other starter kit is to:

  1. Codify a long list of decisions, best practices, and lessons learned
  2. Prevent forgetting important details
  3. Encourage consistency
  4. Avoid repeating work
  5. Increases quality because automation favors the perpetuation of the best practices

This way uses well-known frameworks, design patterns, coding style guides and combines them in a unique way so that we can start implementing features as easy as possible, and with little to no friction.

An app built with our first way is a responsive web app that runs smoothly on mobile devices, laptops and PCs. It uses such modern technologies and ideas as Angular2, Docker, Node.js, MongoDB, Microservices, Angular Material, and many others.

Besides being the tool that makes the seeds and brings them all together, our way of starting a project also includes a way of doing Continuous Integration and Continuous Delivery, a way of writing automated tests, a way of doing peer code review and a way of doing pair programming. 

What Is the Purpose of Having Our Own Way?

Time is an invaluable resource, and saving it through every means possible helps our project teams become more productive. One of the main advantages of the ways we’re creating is the automated creation of parts that are common to most if not all projects. For example, since we’re developing products for other businesses, rather than for the end-users, each of them requires registration and login forms, user profile designs and administrative tools.


By automating some parts of the process we reduce human errors that would occur while doing the repetitive tasks. An organized way like the one we’re setting up now also enables entire teams to have the same vision on how the product should end up.

At the end of the day, we aim for win-win situations. These ways of starting projects are beneficial for both the project teams, who get to do more things in the same amount of time with fewer human errors, and for our customers, who ultimately receive their product earlier than if a way weren’t used.

What’s the Fate of the Old Ways and the New?

Ways based on deprecated technologies wouldn’t be abandoned completely, as there might still be of use for some projects. Hence, in the context of multiple ways, one of them might end up as a legacy way that will be used whenever the projects require so.

On the other hand, the launch of new technologies or of new versions of the already existing ones will allow us to create more proprietary ways of starting projects. However, developing a way is a time-consuming task in itself, and by the time it’s finished, other technologies might emerge. To stay on top of the times, we need to adopt new technologies as they become available, while not necessarily including them in our ways of starting a project. 

What Does the Future Hold in Terms of Ways?

In the near future we mean to create a way for each type of project that we’re developing. While that might sound like a simple case of mix-and-match, it’s never that simple. Development of embedded or telecommunications apps will require specialized components that either need to be integrated properly into one of the ways, or must be built from the ground up. Machine learning and AI are two other possible directions that could benefit from a way, should the need arise. Topic aside, we think that it’s important for every company out there, from software development entities like us to aerospace manufacturers such as SpaceX, to develop a proprietary set of tools and guidelines for using them, in order to provide the best possible service or product.

At some point, there might be several ways of starting each project, and choosing one over the other might prove challenging. For example, there might be two ways that fit a particular project, each with its own components and methods. If the team finds out that the components of one way would work better with the guidelines of the other in this particular case, a third way could be born.

Regardless if we’re speaking about present or future ways, the idea to keep in mind is that we can adapt to accommodate different needs and projects of various types, from mobile and Web apps to complex platforms that combine both of them. Besides a high degree of adaptability, another consequence of the fact that we’re building our own ways is represented by the organizational skills that we’re developing and improving along the way.

Want to know what other tools we’ve developed to make our work lives and the ones of our clients easier? Stay tuned, as the next post in this series is already in the making! 



The Essential Role Of Trust In Product Development

As you get ready to build your product, you'll need a team you can trust to take the best possible decisions.

Download it now

Ilie Ghiciuc, Founder & CEO

Articles similar to this one