The End of Off-the-Shelf Business Software?

Expanding our interests into the professional sphere inevitably means getting to know some of the less appealing aspects of a given field as well.

Since this website is largely dedicated to web design and application development, I will limit myself to these areas rather than delve into specifics that fall outside this scope. That does not mean, of course, that other areas are any less interesting. Quite the opposite - there are plenty of fascinating and sometimes surprising relationships to be found there, too.

Although my attempt to enter the automotive industry, understand its underlying mechanisms and assess its condition began with marketing, I have to admit that what interested me most from the outset was the broader picture of the market. In particular, issues related to process automation, work organisation and management.

Archaic and problematic solutions, limited data exchange and working methods that seem to belong to an entirely different era came as little surprise. What is worth emphasising is that these observations apply to both the Polish and international markets.

On the one hand, this situation can be rather discouraging. On the other, it creates considerable opportunities for the development of business software. In many cases, even the first relatively straightforward implementations can significantly change the way an organisation operates. This means a market with substantial room for growth, but also the challenge of convincing potential customers to embrace changes that often require abandoning long-established habits.

My experience so far does not suggest that Polish businesses are particularly reluctant to invest in automation. Nevertheless, my first direction of exploration was the overseas market. And no, I do not mean the East.

Accessing information about the internal organisation of businesses is, of course, not easy. That is why I initially focused on aspects that could be identified, or at least inferred, from publicly available websites of companies operating in a particular industry.

In the automotive sector, and more specifically the motorcycle market, the most noticeable issues include the lack of automation in SEO and GEO activities, customer communication, test ride organisation and other initiatives aimed at prospective customers.

Initially, I focused on streamlining product catalogue management and preparing a solution that could be presented to selected businesses. These are, however, areas where discussing the details could easily lead to matters covered by commercial confidentiality.

A much more accessible subject for presentation is therefore customer relationship management and other processes involving end users. These do not require going into the details of a company’s internal organisation or the way it manages its product offering.

One observation that probably comes as no surprise to most people familiar with this market is the extremely low level of integration and data exchange between the various tools used by the organisations I have encountered. In the vast majority of cases, it is difficult to speak of any coherent IT system at all.

Test Ride Automation

If even relatively simple processes are barely automated, developing a solution that improves the situation does not necessarily have to be a particularly complicated undertaking.

One of the first applications I decided to present to selected potential customers was a straightforward system for managing test rides. In the motorcycle industry, this process still boils down, in most cases, to providing a dealer’s phone number or a contact form.

Knowing that this would not be a particularly demanding task, I made decisions regarding the required workload and technology stack on an ongoing basis, with the aim of minimising development time. PHP, Laravel and a ready-made dashboard based on Tailwind CSS may not have been the solutions best suited to my preferences, but I was already familiar with their capabilities and knew what I could achieve given my previous experience and the time available.

As a result, after approximately one week of work, a finished system was ready to be presented to potential customers. Despite several limitations – including the lack of an API, the inability to embed the customer-facing component on a dealer’s website and a few other shortcomings – the solution is still being used by several businesses overseas.

A Second Attempt, Not Quite a Do-Over

The situation more than three years ago bears little resemblance to today’s possibilities for developing applications. Back then, my primary coding assistant was Copilot, initially in its free version and later as a paid subscription. I purchased the latter mainly to see whether it offered significantly more capabilities than the publicly available version. And, to put it bluntly, after two days of testing I stopped using it and quickly forgot about the subscription altogether.

It is difficult, however, to compare its capabilities at the time with what today’s AI agents have to offer.

With the limitations and shortcomings of my previously developed system in mind, and having become familiar with the capabilities of even some less popular AI models, I decided it was time to revisit the concept. I wanted to find out how long it would take to prepare an improved alternative, free from the inconveniences identified during the first attempt.

