"Customize Everything" - That sounds like a total dream. Well, we love dreaming and making those dreams a reality! This is why we do what we do and why we are planning this fracture buildout.

So, what does "customize everything" really mean within fracture? It means that we are going to be able to show and hide everything in the system. Users will be able to toggle on/off almost any feature or function. Companies will be able to customize the verbiage, flow and processes, as well as the look and feel to match their needs and wants. Like our iceberg analogy, mentioned above, these companies and users will be able to virtually expose just what they are looking for in a system, without the extra bloat or fluff. This will empower users to maximize their efficiency and productivity. That is exciting!

To speed things up, we will be including a number of different setup wizards to help walk users through the setup process, including industry specific presets, simple wizards, bulk settings, and even AI agents to help with the setup process. Other options will include custom dashboards and the ability to build your own interface(s). The goal is to make the system feel like it was built just for you and your industry.

Our existing product isn't really too far off from customizing everything. We have spent years and years building a transactional data core that is handling all of the primary business functions. This core is built on a stable foundation of permissions, settings, and templates. We want both the current platform and the new fracture buildout, to head in a direction we are calling "the value add-on core" model. This section is not big enough to share the whole vision of where we are heading for the full product road map. If you want to read more about the value add-on core, please see that section.

The system is very robust and versatile. It can be configured to do almost anything. This is one of the strengths of adilas but can be overwhelming to new users. The goal of the setup wizards is to help walk users through the setup process. This will help users get up and running faster and with less frustration.

Here are some of the ideas and plans for the setup wizards:

• Classic setup wizards - small decisions to help walk through the setup process
• Industry specific presets - automate industry templates and settings
• Bulk settings - set multiple settings at once
• AI Agent - conversation and natural language questions and answers
• Manually edit or update specific settings - fine tune your choices
• Transparency - be able to quickly see what is available and make changes as needed

We are planning the fracture buildout to be a hybrid, modular type architecture. Some people assume that modular means that everything is fully independent. For us, we are more of the mindset that everything has to play together as a system, but we can easily show/hide, and/or alter the layout and flow to make it seem more modular. The full adilas application and transactional core will remain intact and fully functional. This is the power behind the whole system. The new code and backend will be developed to facilitate this modular type approach.

Even though the core is fully operating behind the scenes, we will on purpose, only expose the needed parts and pieces. Similar to the iceberg analogy, the majority of the system will be hidden from view. This means that it will be built in a way that allows users or companies to select any feature or function they want to use. As part of this setup process, the system will automatically create a customized interface based on your choices. We will then allow you to further refine that interface and layout as you wish.

To further help with the modular architecture, we will be including industry specific presets, quick groupings for business functions, and other quick setup options. There will also be preset packages, dealing with size, and the price tag for system usage. These will range from free, clear up to full enterprise levels. Additionally, if users or companies are more interested in an ala carte type of approach, they will be able to pick and choose the features and functions they want to use. This will help keep the system more streamlined and focused on what is important to the user or company.

We realize that if you are dealing with coding and tech stacks, there are very strong opinions about how you do certain things. Our intention is not to start a discussion on what is best, right, or required. Our goal is to share some of the points and key concepts of what we will be considering for our new buildout within the fracture project (adilas lite).

We have done a lot of research and will continue to do so. We have also been doing some prototyping and testing of different frameworks and languages. That has been both a fun and educational process for us. We want to make sure that we are using the best tools for the job.

Ideally, we want to keep the development in-house as much as possible. We also need to balance what our existing team is capable of doing along with where we are wanting to go. Depending on our budgets and timelines, we may get creative within our team and/or hire out a 3rd party development team to help with parts of the fracture buildout. A key element for any of these options is making sure that the planning is thorough and well-documented.

Another key factor, especially in today's world, is the use of AI in helping to build and maintain the code base. We are looking at ways to leverage AI to help us write, test, and even document code. All of these pieces will help us speed up the development process, as well as help us maintain a high level of quality while we push forward on our fracture project.

