Build vs. Buy Software for Ecommerce: The Ultimate Guide

In 2025, enterprise software spending is pegged to grow 9.3%. Now more than ever, organizations are investing in enterprise software not just to expand their tech stacks but as the core engines that drive growth.

Many businesses are tempted to put their internal development staff to work to develop a solution when confronted with the cost of enterprise ecommerce integration software. The initial costs of building seem cheaper, and the development personnel is already on-staff. It’s just another straightforward development project to add to your team’s workload, right?

Not so fast. Building your own integrated e-commerce solution is a huge undertaking and should not be underestimated. 

If you’re deciding whether to build or buy software, any technology you adopt must seamlessly align with your business goals—and business requirements trump software features. Building or buying ecommerce middleware or software integrations that don’t meaningfully help your company stand out or align with your goals can be wasteful.

In this guide, we’re breaking down the buy vs build framework software dilemma to help you make an informed decision on whether to purchase ecommerce middleware off the shelf or build a solution customized to your business.

Questions to Ask When Deciding Whether to Build vs. Buy Software

Don’t make the mistake of launching into a software development project or purchasing enterprise software without considering the following:

• Is the business issue we’re trying to solve specific to a small business area, or does it have more significant ramifications?
• What is the urgency driving our decision? Is solving this issue a matter of vital importance or convenience? 
• How often will we rely on this solution? Daily, monthly, annually?
• Is this problem unique to our business, or does the solution to this problem currently exist on the market?
• Has our internal team developed anything like this before?
• Can we guarantee security and protect the data of our customers?
• Does our internal development team really have the resources to jump headfirst into an integration project?
• How much will it cost to build and maintain this solution? Do we know what the ongoing costs will be?
• Do we want to focus our development team’s time and attention elsewhere?

The Build vs. Buy Software Dilemma

In today’s economy of global knowledge, your company needs to be agile enough to compete. How do you achieve this agility? By continually improving your business workflows to provide the best products and services through effective middleware in ecommerce.

Now, there is an increased need for work management systems that depend heavily on integrating information and data within the company to streamline internal processes.

There are various reasons that businesses in the ecommerce industry may need software solutions. You should evaluate ready-made solutions first in most cases since you can implement them much faster. However, what if none of the ready-made software can solve your unique business problem? Therefore, the dilemma exists in buy vs build framework your custom solution. 

And while the decision to create a custom solution just for your business may seem like a logical choice, it’s not suitable for all organizations. Before deciding to build, it’s wise to consider several points and possible outcomes.

There are four key factors to consider when deciding whether to build vs. buy software for ecommerce integrations:

• Cost
• Control
• Connectivity
• Maintenance

These factors will become the foundation of your decision-making, so research is key to making the best decision for your business.

Decision Framework

When deciding whether to build a homegrown solution vs. buying from an ecommerce software vendor, you need a framework to determine which way to go.

Cost: What is the most efficient and cost-effective solution?

Most companies tend to favor the most cost-effective solution for their business. When building in-house, you can decide how much to spend on development. However, IT projects often take longer than forecasted and end up costing you much more. 

Research shows that building custom software is time-consuming and expensive—53% of build projects cost 159% of the original estimate. Even worse, organizations admit to canceling 31% of build projects that initially held promise but became too costly to see them through.

When making your decision, remember that your budget must include any long-term technical debt associated with maintaining your build, in addition to any upfront costs. Once you factor in the cost of internal support, upgrades, bug fixes, and keeping up with market trends, the cost overrun can be immense. 

Purchased solutions often have perceived high upfront costs, however, this is a known cost that allows you to budget your business expenses more accurately. These fixed costs greatly outweigh the risk associated with building middleware in-house for many CEOs. 

“Working with a software partner that has already burdened these costs on your behalf through their domain expertise and experience will typically allow you to go to market much quicker and a lot closer to your planned budget.”

Using the correct ecommerce integration middleware allows you to leverage the expertise of engineers and developers within the provider’s company. There are teams responsible for maintaining software documentation and training clients who need it. Many of them offer continued support and will troubleshoot specific issues for you along the way.

When you purchase software rather than taking on the task in-house, you benefit from onboarding and support plans combined with service level agreements (SLAs). SLAs explicitly specify the services provided and costs associated with them, which allows you to plan and budget for ongoing software maintenance—typically at a reduced cost compared to what you’d spend for piecemeal work.