My experience in CMS design, web design and application development, combined with a general understanding of the subject and familiarity with various AI models, allowed me to estimate fairly accurately how much time would be needed to implement the planned functionality. Ultimately, my estimates were not far off the mark.

I can already point out, however, that this is not a matter of one or three days, even if you have a fairly clear concept of the system and a defined functional scope within which an agent can carry out its assigned tasks.

There is no denying that a substantial part of the technical work can now be delegated to AI. Agents are capable not only of implementing project requirements, but also of helping identify previously overlooked elements and proposing solutions to problems that arise during development.

What I find interesting, however, is how an attempt to create a similar system would look in the hands of someone with no previous experience in application design and development.

Could the current capabilities of AI agents compensate for gaps in technical knowledge and a lack of a structured design approach? Would the result ultimately be a product genuinely suitable for deployment? And to what extent would it be capable of eliminating the problems identified at the outset?

Conceptual Prototype

As I have already mentioned, the system discussed in this article is primarily intended to verify assumptions about the current effort required to develop applications and the capabilities of selected AI agents.

On the other hand, this is not meant to be merely a demonstration of technological capabilities or a mock-up illustrating how a future solution might work. The objective is to create a fully functional system that can also be used in a production environment.

Business considerations, however, remain outside the scope of this project. The application is not being developed with commercialisation in mind, although a more advanced version could not only find an audience but potentially perform very well in a rather rigid market.

Given the considerable amount of time I devote to the Royal Enfield brand, this was the obvious choice. Importantly, it is also a rather interesting organisational case. The company importing the brand’s products holds not only the exclusive rights to represent it but – and this is by no means always the case – practically the entire dealer network is also under its direct management. This is no secret, either.

Such a structure makes it possible to address the needs of the dealer network while looking at the project from a much broader perspective than would be possible with a solution developed exclusively for individual dealerships. It also allows for the inclusion of dependencies and functionalities that might otherwise fall outside the project’s scope.

MVP

After compiling a fairly extensive list of functional requirements for the MVP and selecting a technology stack that should allow subsequent versions to be deployed quickly in a test environment, with the option of migrating to an easily accessible production environment if necessary, it was time to fire up the IDE – on steroids.

In the case of this test ride management system, I find presenting the concept and the complexity of the solution itself far more interesting than discussing in detail which models were used, what environment they operated in, where problems occurred and how many tokens their work consumed.

Contrary to what one might think, developing an application designed to streamline the work of at least 11 dealerships and automate their existing processes is not quite as straightforward as it might seem.

The first version of the product, meeting the minimum functional requirements, was ready and running after just a few hours of work. That does not mean the project ends there, however. The real challenge lies in mapping the entire range of currently used processes while also taking into account new possibilities and dependencies worth anticipating in such a system. And, as it turns out, there are quite a few of them.

Dealer Portal

The remainder of this article will therefore not be a description of recreating a small fragment of reality, but rather an attempt to present the possibilities and explain why this particular subject deserves a much broader approach.

Contacts generated in connection with test ride bookings reach businesses through various channels, from different sources and on different occasions. The first is the standard booking form available on the main website. Others include one-off events and event series covering specific groups of activities.

Enquiries come not only from the main test ride page on royalenfield.pl, but also from individual event pages, landing pages, blog posts and external websites.

This is further complemented by platforms used for marketing activities and lead generation, such as the Google advertising network, Google Business Profiles and Meta services.

Such a fragmented range of sources, combined with the need to manage individual dealerships and distribute enquiries coming from both the main channel and numerous in-house events or events organised by external entities, means that an approach limited solely to lead aggregation would be insufficient.

What is needed is a solution that takes into account not only the acquisition of contacts but also their subsequent handling, assignment to the appropriate dealerships and integration with the other elements of the process.

Motorcycle Fleet

The variety of channels through which enquiries arrive and the need to distribute them correctly among dealerships are just one of many dependencies. Naturally, the system must also account for the availability of motorcycles designated for test rides, their location, technical condition and current status.