We understand that training and support are crucial for the success of our users. Part of our design plan is a focus on intuitive and industry specific interfaces (UX/UI) to lessen the need for extensive training. We are also creating an AI agent that can act as a virtual assistant to help users navigate and operate the system. We want to make sure our users have the resources that they need to be successful.

Additional options that will be available to help with training are:

• Adilas University - online tutorials, webinars, and courses
• Adilas Marketplace - connect with experts and resources
• Education Mode - toggle on/off special learning features
• Setup Wizards - simplify and select industry specific options
• AI Agents - help with various tasks and functions

The API has limitless potential, hopefully we can help you catch a vision of some of the possibilities. Some people have heard the term "API" but what does that really mean? Without getting super technical, the API stands for the application programming interface. Basically, a way for computers to speak with other computers without a human needed for the interactions. In normal software or web applications, a user interacts with an interface and clicks, or types, to do something. Behind the scenes, the software walks through its coded processes to make certain things happen or function. This is the typical flow for software-based functionality.

API's come into play if you want to speed things up, skip steps, do multiple things at once and take out some of the human dependant actions. A well built API allows you to do all of the things that a normal user can do and far more, anything that you could dream up (coding wise). Through API sockets you can change the order, alter security protocols, complete transactions, and use different simplified interfaces. Multiple phases and multiple processes may be automated behind the scenes. Unlimited possibilities. Super cool!

We like to think of API's like an electrical socket on the wall. You are able to plug into it and then get a result. Each socket or API endpoint allows you to do different things such as business functions or connections with the database. The bigger the application or business is, the more sockets, or end points there may be. Sometimes we show people a surge protector with multiple outlets to help them get the idea that there are so many possible options. Adilas.biz has over 2,000+ sockets. That's an awfully big surge protector! Each socket connects to logic or code that provides functionality which ties into the backend database application.

Assuming a basic level of knowledge about API's, let's talk potential. Remember, the full power of the underlying transactional data core is still there. You don't have to use the existing interfaces or flow, but the full function of the application is available if you want to use it. The API allows for usage over the top of what already exists. That allows you to code to just what is needed versus trying to rebuild everything from A-Z. So, returning to the API potential question - what can you do with API's?

• Create specialty products or interfaces - industry specific, mini apps, graphs/charts, dashboards, reports, UI/UX friendly, intuitive flow, etc.
• Design any flow or process - not limited to the underlying preset interface
• Direct flow and automation - skip steps, bulk processes, recurring tasks, etc.
• Define your own security protocols - your app controls all permissions and access levels, not the system user permissions
• Build to fill in the gaps - meet your individual needs and wants
• Dream it up..., the sky is the limit!

We have a master plan, or road map, for our product that is called the value add-on core. Adilas is going to build out the main transactional core (level 1 of 5). We will continue working on all of the other levels. However, any other level could be built out, and/or added to, with the API. We can't even fathom all of the possibilities. If you want more information about the value add-on core and all of the levels of the master plan, please see that section. Here is a quick overview for the proposed levels of the value add-on core:

Level 1 - Adilas Transactional Data Core
Level 2 - Industry Specific Skins
Level 3 - Custom Code
Level 4 - Business Intelligence (BI)
Level 5 - Enterprise (multi world)

We started the original adilas core back in 2001. At that time, testing was only something that you did as you built the different pages and functionality. Back in the day, we had one primary developer and he was in charge of the system. As new developers were added to the mix, and as time has gone on, the need for better, more structured testing has become evident. This combination of naturally growing the code base and meeting client needs, has helped us pioneer a successful web-based application and service our clients for over 20+ years.

Sometime between 2018-2020, more testing was generally added to our process. We have developers who are doing unit testing, mocking data, performing database connections, load testing, and running deeper integration tests. That has been a good shift for us as a company. Our plan it to continue along those lines, and even increase our testing focus.

