We had a long standing rhetorical question at my previous job. A question that has come up many times during my career: Should our software set the standard for how people should work, or should our software adapt to how people already work?
In a previous role, when the company first started, the team saw an industry with many different ways of working and felt that we could standardize things. We attempted to introduce conventions for working best, just as Ruby on Rails had done in the programming world. Convention over configuration. This worked for some customers...
However, when you’re a startup, you have to do what it takes to survive! I’ve seen this many times where the team has a vision of what they want a product to be, but then the market has different ideas or needs. It can be hard for software people to accept, but you have to adapt to make the business work sometimes.
As time went on and we were scaling our business, we saw that that was not going to work. We were dealing with big companies that expected us to accommodate their needs and their ways of doing business. From a business perspective, we couldn't afford to pass up on opportunities because they weren't ideal customers.
Over time, we developed several key "tools" that made it possible to adapt our software to our customers:
- Every application that is handling a wide variety of customers will at some point need a 'Custom Field' system. This is especially true if you're working in the enterprise with a wide variety of customers. A custom field system allows you to add additional fields to store your customer's data without continually adding more database columns. This allows each customer to have fields specific to their needs. As a contrived example, if your customer is a brick and mortar store, they might have a field called "store_location" to track where each employee works. Another customer that has remote employees would not require this field since that wouldn't make sense for them.
- A conditions system can turn functionality on or off depending on logical statements that are configured through the UI. Many companies have this functionality, such as Zendesk. This is a fundamental and necessary feature to build in the flexibility that is needed when business logic gets hairy. Business logic can live in data (through this condition system), rather than hard coded in the codebase. This system can be powered by Liquid so that it is possible to compare any data that is wanted.
- A rule system can handle special requests from customers around orchestration. It is a "pub sub" system that can be triggered at certain times from the application, and then take certain actions. Let's say that a customer wants their new users to be notified via email when they sign up. Written in the codebase, when a new user signs up, it will broadcast that event through the system. Then, any Rule that is listening for that trigger knows that the event happened and will take action. In this case, the action can be sending an email.
- Finally, an Email Template builder allows your application to send highly customized emails depending on your customer's preferences. This allows you to brand their emails or insert specific content depending on the customer’s needs. One thing I've learned over the last ten years of my career is that email is serious business. Users get upset when they receive too many emails, and customers get upset if emails contain incorrect information. This system allows you to be flexible to your customer's needs.
This set of tools provides the building blocks you can use to implement any customer within your application.
One of the last projects that I worked on at my last job was to build a BPMN Workflow system. This was a domain-specific workflow system that was built to solve the needs of the business. However, in reality, the Workflow system we created fundamentally was not that different from systems such as Zapier. The goal of the workflow system was to create an environment in which the customer could take control of the technology themselves. This was mutually beneficial for both the customer and us. For us, the cost of customer support for customer specific changes would go way down with this technology. For the customer, they would get the results from the software themselves way cheaper and quicker.
This kind of system can be a long term goal for your organization. However, building out this kind of a system is a huge investment for both time and money. This may be overkill in the beginning stages of your company. In the beginning, you just need something that gets the job done as cheaply and efficiently as possible.