The system must therefore allow vehicles to be excluded if they are damaged, sold, undergoing servicing, being relocated or temporarily unavailable due to other business requirements.

Unfortunately, automating the management of all these aspects will not be possible under the current circumstances. Most related activities will therefore have to remain the responsibility of individual dealerships. This includes updating mileage, changing vehicle status and activating or deactivating motorcycles in the system. The objective is to ensure that outdated or incorrect information does not negatively affect the experience of customers using the booking form.

Since the people responsible for the fleet are also those who have direct contact with it and access to the most up-to-date information, the entire process should be made as straightforward as possible.

At the same time, management of the model catalogue and its categorisation should remain the responsibility of the central administrator. This means employees at individual dealerships will not have to enter this data themselves and, more importantly, will not be able to introduce incorrect or inconsistent information. Their task will simply be to select motorcycles from a predefined, standardised catalogue.

Staff

The availability and technical condition of a motorcycle obviously affect whether it can be booked for a test ride. It may not be the most sophisticated way of putting it, but people are an equally important resource here. After all, someone has to prepare the motorcycle, hand it over to the customer and collect it once the ride is over.

It is therefore necessary to take into account the availability of employees at individual dealerships. This is not limited to holidays, full-day absences or trips related to participation in events. Shorter periods away from the workplace and other absences are equally important and need to be considered in terms of specific hours rather than entire days.

In short, a module allowing employees to manage their own availability and report absences is essential.

And since these employees will also be users of the administrative interface, they need an appropriate environment in which to perform these tasks. The system must therefore also include a user management module covering their personal details and assignment to individual dealerships.

Naturally, the system must also account for situations in which more than one employee is responsible for handling test rides at a particular dealership. In such cases, the absence of one person should not automatically make a given time slot unavailable for booking. Availability should only be restricted when all employees authorised to handle test rides at that dealership are unavailable at the same time.

Working Hours

Taking employee availability management a step further, a natural solution would be to create a subsystem that allows each employee to define their own absences while also providing access to a list of people authorised to manage these settings.

The data entered in this way will be automatically taken into account by the application and reflected in the information displayed to customers interested in booking a test ride. This will also help reduce the risk of discrepancies between employees’ actual availability and the information presented by the system.

Dealerships

The list of dealerships and their parameters should be configured by an administrator, given the low rate of data changes in this area and the fact that management of these matters falls within the responsibility of the company’s management.

Dealership configuration must primarily include its name, address and contact details, status and an individual identification code used as part of the vehicle registration number.

Another important parameter is the dealership’s general availability, defined by regular opening hours that determine the time frames within which bookings can be made. Given the possibility of organisational changes, it is also worth providing options to configure the standard duration of a test ride, a buffer between consecutive bookings to allow the motorcycle to be prepared for the next customer, and the maximum booking horizon.

The latter parameter should prevent both last-minute bookings and reservations made too far in advance. In the latter case, for example when booking six months ahead, changes to the fleet or current product offering could lead to serious organisational problems.

It is also worth providing the ability to define days on which bookings are unavailable, both at the level of an individual dealership and globally across the entire network. This would make it possible to account for public holidays, days off and other dates when test rides should not be available.

The configuration could also include links to external services associated with a particular dealership, such as social media profiles or its Google Business Profile. These could be used, among other things, to redirect customers to an external form where they can leave a review of the dealership.

Access Management

With a larger number of users operating within the system, mistakes resulting from everyday work are inevitable. There will also be natural differences in the responsibilities and duties of individual employees. A properly designed access management system therefore becomes essential.

The fundamental principle should be the separation of individual dealerships. Every employee performing their duties at a particular location should have access exclusively to the data and functionality associated with that dealership. They should neither see information nor be able to perform operations related to the activities of other locations.

This approach not only reduces the risk of accidental errors but also maintains a clear system structure and establishes well-defined areas of responsibility for individual users.