Control: Can you meet your company’s unique requirements?

If you’re considering building an integration in-house, you probably like the notion that the integration can be molded to meet your specific requirements (today and others as they arise). However, this means that you’ll always rely on developers to build it. 

You may not know that it’s common for companies to hire developers and be left with unusable codebases when they leave the company. This adds an ongoing maintenance cost of hiring new developers to familiarize themselves with the framework, then rebuild and iterate on the codebase.

According to the Adobe Enterprise team, if existing commercial software fits your company’s requirements by 60% or more, you should buy. While you won’t have complete control over that company’s product roadmap, many vendors are willing to listen to and work with customers when considering future product functionality. 

Connectivity: What fits best within your tech stack?

Every ecommerce company has an ecosystem of applications that must play nice with systems outside of the company, such as accounting applications. If your development team is capable of stitching together multiple, more minor fixes, building your own integration can help ensure that proper connections are made. 

However, it is likely that a more comprehensive and advanced integrations solution is already available on the market. Some of them can act as an extension of your existing application ecosystem rather than overhaul your IT teams arduously built architecture.

Maintenance: Do you have the resources to rely on your internal team?

When building software, you don’t have to rely on an external development team to manage new features or roll out software upgrades. However, most internal development teams simply don’t have the same bandwidth or expertise when it comes to complex architectures, which are common in enterprise applications. 

Creating and keeping software documentation in order and up to date may seem trivial, but managing that is actually pretty tricky when juggling other aspects of the team’s workload. This doesn’t include maintaining API changes, multiple integrations, and everything else.

When you want to build a new system, you should really be thinking about “what are the operational requirements for me to maintain this system” once it’s built.

“There are dozens of these behind-the-scenes factors that make things appear easy to build, but in actuality, very difficult to successfully maintain. Having someone else experienced worry about these intricacies can serve as a major competitive advantage when integrating.”

From data compliance to multi-tenancy, a dedicated development team equipped with the latest market insights will be better able to handle ongoing maintenance for enterprise-level ecommerce software.

What to Consider Before Building or Buying 

Now that we’ve discussed the factors that should drive your decision, let’s dig deeper into what to consider before building or buying an ecommerce operations platform to suit your needs, including:

• Readiness
• Use cases
• Project scope
• Resources
• Opportunity cost
• Building risks

Readiness: Is your business in a position to weather disruption?

You can’t walk into work one day and drop a development project on an unsuspecting team. Any change within a company brings some level of disruption, which should be accounted for when choosing whether to create or purchase a solution.

Despite best practices, many development and marketing teams operate in silos. Each team focuses on its own processes, datasets, and ways of working. Introducing a new software integration (whether bought or built) without preparing the organizational side of your business is a clear recipe for disaster. 

Yes, technology upgrades and replacements are crucial for the success of both your business and your customer, but your teams and processes must be in a position to embrace change. That said, you must evaluate the organizational processes that will become necessary when introducing new software.

Use Cases: Do you have a proper understanding of the use cases of the end result?

In the early stages of decision-making, it’s critical to answer the question of what use cases you intend for your new software to solve. The use case behind the platform or ecommerce middleware influences who the stakeholders will be. Who will use this solution regularly in their day-to-day lives?

For example, when building an integration for accounting data collection, analytics, and reporting, the stakeholders are typically CEOs, CFOs, and other executives who need to acquire profitability insights to gauge the organization’s success. 

A proper understanding of the use case(s) that the new platform or integration you’re building or buying must deliver wildly influences the requirements for the end result.

Project Scope: Is the issue you’re attempting to solve common in your industry or unique to your company?

Next, you must weigh whether the issues you’re attempting to address are unique to your company or common in the ecommerce industry. 

Many ecommerce business owners and tech leads today face similar challenges, most of which are already solved in enterprise ecommerce solutions. However, if your needs fall within edge cases beyond the functionality of platforms on the current market, you may have a good argument for custom development.

Complexity plays a role here, too. Trusted internal development teams can often handle a high level of complexity. However, if your integration must comply with data regulations, such as GDPR or CCPA, and span multiple geographical locations, it’s probably wiser to buy an enterprise ecommerce platform instead to save on resources and time.