The adilas user base has been a huge asset. We offer such a unique product and each company/user uses it in so many different ways. This has helped us get very unique testing coverage based on users and their system usage. We have actually added over half of our features based on user input, feedback, requests, and ideas. We love that. We plan on continuing in that path as well and will actively seek user feedback and input.

Additional focus on testing will help stabilize and improve ease of use as we keep building. Here are a few ways that we will continue with testing and integration plans:

• Functional and characterization testing - what does it currently do
• Unit testing - what are the individual parts and pieces - functions and methods
• Integration testing - how does it work with the other parts of the system
• Versioning and code repositories - historically tracking changes and auto deploying code to production servers
• Documentation, help files, and SOP's (standard operating procedures)
• Other testing and integration plans

This validation section deals with security of the data being passed around, and/or transferred, from client to server and back again. The term client-side validation deals with checks and balances before the webpage or form is submitted. This front end, or client-side, validation can really help with the user interface and user experience (UI/UX) parts of the system. This type of validation can help catch simple mistakes, typos, or missing information before the data is sent to the server. This helps speed up the process and reduces server load. If the data doesn't pass the client-side validation checks, then the user is prompted to correct the errors before submission. This is a great way to enhance the user experience and reduce unnecessary server requests.

Server-side, or backend validation, deals with what goes on once the webpage or form leaves the user's computer and hits the server. The server is the backend brains of the application. Backend validation is responsible for checking and making sure that anything submitted is viable and can be used in the requested action. This backend validation is very secure, it can exist in multiple levels, and may even be stacked if needed. If backend validation is used, and the data doesn't pass the validation checks, then the server throws an error. Depending on how deep it is, the errors will stop the process and the desired action is not completed. One or more error messages then get passed back to the client. Error messages are required for communication with the users. However, they may lightly detract from the user experience.

The best combination is a good mix of both client-side (front end) and server-side (backend) validation. We, as a company, are already doing a lot of this mixed validation. We are currently heavier on the server-side, but both options are being used. Moving forward in the fracture buildout, we will continue to keep the server-side tight. We also plan to enhance the client-side validation to make the whole experience even smoother for our users and clients.

We are focused on a desktop first design that is also responsive for tablets and phones. This means that the whole system will be built to work on desktop and laptop computers first. Mobile first design is great for simple apps, but we have built a complex app that needs a desktop first design. Most of our clients and users are physically at a computer while working on adilas. There is no way to get huge reports or data capture forms into a super small mobile view without losing functionality. Focusing on desktop first design allows us to create a full featured experience for our users.

Even though the focus will be on desktop first, we will be building out the entire fracture project with a responsive design. Responsive design means that the system will adapt to different screen sizes and devices. This allows us to create a seamless experience for users, regardless of the device they are using.

Full mobile ready design, and functionality, will be used in customer facing portals, ecommerce, and other specific use cases. We will also create certain admin and user interfaces that are more mobile friendly. Most of these smaller mobile friendly apps will help with specific tasks and functions. That will keep the mobile experience focused on the task at hand while still being able to fall back on the full desktop experience when needed.

One of the goals of fracture is to empower the users to customize their own user experience. That means that, based on the user and their device, they can toggle on/off any buttons, features, report columns, etc. That allows a desktop user to customize their workspace, while a more mobile type user could simplify their interface. This flexibility is key to ensuring that all users can work in a way that is most comfortable and efficient for them. Our users vary greatly, some like touch screen, others use their phones, while others are mouse and keyboard people with multiple monitors. Our goal is to create a dynamic application where each person feels in control of their own experience.

Our other hope is that outside users will catch the vision of the API and build out specialty mobile apps that connect to the adilas backend via the API. This would allow for more specialized mobile experiences that are tailored to specific industries or use cases. This could be simple native mobile apps, SPA's (single page apps), custom interfaces, or other types of mobile friendly apps. More information is available in the API section above or from the adilas marketplace.

One of our most encouraging lessons is that we are successfully creating an application that we've dreamed up and worked for. It is totally possible. We are systemizing business functions into an integrated platform that other companies have been separating into multiple different applications. We have been doing this on a garage budget, with limited resources, for 20+ years.