Login security, including two-factor authentication (2FA), must also be considered. Within this project, however, these aspects will largely rely on solutions provided by external service providers.

The primary method of accessing the system will be authentication through a designated Google account. The association between the account and the user, along with its parameters, will be recorded within the application, while authentication itself, including mandatory two-step verification, will remain the responsibility of Google services.

Events

As mentioned earlier, events – whether organised individually or as part of larger series – play an important role in the motorcycle industry. This is particularly true when their programmes include making motorcycles available for test rides.

Accommodating this type of activity affects several independent areas of the system.

First, events involve employees from the dealer network, which may prevent individual dealerships from accepting bookings during their regular opening hours. For this reason, both the event date and any associated employee absences must be taken into account by the system and appropriately reflected in the end-user interface.

Second, events of this kind frequently involve changes in fleet availability. Motorcycles from the central warehouse and individual dealerships are transported to the event location and subsequently returned to their original locations. The system must therefore account not only for the event itself but also for the time required to transport each motorcycle in both directions, the duration of the event and any additional buffer needed before the vehicle can become available again at its original dealership.

Equally important is the diversity of events themselves, which should be reflected in the way the user interface operates. The frontend must respond to parameters determined by the nature of a particular event and support both individual events and entire event series.

In the case of an event series, users should be able to select a specific event within that series. For a standalone event, the interface can operate in a simplified mode without the need to display additional selection options.

Regardless of the chosen scenario, all widgets should be designed for embedding in different environments: on event pages on the distributor’s website, royalenfield.pl, on the homepage, in blog posts and on external websites. This ensures that the booking mechanism remains functionally consistent, regardless of where the user begins the process of arranging a test ride.

Bookings and Information Flow

I will move on to the frontend component of the system, intended for end users, in a later part of this article. For now, it is worth discussing the process that should take place once a customer has completed the booking procedure and their data has been successfully transferred to the backend.

First, every enquiry should receive an individual identification number. For the sake of clarity, it is worth using a format that incorporates the booking date, an individual dealership identifier, a network identifier (with potential future system expansion in mind 😉) and a unique hash to ensure that every ID is distinct.

The system should also store:

• the date and time the enquiry was received,
• the parameters of the selected service, including the motorcycle model,
• the details of the person making the booking,
• the scheduled service date and time.

An important element in ensuring the system operates correctly and eliminating the risk of the same motorcycle being booked more than once is assigning a specific registration number to every enquiry. These registration numbers should be predefined in the system and then assigned automatically during the booking process.

If a motorcycle with a particular registration number has already been booked for a given time slot, it should automatically be removed from the pool of available vehicles for subsequent customers interested in the same model.

An additional control mechanism, limiting the possibility of employees in the network creating fictitious bookings, should be the requirement to enter the motorcycle’s actual mileage whenever a booking is marked as completed. This involves two independent readings: the odometer reading before the motorcycle is handed over and the reading after it has been returned. This will make it possible not only to verify actual vehicle usage but also to maintain its operating history.

Trust, but verify. 😉

The booking management panel should, of course, allow the status of every reservation to be modified and provide advanced filtering options. In addition to the booking number itself, it should be possible to search and sort records by dealership, scheduled date, motorcycle model, status and other booking parameters.

The scope of visible data and available operations should depend on the permissions of the individual user, their assigned role and the dealership they are associated with. This means dealership employees will have access to the information necessary to manage their own bookings, while network administrators will have a correspondingly broader range of control and data management capabilities.

Notifications

Successful receipt of a booking should, naturally, be communicated both to the person submitting the enquiry and to the employees responsible for carrying out the test ride.

There are several ways to achieve this. The natural and most basic solution is to send an email confirming that the booking has been received. This channel can also be used to communicate subsequent changes in the booking status.