A commercial solution that reduces the risk of any unintentional non-compliance will pay for itself when you compare the hefty fines you may receive if your in-house solution fails to follow regulations.

Resources Do you have enough people, time, and other resources to see the development project through?

When building internal ecommerce middleware software, you should first consider whether your company has enough resources to get it done–even if you go over budget. 

Most of today’s popular platforms have been in the making for several years. Creating an enterprise ecommerce solution requires an incredible number of people, including data engineers, developers, data scientists, UI/UX designers, and more. And once complete, these platforms need to be evolved to keep up with an industry in which a new standard can pop up any given day.

Before deciding to build in-house, you must also take the potential impact of pulling resources away from critical company operations into account. It’s usually wise to leverage third-party automation job infrastructure and event-driven APIs to scale your operations without reinventing the wheel. This allows you to integrate once and avoid maintaining multiple scripts, integrations, and disparate jobs.

Opportunity Cost: Will building an in-house solution distract your employees from solving more critical business problems?

In a perfect world, IT teams will focus on gathering data and building the technical infrastructure to collect, report, and predict critical business insights. Your IT team should exist as your company’s “big brain” that can offload insights to teams specifically designed to communicate and orchestrate tasks.

When tasks are beyond your IT staff’s comfort zone, it’s best to hand them off so that they can focus on what they do best. This may mean handing them off to a third-party solution that can amplify your team’s efforts. 

Time-to-value: Can your in-house development team build a platform within a reasonable time frame? Are your issues time-sensitive?

Having a shorter time-to-value will help you keep customers engaged and position your company ahead of the competition. 

Requirements fluctuate over time, and it’s easy to spend years developing software only to fall short of the requirements to use it. It’s possible that, as the market changes, your internal teams won’t be able to shift gears fast enough (or not at all), which significantly impacts your ROI. 

So, ask yourself, can your team develop a solution in a reasonable time frame? If they can, is it possible to ensure the final product accurately addresses the businesses issues you’re attempting to solve?

Finally, if the use cases are time-sensitive, how long can your company afford to wait for a solution? If time is of the essence, purchasing middleware will serve immediate needs, while building an internal solution can take years—and you risk not entirely solving your issues.

Building Risks

If you’ve decided to build a custom software solution, you should know that you’re playing with metaphorical fire. Let’s discuss a few of the risks of building so you can make a more informed decision. 

Will additional resources be available beyond the projected development timeline?

In software development, speed matters. One day can mean big profits or setbacks in a highly competitive environment like ecommerce. Timing can be affected by a variety of reasons, such as:

• Lack of resources
• The functional features of the final product were not determined in a timely manner
• The total time for the project was incorrectly determined
• The project manager doesn’t properly track task status
• An unexpected expansion of the project scope, etc. 

To avoid this specific development risk, you must ensure the maximum involvement of all team members involved in planning and executing the project. It’s essential to gather and analyze feedback from all project stakeholders at all stages. If your development speed suffers, you may have to consider an emergency team expansion, which can significantly increase the project budget.

Poor productivity is also among the top software development risks. This is most common for teams working on projects with long timelines (i.e., software development services).

A long project can mean team members waste time in the early stages, believing in the illusion that there is plenty of time. Often, poor productivity stems from incorrectly chosen project methodology, poorly matched team members, and poor project management. 

What about unpredictable external factors?

When running a development project, unpredictability is another enemy. External risks in software development are inevitable due to:

• Unforeseen market changes
• The sudden growth of a competitor (often with more resources available)
• Changes in consumer behavior and priorities
• Implementation of new government regulations

Can your development team afford to take on technical debt?

When a quick fix is necessary due to a less-than-ideal timeline and budget, your team may choose to take on technical debt. Technical debt is the future obligation to fix inherently flawed software. Sometimes, a team is forced to take on technical debt due to poor planning.

On top of technical debt, your team may lack the talent and finances to see the project through to completion. These two factors together lead to lost company time and money.

Can you build and maintain a secure ecosystem?

Strong security practices are essential, especially in the realm of data collection. If you’re considering building software in-house, you must consider data security and compliance. 

Data security isn’t a small concern—it’s a 365 days a year, no days off, forever type of effort.

The average cost of data breaches is highest in the United States at over $8 million per year. With the introduction of legislation such as GDPR, CCPA, and APP, lawsuits, settlements, and fines related to data security are also on the rise.

