Developers love tinkering with code and figuring out how cool stuff works. Given no constraints, many of us would be seriously tempted to build our own tools for everything - some of us, even our own operating systems. We constantly start new pet projects to learn something new or to try out the latest hyped-up libraries. If we don't have the opportunity to dabble with all the interesting things at work, we continue coding on our own time. Developers simply love building stuff.

In a professional setting, where time and money are your typical constraints, many developers still prefer to build products from scratch. These Purists appreciate the feeling of complete control over the development process, and the sense of achievement as the crafter creator of the web app they've built by integrating their developer DNA into its every detail. They know exactly what's going on in every process, between the processes, on every layer of the tech stack they've hand-picked, configured and optimized for their project.

There are obvious advantages to the Purist approach, and sometimes keeping all the options open is the right way to go. From a commercial perspective, however, there are not too many options. Purist developers excel in environments with time and budget to create web apps in their preferred way. They are highly opinionated, skilled, sometimes specialized, and cannot be easily convinced to cede control of their technical decisions to someone else, e.g. a 3rd party commercial product.

In most organization, the role of software is to enable and support the business, not to be the business. Inside these organizations, developers need to maintain their productivity in an environment with limited time, long backlogs and plenty of constraints. Constraints are plenty – typically resource, technology or business related. This would not be an ideal environment for a tinkering developer: the pace is too quick for building and maintaining custom solutions made from scratch. Instead, this environment calls for a Pragmatist developer mindset.

Pragmatic developers have a strong focus on getting stuff done. They are interested not only in developing software, but also the business itself. They understand that every technical choice is ultimately a balancing act between tech and business needs. And business needs have to be fulfilled, since there'd be no need for software without a successful business.

In this kind of setting, it's easy to understand why pragmatic developers are willing to invest in tools that improve their productivity. A great tool won't necessarily give them everything they ever wanted, but if it cuts development time in half while utilizing the team's existing skills, allowing the team to focus on actual business problems instead of input validation and event handling, the ROI starts to look pretty awesome.

In large organizations, and especially in organizations where complex business domains are mirrored by complex organizational structures, all impactful technology decisions tend to be made higher up in hierarchy, further away from developers and their first-hand experiences. Technical angle is presented indirectly through C-level or management roles. The further up technology choices are discussed, the bigger and broaded decisions can be made from a top-down strategic perspective - in good, and in bad.

In this kind of a setting, the preferences of an individual developer, or even established practices of a team carry much less weight. Developers might be in control of some technical aspects of their projects, but organization policies dictate larger themes, such as the languages, tools and tech stacks used. Sometimes a forced technical decision may generate resistance, but ultimately developers need to make things work with the tools and platforms they're given.

Platformists are the third kind of developers in this category. It's not necessarily a nurtured mindset, but more of an accepted state of things where they are willing to operate. Platformists give away the most of their developer freedom, but can still be happy and productive in what they do – as long as business requirements can be met with the features the platform offers.

From a commercial point of view, Platformists have the least impact on technology decisions in their organizations. A commercial product needs a top-down approach: first introduce and sell the value proposition to top-level business decision makers. Then, take the product into limited use inside the organization. If things look good – and you definitely want to ensure developers succeed quickly and repeatedly with your tool – you get the grow adoption into other teams as well.

This is by far the segment with most volume. Most business web apps are used by some tens of users, and are built to support a specific internal business process. These apps have typically quite loose specifications, and not that high end user expectations either. Thus, developers have relatively lots of freedom to choose how they get the job done.

Since these applications reside at the lower half of their organizations' priority lists, they get little love from developers as well. Not that developers wouldn't want to do a good job here; they just don't have the time or budget to do things properly. Either you do something quick and dirty (Purists), speed things up with a free framework (Pragmatists), or find a blueprint in your commercial platform that will fulfill the business needs (Platformists).

Commercially, this segment has very little direct commercial potential. The ROI of the situation doesn't support any investments to software tools. But indirectly, this is a great opportunity for a product with an open-core business model. Small web apps with low risks and low external pressure are perfect playgrounds for trying out new developer tools in production. Positive experiences with the free offering can result in further adoption within the organization, and eventually lead into a commercial opportunity when stakes are higher and the ROI improves.

This segment has a very broad range, and the end user count is more of a rule of thumb than a strict line. The more important factor is how at some point the attitude and focus of the development team shifts from one set of priorities to another.

In this segment are mission-critical business web apps built either for internal or external user bases. Lots of business value is generated through the processes these applications control. Dedicated business, product, development and support teams are organized around these apps to manage their feature sets and lifecycles.

Where there's business value, there's also opportunities for commercial developer tools.

When your app has reached a certain level of maturity, and its scale has grown to a point where basically at any point of time you have thousands of concurrent users, your priorities start to shift. Everything needs to be carefully managed, and all the development and deployment processes need to be adjusted for the scale of your operation. Consequences from a bug that slipped into production and crashed thousands of users' workflows would be catastrophic.

Performance is another aspect that gradually gets more and more attention. This means that a simple single-page web app which started as a small project needs to be rewritten and thoroughly refactored into a scalable, manageable architecture with caching, load-balancing nodes, cloud storage etc. Everything becomes distributed, custom code split between specialized development teams.

When you build your web application's tech stack on top of a generic framework, bring in lots of components and libraries from various sources, and add your glue and business logic between the pieces, you are doing things in a decoupled fashion. In theory, this should be a fast and cheap way to get things done, but you need to bring the quality into the process by knowing from experience what works and which pieces play well together.

If you don't have the experience, or any opinions, you will have a bad time and start from scratch multiple times.

This is how Purists are made.

Full-stack tools offer an opinionated, comprehensive solution to building web apps. When your tech stack can fit a full-stack framework, you can focus more on solving business problems than figuring out all the basic necessities of a modern business web app.

There's always a learning curve to a framework. A lot of decisions have been made for you throughout the stack, and it takes some time to wrap your head around the framework and its best practices. This approach gives you a quality and a cheap solution, but it's only fast if you know how to play with, not against the tools.

Enterprise-level low-code and no-code platforms have traded quality to low effort. Once you've adopted and mastered your way with this kind of tool and understand the patterns and best practices, you can get good quality results done quickly with the building blocks and tools these platforms offer. However, it doesn't come cheap. Enterprise tools usually have enterprise price tags.