We have built up this application by prototyping features and functions to meet various needs. Many of these needs and wants have come directly from client input and requests. To summarize what we mean by prototyping, our process starts by determining a want or a need. Then we do research and brainstorming and figure out the plan. This could include trying to use new techniques or doing things that would further the product along. Where possible, we tend towards permissions, settings, and templates. Then we build it out and let others use it. They beat it up, and we make any revisions that are needed. Once it is being used and our clients are loving it, they often let us know what they want for the next steps. This pattern has occurred over and over again. This prototyping process has allowed us to build out the entire adilas application over the years. The result of this is a robust, revenue producing, and versatile system that is meeting the needs of our clients.

Our approach going forward is to continue following this pattern. If we do receive more funding, we will adjust our approach accordingly. This may include building out a more detailed master plan, using teams, hiring specialists, further AI integrations, and other development techniques. If no additional funds are available, we will keep dreaming up new ideas, doing research, experimenting, prototyping, building, and moving on. This is what we do! If you want to see an overarching view of our master plan, please see the value add-on core section.

With 20+ years of experience, there is no way that we could fully put into words all of the lessons learned. However, we have documented the whole process through a section that we call the "developer's notebook". This notebook has been a running log of ideas, concepts, lessons learned, and other notes that we have collected over the years. It has been a great resource for us to refer back to as we continue to build and improve adilas. Just as a sample, if you go to that page and type in the word "fracture", you will see a number of notes and ideas that we have collected over the years that relate to this new buildout. There are over 200+ entries just on that subject alone. If you want to checkout the developer's notebook, you can find it here: Developer's Notebook by month and year, or search the developer's notebook by any subject, use this link and associated form.

Life cycles are important to consider when building and maintaining any software application. There are multiple types of life cycles that we need to consider:

• Development and code life cycles - determine the need, brainstorm the fix, plan and build it, test it, deploy it, maintain it, upgrade it, and maybe eventually retire it - everything follows that pattern
• Data life cycles - who creates it, who uses it, how long is it valid, where does it go, what is it tied to, when to archive it, when to move it or retire it
• General hardware and software life cycles - when to upgrade servers, computers, devices, software, frameworks, etc.
• Plan for the future - technology changes fast, figure out what pieces will stay going forward, work to stay ahead of the curve
• Plan for the unexpected - things break, get hacked, go down, styles change, and priorities fluctuate

Another big aspect of software, and software as a service (SaaS), is that maintenance and upkeep are sometimes more important than making something new. That is really hard for developers and creators to accept. They love to build new and shiny things. However, maintenance and upkeep are crucial for the long term success of any software application. If you don't maintain and upkeep the software, it may get bugs, and it will eventually become outdated and possibly unusable. This is why we are putting a big focus on maintenance and upkeep as part of our fracture buildout.

Maintenance and upkeep plans will include:

• Building with maintenance in mind
• Testing and modular design
• API's and documentation
• Set certain maintenance schedules
• Planned life cycles and rollover - upgrades
• Help and education - update training as application is updated
• Allocated budgets for bugs, upkeep, and other maintenance
• Letting go - we tend to hold onto things that we don't need to - let it go

Fracture will make white labeling possible at so many different levels. Since fracture is modular, configurable, customizable, and dynamic, it will allow any combination of features, modules, and presets. The concepts in this fracture buildout project create the dynamic, foundational elements to build your own, unique adilas business application. We like to say your data, your world, your way. We love these concepts and really want to encourage growth of the system through white labeling and 3rd party solutions. Imagine industry specific skins, custom branding, specialty interfaces, custom reporting, automated flow processes, AI enabled dashboards and stats, and endless other options to make the system feel like it was built just for you and your industry.

To explore more options on white labeling, please visit the white label sections on either the adilas marketplace or the adilas investment opportunities pages. There are multiple options available to help you get started on your own white label journey. Come and check it out!