Ecommerce makes up a significantly increasing portion of total retail activity. As the industry grows, so do cybersecurity threats and data breaches, which lead to many business owners struggling to keep their company’s reputations in check.

Large-scale ecommerce retailers are frequently targeted by cybercriminals hoping to steal customers’ personal and financial data to steal identities or make unauthorized transactions. 

Unless you can guarantee security, the risk of developing an unprotected, insecure solution likely isn’t worth it. You’re backed by certifications and industry standards when you choose trusted third-party software. You will have the peace of mind that exists alongside a reliable software solution.

In addition to 16+ years of SaaS experience, Flxpoint has network firewalls, full disk encryption, code vulnerability scanning, traffic monitoring, and more in place to make it more dependable than an in-house solution.

Buying Risks

A trial is often ideal for a smaller business but becomes more challenging to implement at the enterprise level. New software often comes with a lengthy onboarding process, which is necessary to ensure success with new technology. Before deciding to demo or sign up for a trial of any software solution, familiarize yourself with the risks of buying versus building a solution yourself.

Can you trust a third party?

One of the most enticing reasons to purchase ecommerce middleware instead of building in-house integrations is to benefit from knowing you’re working with a trusted software vendor

Enterprise-level companies can be victims of malicious cyber attacks, which lead to compromised client accounts. In fact, there’s a pretty good chance that your data has been inadvertently exposed in a vulnerable system at some point.

There are several practices that can improve data security, including evaluating security processes, data loss prevention, data encryption, and implementing governance, risk, and compliance methodologies.

You can further reduce your company’s cybersecurity risk by putting strong authentication methods in place, such as OAuth for web-based systems. However, breaches do occur even when a company follows cybersecurity best practices. It’s worth extra consideration before willingly allowing your company to become a potential target of large-scale cyber attacks.

Does the existing software address all of your needs?

Another risk of opting to work with a vendor is whether their existing solution satisfies your company’s needs. Let’s assume that many ecommerce retailers face the same issues, so the software market is saturated with software options. It is still possible that no one third-party software addresses your specific use case. 

Many software companies are open to customer feedback and encourage suggestions when developing their roadmaps. However, if your problem is unique or limited to your niche, it’s unlikely that a company will develop a solution specifically for you.

Do you have confidence in the vendor’s ability to weather a market downturn?

Let’s say you purchase an ecommerce operations app and integrate it within your business processes. A year later, the company raises its pricing to avoid going out of business. Months after that, they end up bankrupt anyway. 

Now, you’re facing the same dilemma and kicking yourself for not considering the risks of buying software last time. When working with third-party solutions providers, you must be confident in their ability to weather the external factors that may affect the health of their business.

Reasons to Build Software

In most situations, it’s a better decision to buy rather than build middleware. However, there are reasons to develop a 100% custom solution. Some factors that may influence your decision include:

Full Control Over Data and Security

When you build a solution in-house, you are strictly accountable for what happens to your and your customer’s data. You don’t have to wonder whether a third-party vendor follows all data requirements if you’re relying on your internal team to secure your solution.

Build to Your Exact Specifications

Generally, off-the-shelf products are built to satisfy the needs of “most customers,” but sometimes certain features that are important to you may be lacking. If you can’t select or modify features to suit your specific requirements, developing your own solution may be less frustrating.

Your Code = Your Property

The code that you and your team create is your property. You may choose to build a solution if there is an opportunity for commercial development down the road.

Reasons to Buy Software

Your team faces greater responsibility when building software rather than purchasing it. When weighing the pros and cons of buying software, consider the following:

Economies of Scale

In most cases, it will cost less money to implement commercial ecommerce software than to build a custom solution. This is especially true when internal resources are limited.

Implement a Solution More Quickly

If a solution to your specific problem already exists, you can address it faster. Using commercial ecommerce integration software can significantly reduce delays and difficulties caused by process and system changes. Most vendors work with these clients to address change requests.

Out-of-the-Box UI

When you can plug into an existing software solution, you’re able to eliminate the costly design phase of an integration project. Also, because many customers use the same interface, a large number of edge cases will have already been addressed—and UI optimization will occur faster.

Fewer Security Risks

When you entrust a software vendor to handle all data security and compliance concerns, you offload the responsibility of managing customers’ data. 