Personally, however, I believe that requiring users to additionally confirm their booking through a message they have received is not so much a featureless solution as simply an outdated one.

First, the message may never reach the intended address. A simple typo in the email address or the message being classified as spam is all it takes. Requiring users to log in to the system, while representing a certain attempt to address email-related problems, may in the case of such a simple task feel like an unnecessary way of collecting additional data and complicating the entire process.

This does not mean that email communication should be abandoned. Quite the opposite – it is worth automatically sending both a booking confirmation and a thank-you message after the service has been completed.

The second message is particularly important, as it creates an opportunity to collect customer feedback and encourage users to leave a review on external platforms, including Google Business Profiles displayed in search results and Google Maps. This is not only a way to gather valuable feedback but also an opportunity to build a positive perception of the service and the professionalism of the entire organisation.

Automating the process also opens up much broader communication possibilities that go beyond traditional email. Push notifications and messages delivered through popular messaging platforms remain important communication channels worth incorporating into the target system architecture. This would not only improve the effectiveness of information delivery but also allow communication methods to be adapted to users’ habits.

Reviews

Feedback concerning the experience and quality of the service, customer support, the overall convenience of the process, potential problems and suggestions for improvement should be collected and presented in a dedicated overview.

This means creating a separate module that allows users not only to browse collected reviews and ratings but also to filter them, inspect detailed information and analyse feedback according to selected parameters.

The collected information can then be used not only for ongoing assessments of service quality but also to identify recurring problems and highlight areas requiring further improvement.

RE.View

Those following Royal Enfield’s activities in the Polish market have probably already noticed the launch of the RE.View programme, which allows the standard test ride duration to be extended to two or three hours.

The programme is primarily aimed at content creators and people preparing motorcycle-related materials, for whom the standard period of access to a motorcycle may not be sufficient to present its capabilities properly.

That does not mean, however, that this option cannot also be used by people who would simply like to spend a little more time on the road with a motorcycle of their choice.

To increase awareness of the programme, reach potentially interested customers and make it easier for them to take advantage of this opportunity, it is worth integrating its management directly into the application.

For this purpose, the end-user frontend should provide an option to indicate interest in participating in the RE.View programme, followed by the selection of one of the available duration options.

It is also worth including a dedicated section explaining the programme, together with a link to its landing page, where interested users can find additional information and familiarise themselves with the details.

Naturally, selecting an RE.View option, which extends the test ride by an additional one or two hours, must be properly reflected in the motorcycle availability management mechanism. A booking should block the selected motorcycle for the entire period of its use, including any additional time required to prepare the vehicle and make it available again. This will help prevent overlapping bookings and the organisational problems associated with them.

One-Page Checkout

The backend design, or more specifically the dashboard, should of course follow established UI and UX standards, allowing users to navigate naturally between pages without disrupting the familiar patterns of interaction they have developed over years of using basic web applications.

It does not, however, need to be polished to the absolute limit. Inconsistent margins or a colour scheme that does not follow the brand guidelines are perfectly acceptable, provided the system itself is functional.

The end-user frontend offers considerably more room for experimentation. Naturally, the design should remain consistent with the brand’s main website, but if we do not want to adapt it separately to every other website where it might potentially be displayed, it should also incorporate a reasonable degree of versatility.

There is little point in discussing the mobile-first approach in detail, as it is now standard practice. To illustrate this trend, it is worth mentioning that mobile users account for more than 80% of all visitors to royalenfield.pl, a figure that has remained relatively stable for at least two years.

When considering the appearance and layout of the customer-facing interface, my reluctance to spend an excessive amount of time on this particular aspect, combined with my own habits, ultimately won out.

Given that e-commerce has accounted for a substantial proportion of commercial online services over the past few years, these were also the types of applications I had the most experience with.

And so the idea for the final component of the system was borrowed directly from the world of online shops and the content management systems they use.