Unexpected Payoffs

Making the decision to purchase software instead of building it may not only turn out well at the time but deliver more substantial, unactivated benefits down the road. You might end up with capabilities that you didn’t know you needed—let alone even possible. When you purchase, you can be up and running (and realizing value) more quickly. Spending years developing and deploying an internal solution can lead to missing out on unrealized opportunities and behind your competition.

The Phases of an Integration Project

As an ecommerce retailer, selecting the right ecommerce middleware can make or break your integration success. The buy vs build framework becomes especially relevant when considering long-term scalability and maintenance requirements.

Let’s take a look at the pros and cons of each by first examining the phases of a typical integration project.

If you’re here, you most likely already know that integrations are quite intricate. Sure, your team will face plenty of initial technical challenges, but there are several other factors to take into account. Two companies may come to the table with entirely different organizational structures, people with competing agendas and skillsets, dissimilar processes, and different work management systems. These are all factors that add to the intricacy of the integration process. 

Here, we’re going to focus on one portion of the process—considering whether to purchase commercially available ecommerce integration software or develop a custom application using existing company resources.

Spelling Out the Requirements

Before you can accurately assess the pros and cons of a build or buy decision, your team must clearly spell out the requirements for data integration. This includes:

Defining the Communication Path Between the Two Environments

What deployment model will both companies use? What are the specific authentication, authorization, network security issues, identification, information, and data to be used during the integration?

Selecting a Common Data Model 

You must select a common data model to correctly map data exchanges. This must happen to guarantee that any necessary data transformations between systems occur properly.

This step is critical for any successful integration project. Correctly mapping data exchanges is especially important in a cross-company integration scenario. A two-space text field will not map to a three-digit text field, no matter how many times the two teams force the issue. Sure, this may sound trivial, but there have been real instances where developers have spent countless hours troubleshooting a “minor” issue like this.

“Every 3rd party is different and has their own nuances, which forces you to contend with their bugs or nuances in addition to your own. Partnering with someone that’s dealt with this hundreds of times already can let you worry less about the tech behind the scenes and more about the business rules that are empowered by that integration.”

Identifying Redundancies 

Next, technicians must identify possible failure paths and the notification protocols that will take place in case of probable failure. In the case of unforeseen system crashes, there must be a formal rollback system in place.

Establishing Data Tracking

Any cross-company integration application must have a tracking system to log all data transfers to ensure the data integration is complete and valid. This is necessary to conduct regular audits of data transfers which secure the reliability of the integration.

Coding the Required Application Functionality

Once all of the necessary integration requirements have been gathered, developers can begin to code the application’s required functionality. This can be an arduous task, even if it appears relatively straightforward. 

Programming the functionality may seem straightforward enough, but the hard work comes in deciding how to handle expectations and errors.

Today, developers code the most sophisticated applications to capture and deal with data errors and exceptions without the need for the application to terminate. The application’s functionality must include alerting any identified integration issues back to the appropriate person on the technical team.

Validating the Integration Functionality

One of the most difficult aspects to tackle after integration development is validating the functionality. The integration or application must be vetted by being subjected to many tests for performance and functionality. 

These tests must also validate the availability and stability of the integration so that duplication or similar errors in the integration process don’t cause the application to crash.

Teams must also develop tests to identify unexpected errors that lead to application crashes—causing a devastating unintentional loss of data. For example, expecting a three-letter country code (i.e. ALB for Albania) to cross into a two-letter text field as AL will never work.

Managing the Production Roll-Out

Once your ecommerce middleware  has been thoroughly developed and validated, it’s time to release it to the production systems of the companies involved.  The middleware in ecommerce must be rolled out carefully to ensure business continuity.

The integration rollout needs to occur in two different systems at once, so implementation into these systems must be completely transparent and accessible to the end-users. Any unplanned disruptions can cost your company thousands of dollars—or more—in lost revenue.

Application rollouts must also include emergency rollback plans in case of system failure or other consequences caused by the integration or ecommerce middleware application.

Creating an Ongoing Monitoring Plan

Your team must have proper monitoring in place to ensure your new application is continuously monitored for reliability and accuracy. It requires trained personnel to spot and report unexpected service interruptions and data anomalies. 

Customization

Don’t make the mistake of thinking an integration is finished upon rollout. Business processes in every industry tend to be pretty dynamic, so additional customization requests will surely begin to roll in. 

This is when the reality of in-house development kicks in. Your team will likely receive continual requests to make changes to your initial solution, always seeking to make the integration “better.”

Unless your development team added functionality that allows end-users to make changes to workflows (unlikely), they would have to work on any customizations. The development teams of both organizations must coordinate any customizations, as most companies are sensitive about sharing sensitive internal data. Therefore, this can be a lengthy process.

Maintenance

When it comes to software projects, maintenance accounts for most of the costs. It’s likely that these costs are even higher for integrations built to connect data between companies. 

In software engineering and development circles, it’s pretty common knowledge that maintenance accounts for most of the costs associated with software projects. Industry experts estimate that over 90% of product development costs are the regular maintenance costs that most companies forget to account for. It’s safe to say these costs are even higher for cross-company integrations.

These costs are high but only reflect the difficulties in maintaining custom in-house applications. When it’s time to upgrade or entirely replace these applications, they must be modified or completely rewritten. 

Don’t forget that the original application’s documentation will need to be maintained, updated, or rewritten as you rollout changes. This can become a puzzle in itself as original developers or tech personnel leave and knowledge isn’t entirely conveyed to new employees. 

Together, all of this can create a perfect storm of problems that will dramatically drive up project costs and make customization difficult to maintain in-house.

With Flxpoint, you benefit from an entire team of developers that spends 20% of their time maintaining the product so that you can run your ecommerce business worry-free. 

Changes

Business environments are unpredictable and can change quickly. As we mentioned in the beginning, your company must be agile enough to fluidly accommodate changes and remain competitive. When you develop integration applications in-house, you add an additional layer of complexity to customization.

Continual changes like these can dramatically impact cross-company integrations, and it’s typical to expect several configuration changes (on either side of the integration). These changes may include new permissions, workflows, data fields, and possibly new insights from using existing processes.

An example is adding new data points to existing processes to eliminate the need to perform an additional check.

However, custom integrations aren’t built to flex for these customizations so dynamically. Unless you have a solid change management process in place, changes require business and technical coordination on both ends.

The Consequences of a Wrong Build vs. Buy Software Decision

By now, you realize the buy vs build framework software dilemma implies that each decision has pros and cons in specific situations. While a custom solution can be a useful option, it presents more extreme costs and risks.

First, if you make the wrong decision, you’ll simply waste resources. The wrong decision won’t bring value, and your problem will remain unsolved. 

Second, if you decide to develop a solution in-house when the answer lies in existing software, you’ll doom your company to an unnecessary waste of time and money. However, if you choose a ready-made solution when you have the time and skill available, you lose the unique opportunity to create actual value, solve problems, and bypass the competition.

However, remember that not all vendors are created equal. You want to purchase from a provider that is highly experienced and focused on a distinct product domain with a strong track record in their niche. Expertise, onboarding and implementation experience, SLAs, and support all matter. 

In the research phase, determine how much development is being put back into the platform. Ask about the product roadmap, understand any feature release cycles, and always seek feedback from existing clients about their experience with the solutions provider.

Invest in Your Business by Purchasing the Right Ecommerce Software

When integration becomes a vital part of optimizing workflows and ecommerce management systems, you’re faced with choosing to develop the integrations in-house or purchasing commercial middleware. It’s the typical build-or-buy software predicament.

When considering ecommerce integrations, remember that customizations must occur on both ends. How will development teams on both sides work together? As systems are updated, how will the teams retrofit the new solution? Can that even be done? Who is responsible for application documentation? Maintenance? What happens when a critical internal developer moves on to another company?

Each of these factors can significantly drive up inefficiencies and costs. 

Thankfully, you can avert most of these issues by incorporating the right ecommerce middleware. Sure, the initial costs are higher, but they drop off dramatically in the integration’s actual building and maintenance phase.

When leading digital transformation is a top priority and resources are sacred, investing in a complete ecommerce operations software can maximize execution and reduce costs more than any homegrown application ever could. It also ensures a specialized solution that a dedicated software partner can continuously improve. In turn, your IT staff can concentrate on what they do best: core business processes. 

If you’re currently comparing options for reliable ecommerce software solutions, look no further than Flxpoint. 

We built Flxpoint so that you don’t have to—talk with an expert today to learn more.