The One-Page Checkout layout may not be the ultimate or even the best possible solution, but it is a little like democracy. One-Page Checkout may be the worst form of checkout, but no better alternative has yet become widely established.

Although perhaps a more accurate way of putting it would be that no better solution has yet become widespread.

As mentioned in the individual sections, the checkout and its dependent modules are influenced by a whole range of factors.

If the form is displayed on a particular dealership’s website or on a page dedicated to an event associated with that location, the Select dealership or location field is hidden. The relevant data is automatically matched with the dealership specified in the data parameter.

If the checkout is intended to handle bookings for a one-day event, the date selection field is hidden instead.

Depending on preferences, the section relating to RE.View can also be displayed or hidden.

And this is essentially how it works with every element. Virtually all configurable options can be defined through parameters in the embedded code, eliminating the need to repeatedly configure the required settings in the management panel.

Another useful feature for customers, which also contributes to a positive perception of the service, is the automatic display of the contact details of the person responsible for the booking. The appropriate contact is displayed based on the dealership or event to which the booking is assigned. Naturally, the module also accounts for situations in which more than one person is responsible for handling bookings.

In keeping with the overall approach, all parameters selected by someone interested in a test ride are displayed together in a separate column. This allows users to review and verify their choices before clicking the CTA button.

Live Demo

Although, according to the original assumptions, the system and its individual components were not designed with full production deployment in mind, the ongoing development and maintenance of royalenfield.pl eventually encouraged me to make a booking module (checkout) publicly available, configured specifically for the needs of the Royal Enfield Kraków dealership.

Following the logic described earlier, the field allowing users to select a dealership or a specific event within an event series remains hidden in this case. There is simply no need to complicate the interface with options that are irrelevant to this particular scenario.

Testing solutions directly in a production environment may not be the most textbook approach. Nevertheless, the specific nature of the entire undertaking needs to be taken into account.

For years, I have effectively been working simultaneously as an architect, UI designer, developer, graphic designer, tester and project manager. On top of that, I have accumulated a fairly substantial team of my own assistants, although they are still entirely intangible.

Sticking rigidly to procedures that do not necessarily fit the realities of small, niche projects could therefore easily become an exercise in bureaucracy for its own sake.

https://royalenfield.pl/salony/krakow/

I can therefore confirm that the system operates in accordance with the assumptions described above and is available as an alternative way of booking test rides at the Royal Enfield dealership in Kraków.

A New Reality

In a rather rigid and anachronistic automotive industry, the solution described here, even at the prototype stage and created essentially for the sake of experimentation, can represent a considerable innovation.

Verifying the initial assumptions, however, leads to much more interesting questions and conclusions.

Are we already witnessing the twilight of the SaaS model, off-the-shelf CMS platforms and closed, generally exorbitantly expensive and often archaic business solutions?

Are distributed systems and frameworks that have been developed over many years facing a similar fate, or, quite the opposite, are entirely new opportunities opening up for them thanks to AI?

Developing a fully customised management system tailored to specific requirements is now faster and more accessible than ever before.

In the context of micro, small and medium-sized enterprises, this raises the question of the most rational path forward: building their own comprehensive ICT ecosystems, relying on solutions that have been available for years and may not be perfect but have already proven themselves in practice, or combining both approaches?

Or perhaps it is worth waiting for the emergence of agencies offering comprehensive software development services at prices comparable to what businesses currently spend on maintaining and operating off-the-shelf systems?

This is not merely about reducing costs or replacing one tool with another. Equally important are seamless data flows, the ability to support further business development, the automation of tasks that previously required considerable manual effort, and access to information whose collection, aggregation and processing were once economically unviable or simply impossible.

And perhaps it is precisely this last area where the greatest transformation lies. Not so much in the way software is created, but in the ability to build tools that genuinely address the needs of a particular business, rather than forcing it to adapt its own processes to the limitations of a purchased solution.

Tighten repeated explanations throughoutClarify prototype versus production status