## The Legend of the Gordian Knot

When Alexander the Great traveled through what is now modern day Turkey, he came upon a curious challenge. 

In the town of Gordium in Phrygia was an ancient ox cart tied with a complex mass of knots known as the Gordian Knot. A local legend claimed that whoever could loosen it would be destined to rule all of Asia. Alexander struggled with the convoluted web of cords before determining, “It makes no difference how they are loosed.” 

So in one simple yet bold act, he slashed through the knot with his sword.

## From Alexander to the Modern MVP Philosophy

This simple solution to a complex problem could arguably be called—2000 years before the term came into existence—a minimum viable product, or MVP. 

When Alexander first confronts the Gordian Knot, the assumption is that he will attempt to untie all the pieces, which were described by the ancient historian Quintus Curitus Rufus as “several knots all so tightly entangled that it was impossible to see how they were fastened.” Instead, he tries a minimal, unexpected solution, and it takes care of the problem completely. 

Eric Ries popularized the concept of an MVP in his book The Lean Startup, saying, “the minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.” 

In other words, start simple, test, make adjustments; rinse and repeat.

MVPs are about challenging assumptions and trying solutions that may initially seem “too simple.” This doesn’t mean your final product will be too simple to do the job thoroughly (if that were the case, it wouldn’t be the right product for you), but it is a stage we begin at to better test assumptions. 

![Alexandar the Great cuts the knot and declares a new precedent for software!](/uploads/alexander-cuts-the-gordian-knot-563f2d-edit.jpg)

## Simplicity Through The Lean Startup

One of the great advantages to adopting this Lean Startup Methodology is that you may discover a far simpler-than-expected iteration of your product that satisfies your needs, saving you time and money. 

Of course, Alexander found a solution to his problem rather quickly, but there are many stages to building suitable software for your business. He also didn’t have more to keep cutting after that first successful slash. 

But creating software is an iterative process that requires refinement. In the spirit of experimentation, we build a simple product, test core assumptions, and make adjustments accordingly. We build and adjust in small stages until the correct product has been developed. In this way we avoid wasting time on features you won’t use, we save you money by not building more than you need, and the final product is stable and easy to use because it fits perfectly into its role in your organization.

### The Southwest Airlines Solution

This process takes humility. Cody Thompson, COO of business consulting company The Table Group, tells an intriguing story on his [podcast](https://www.youtube.com/watch?v=HW4iAwzUT9E) about how Southwest Airlines solved a problem they were having with customers accidentally throwing away their paper boarding passes before they reached their gate (Ah, the days before cell phones!). 

He explains that Southwest agents at the ticket counter “would print the boarding pass and the receipt on the same paper…and they had this huge problem where people were just throwing away their boarding pass because it looked like a receipt.” 

Southwest investigated several solutions to the problem, such as installing self-service kiosks or building out different systems, all of which cost millions of dollars. According to Thompson, the solution they ended up adopting was to “tell all their gate agents to write ‘This is a Boarding Pass’ in red pen on \[the] boarding passes, and it solved the problem almost immediately.”

![Boarding pass with a note written in red ink, reading: "This is your boarding pass!"](/uploads/boardingpass-southwest.jpg)

While self-service kiosks were emerging in the industry, Southwest chose not to adopt this new technology immediately. By staying lean, they found a simple solution with a red pen and waited to adopt the kiosk at a point that was right for them.

While red pens are far less sexy than new automated systems, Southwest had the humility to solve their problem in the leanest way. The resources they saved—from the initial cost, to ongoing maintenance, to training and onboarding employees—can’t be overstated.

## The Lean Software Ecosystem   

It is in this same spirit that we build the leanest software you need. 

Complex software ecosystems can be a burden on your team's productivity and morale. With too many tools to manage, employees might find themselves navigating through a maze of features, unable to focus on their core tasks. New hires will have a longer training and on-boarding process. 

On the other hand, a smaller, carefully curated software ecosystem makes your employees’ lives better, reduces potential points of cyber-attack, and simplifies security measures. A concise software stack is a boon for extracting valuable insights. Fewer tools mean better data integration, which provides a clearer picture of your business's performance.

So while the allure of large software solutions can be tempting for managers looking to boost productivity and stay ahead of the competition, we want to challenge the notion that more internal software equals better business outcomes. We encourage a strategic, streamlined approach to software adoption, focusing on essential tools that align with your specific needs. 

By keeping your software lean, you can adapt to new challenges and opportunities more efficiently. This adaptability allows your business to stay competitive and seize emerging trends without being weighed down by unnecessary software. 

## A Minimalist Approach to Cut Through Your Gordian Knot

When a client approaches us with a custom software project, they may carry with them some assumptions. 

For example, they may assume that the software needs to have a lot of features for it to fulfill the business goals. Or that it must be retrofitted to work with other products. Or that an entire system needs to be built, rather than just one piece. 

To make the best possible product for your business, we will need to step outside these assumptions and approach the problem from the perspective of creating the leanest version of your product, testing how it works, and building out from there. This process has been proven result into the best use of everyone’s time and resources.

And frankly, if you don’t need custom software, we won't recommend it.

![A TSG designer sitting with a client reviewing his app features.](/uploads/strategize-xcitedemo3-email.jpg)

We want to help you cut your Gordian Knot—that’s why we are committed to taking a minimalist approach to our projects and avoiding assumptions throughout the software journey. If you’ve got an upcoming custom software project, contact us to explore how our core values can ensure your project’s success.

AI Illustration of two hands untangling an abstract ball of yarn and fibers. 

See what an ancient legend can teach us about a lean approach to software development today.

Alexander the Great’s Approach to Software | TSG Article

Alexander the Great’s Approach to Software Development

When fast-food powerhouse McDonald’s wanted to increase its milkshake sales, they did the seemingly sensible thing—researched milkshake-buyer demographics, built focus groups, and collected input from customers about everything from taste, to viscosity, to price. 

They implemented the changes recommended by their customers, sent “better” milkshakes out into the world, and waited for sales to spike. Instead, sales remained bewilderingly the same. There was no significant increase or decrease. 

What went wrong? According to Harvard Business School professor Clayton Christensen, they began with the wrong question. McDonald’s had asked its customers *what* they liked about milkshakes. But they failed to ask *why* they were buying them.

## Understanding the “Jobs to Be Done Theory” 

Understanding the motivations for customer choices—the why behind the what—is the central theme of Christensen’s 2005 paper, “The Cause and the Cure of Marketing Malpractice.” 

In it he states, “When people find themselves needing to get a job done, they essentially hire products to do that job for them… If a \[business owner] can understand the job, design a product…to do that job, and deliver it in a way that reinforces its intended use, then when customers find themselves needing to get that job done they will hire that product.” 

In other words, if you need a quarter-inch hole in a piece of wood, you’re likely to “hire” a drill with a quarter-inch bit to take care of that job. But if someone designed a phone app that could zap holes of any size into pieces of wood, would you still go out and buy a drill? Probably not. You would choose to “hire” the app for the job of making holes. 

A company could pour millions into designing the most amazing drill ever made, market it beautifully, and people all over the world would continue to happily zap holes with their phones, because no one ever really wanted a drill. They wanted holes.  

This outcome-driven theory is known as the “Jobs to Be Done” theory (“JTBD”) because it’s built around a central question: What is the job a person is hiring a product to do? What is the job to be done? In the realm of software, the JTBD could be timely communication, making data available to those who need it, or reducing friction within transactions, to name only a few. 

But pinpointing the real job that a product is hired to do can be elusive, and asking the wrong questions is a fast way to arrive at a wrong conclusion. McDonald's erroneously thought the job to be done was improving their milkshakes. How can you prevent a similar mistake in your organization?

![McDonald's milkshake in car cupholder](/uploads/mcdonalds-milkshake.jpg)

## Understanding Customer Needs: Decoding the Milkshake Mystery

When McDonalds hired Christensen to sort out their milkshake mystery, his team started without any assumptions. They stood in a McDonald’s restaurant for 18 hours, taking careful notes about every customer who bought a milkshake. They wrote down the time, what the customer was wearing, who they were with, whether they dined in or ordered take-out, and what else they bought. Essentially every detail was recorded. 

Soon, patterns began to emerge. Over half the milkshake sales were made before 8:30am. The customer was alone. They didn’t buy anything else, and they took their milkshake to their car and drove away. 

The next day, Christensen’s team went back and began asking the morning buyers why they were buying milkshakes. What job did the milkshake do for them? Turns out, these customers had one thing in common: a long, boring commute. They needed something to interact with as they drove and wanted to feel full until their first break. Other snacks were consumed too quickly or caused a mess. On the other hand, the milkshake lasted for the whole trip and fit right in the cupholder. It accomplished the job they wanted done better than other options. 

Who could have predicted that McDonalds wasn’t competing with the chocolatiness of Burger King milkshakes or the viscosity of Wendy’s Frostys, but were instead competing with the convenience of bananas and the satisfaction of snickers bars? 

## Why Demographic Data Isn’t Enough: Deciphering Customer Behavior

This brings to attention an important point: demographic data alone cannot accurately determine a customer’s intent. A person’s needs drive their behavior, even within structured environments. 

For example, if the database your organization uses is old and difficult to navigate, people may resort to using post-it notes to store information. The JTBD for them is, “have the information I need at hand for when I need it.” 

If a post-it note does that job better than your company’s software, it’s time to make a change.

## Identifying User Intent for Better Product Development

Identifying the intent of your users is the first step towards building a better product, and that starts with empathy. Whether you’re a CEO, a manager, or a UX designer, if you want to be effective at your job, you need to identify their job. You have to discover what need, desire, or objective they hope to satisfy. 

Far too often, businesses will rush this fundamental research phase and dive right into applied research, the way McDonald’s did. They will identify and propose a problem statement, but without proper fundamental research the problem statement is filled with assumptions, and applied research (the expensive stuff) heads toward a likely dead-end road.

![A graphic of the "JTDB" acronym: Jobs To Be Done.](/uploads/mcdonaldsmilkshape-jtbd.jpg)

## Crafting the Right Problem Statements for Outcome-Driven Solutions

A team might form a problem statement such as:

> *There is no drop-down option to indicate the status of a task.*

This seems straightforward, but what is the real JTBD here? Is it to label tasks with their status? Or is it to move tasks forward to the next stage? A better problem statement could be:

> *We need an efficient way to communicate to the next person in our workflow that a task is ready for them.* 

The second problem statement is open to an array of possible solutions, whereas the first is extremely limited. 

Imagine working off of the first problem statement, spending the resources that it takes to develop and integrate a new feature into the system, only to discover that while a dropdown is convenient for the person finishing the initial phase, the next person in the workflow must login to a system that they don’t actually use just to see the status of a task. This is not a particularly efficient solution, and probably did nothing to address the actual JTBD, which is effective communication. 

To be truly outcome-driven, it is important to check for assumptions in your problem statements before talking to your stakeholders. They are eager to share their stories of pain and success, but what they actually tell you will depend entirely on how they are prompted. Forming robust problem statements will allow you to test solutions that address their actual needs and contribute to improvement across company systems. 

## Helping You Achieve Your Goals

Jobs that need to be done encompass everything from large organizational goals down to specific smaller tasks, with many other JTBDs in between. 

In light of those insights, at The Smyth Group, we pride ourselves on avoiding assumptions by asking the right questions. We build tools to help clients make achievements on the way to accomplishing their goals. We can help you assess the problem areas in your system, identify the JTBD, and develop a custom software solution for your business. 

If you would like to learn more about our process and how we can help, please contact us for a free consultation.

A McDonalds sign lit up early in the morning hours.

Understanding Jobs To Be Done along with customer needs, behavior, and intent will refine your software. 

Why a McDonalds Milkshake Story Should Reshape Your Software

Why a McDonalds Milkshake Story Should Reshape Your Custom Software

In 1940, an $11 million dollar bridge over the Puget River in Tacoma, Washington, buckled and twisted in 40mph winds before snapping and collapsing only 4 months after it was opened for public use. Its construction was supposed to endure strong winds, but it collapsed due to a fundamental engineering oversight.  “Galloping Gertie,” as she is known, became a famous example of the risks involved in pushing forward with a design that may save costs but has not been fully tested. 

Today, making good software is somewhat like constructing a strong bridge or building. If you build along the lines of Galloping Gertie without understanding the implications of untested designs, the building will not last. 

When it comes to software, businesses are often more concerned with meeting deadlines than building a stable, future-proof product. Launching versions of your software into production sooner than your technical team is comfortable with could result in costly retrofits and years of usability being shaved off down the road. 

So what does it take to keep your software secure, maintainable, and flexible over the long term? Let’s consider nine common strategies that you and your technical team should be aligned on to get the best possible value for your investment.

## 1.  Accurately Defining Business Requirements for Software Development

A good way to fail is by making the wrong product for your business. This seems intuitive, but software (even a simple system) is very complicated, and it needs to serve multiple stakeholders at a company. It is all too common for a high-level executive to request software with features that aren’t actually useful to the mid-level managers and end users. So, making software becomes an exercise in communication. 

The first step is to accurately describe the right product for all the business stakeholders. Often this can be done with a few well-timed conversations and emails. 

The next step is to describe the right product to the development team. You wouldn’t expect a construction crew to construct a building from an artist’s sketch. The crew would need highly detailed blueprints. But in the world of software, many businesses provide only a rough sketch to the development team, perhaps a powerpoint and some wireframes. This is a recipe for confusing, frustrating, unnecessary software. Programmers need precise, thoughtfully defined requirements with clear examples of what you are looking for.\[1]

## 2. Enhancing the Developer Experience 

We’ve all heard of user experience and why considering it is important. Developers are a subset of your users—they’re simply working under the hood. They need quality tools and methods that work well in order to yield faster, more stable results. (Help me help you.) 

This includes a robust development mode for testing the software before deployment, a well-thought-out strategy to avoid “squirreling” (more on this later), and positive morale. 

If the developer experience is pleasant, your software will be made faster, and there will be more interest in creating quality versions of that software. Changes to the software can be made more efficiently, and new developers can be onboarded very quickly. 

Giving your developers tools and processes that improve their experience will streamline the entire process from beginning to end. 

## 3. Avoid Task Switching or Context Switching 

Extensive research shows that frequent task switching—at times referred to as squirreling—is detrimental to our productivity, increases the risk of error, and demands a high cognitive load. 

Frequently switching gears midstream will tank the velocity of any team, but this is especially true for programmers. When writing code, they can be working on a train of thought that spans several days. When this is interrupted with a request to make something else, it leaves loose ends in the code base that have to be finished later. A piece of code that was 8 hours away from completion may now be 24 hours away from completion when it is revisited if the original train of thought is lost or interrupted. 

It is a red flag if your requests for changes encounter resistance from your development team. Usually this is a sign of too many tasks in process and too few completed (which means the code has been deployed and in the hands of users). 

Having a clear product vision will prevent the interruption of a current workflow with a new/different/side workflow. \[2]

## 4. Implementing Infrastructure as Code 

Your staging, quality assurance, and production environments should all be identical. The only way to keep your servers truly identical is by writing a script that can be run by your cloud provider to automatically reprovision your server. This is called “infrastructure as code,” and it is manageable, scalable, and predictable. 

The parameters and settings of your system are written and provided to any platform as a complete package, not requiring any set up or manual adjustment. This methodology is like a series of rubber stamps that can be used over and over again, yielding the same results every time. This avoids the dreaded “pet” server that requires special handling and the manual expertise of a specific technician. It avoids the “snowflake” server that is unique and delicate, impossible to replicate later if your business needs to grow. 

Using infrastructure as code turns your servers into cattle rather than pets. They are all treated the same and offer consistency. Instead of manually setting up specific servers (treating them like pets), you can write a script and run it whenever you need to spin cloud services up or down (treating them like cattle). You can scale up in seconds, and if you find that you no longer require all the resources you formerly did, it takes only moments to scale down. 

All the most popular cloud service providers—Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP), and others—support all the automation tools necessary to provision your infrastructure as code. The flexibility offered by infrastructure as code is key to getting the best ROI out of your system.

## 5. Emphasizing Peer Code Review

Every newly constructed building goes through many inspection processes, not because the workers are unqualified or untrustworthy, but because there is always something to gain from the insight of other experts. 

Having new code reviewed by senior level developers before it’s checked into the master code repository will not only eliminate problems down the line but will create a more consistent code base and contribute to the training and sharing of knowledge with junior level developers. All of your developers will have a better understanding of the code as a whole, avoiding single experts in small areas. 

The reality is that programmers can and do transition in and out of companies. If one was working in a non-peer-reviewed vacuum and transitioned to another job, this could leave a question mark in the code that would require time and resources to figure out and integrate with the whole. 

Knowledge sharing makes for a healthy, productive company culture, and that in turn will produce a better product. 

![Two developers reviewing code side-by-side](/uploads/software15years-peercodereview.jpg)

## 6. Investing in Delivery Automation for Efficient Deployments

Newly launched software, regular updates, and new features all travel along an automated pipeline to the end user. 

We are all familiar with software updates to our smartphones. These updates are downloaded and installed automatically. Imagine, instead, if these updates were emailed to you from an employee at Apple or Google. Or if you had to make an appointment for a technician to come to your house and update your phone. 

This sounds ludicrous, but many companies struggle with the fragile process of delivering software manually rather than having it automatically deployed. Delivery automation allows developers to roll out needed code changes quickly and efficiently. 

It’s also very important that these code releases not be tied to feature releases. This is possible by building Feature Flags into your system, which will allow you to turn certain functionality on or off (or versions of each functionality) without deploying new code. This allows you to test new features in production and immediately rollback or kill any feature without deploying new code. 

Small patches may need to go out immediately, but if they are tied to an unfinished feature, you will have two bad options: delay an important update, or release a feature that may break everything. Automating the delivery can also allow new features to be released gradually, perhaps to a small number of users within the organization, before releasing them to everyone. 

Keeping code releases separate from feature releases and automating both create stability while simultaneously speeding up the responsiveness of your development team.

## 7. Adopting Test Automation for QA

Testing your code before every deployment mitigates risk and increases quality control, so it’s a matter of course that you would want to do so. Rather than hiring people to simply test it manually, smaller pieces of software can be run alongside the main software, testing as it is built and deployed automatically. 

Imagine if the plumber working on your house had little robots following him around, jumping down the pipes and checking for leaks as he worked the whole time. Not only would he be alerted to issues long before they could bother you, but he would also be able to move more quickly through his work with greater confidence. 

Automated tests being run in a pipeline allow quality metrics in the code to be visible to your entire team, and quality control becomes part of your assembly line. Having rock solid testing requires building a strategy with your development team from the beginning. 

Healthy code is easy to test. But if the tests seem fragile, if they break all the time or are often ignored, this is a red flag that the tests are not high value and are not testing the right things. The better the code, the easier it is to test. 

Having test automation keeps the entire team alert and accountable for writing good healthy code—not just the developers.

## 8. Ensuring Regular Maintenance and Upgrades

Software is **always** changing. All programs ride on the shoulders of other programs, making it possible to build incredibly sophisticated systems. Parts within the system are constantly being updated, defended against malware, and improved. 

To keep your software running properly, it has to keep up with the larger ecosystem. It has to be maintained. 

If you made the investment of building a house, you wouldn’t later refuse to clean the gutters or treat for termites simply because the house was finished. In the same way that treating your house for termites is cheaper than having your woodwork replaced, keeping your software current will defray costs down the road. The cost of staying current is lower than the cost of updating infrequently after several generations. 

If you hear that the updates are too costly or take too much time, this is a red flag. This is tech debt that needs to be paid off. 

All code needs to be patched and kept up to date. Operating systems need to be kept up to date. Delivery platforms such as the App Store have guidelines that require consistent updating to the degree that they will remove an app from the store if it is not kept up to date. 

Proactively maintaining your software is safer and more cost efficient for you and your users.

## 9. Incorporating Built-in Security Measures

You build trust with your users. If you violate that trust, you may have legal repercussions, loss of brand trust, and financial implications. Since security is such a high priority, it should be built directly into your software as part of the development process. 

Make sure your developers are familiar with secure coding practices. Have the code evaluated from a security standpoint. Building in security from the ground up will make your software stronger and therefore last longer. 

Imagine you finished constructing your home, only to realize that the electrical wires pose a fire hazard. To be safe, you would need to rip them out and start over, which would obviously be extremely costly. It is always better to design with security in mind from the very beginning.

## Creating Software that Stands the Test of Time

Each of these topics easily merits an entire article of its own, but if you can talk about them with some fluency to your team, your product will end up being relevant and useful. Being on the lookout for traits and habits that could harm or hamper your system as it develops over the years will keep it robust and stable. And finally, giving your developers the tools they need and the time to follow these healthy practices will keep your system fresh and innovative. 

While these approaches require time, commitment, and effort, the result will be software that can easily last for fifteen years and will yield a significant return on your investment.

If you’re committed to building enduring software, we’d love to hear from you. Schedule a consultation to discuss how our strategic approach can ensure that your software doesn’t just launch—it thrives for years to come.

**\[1]**  BDD or Behavior Driven Development is an approach to software development that encourages a strong focus on the behavior of the system as perceived by its users. For more on this, see [Domain Driven Design with BDD](https://www.youtube.com/watch?v=Ju50D11EIoE) by Dave Farley

**\[2]**  For more on developing a strategy for starting less and completing more see "Why Limit WIP? We're Drowning in Work" by Jim Benson [Why Limit WIP: We are Drowning in Work (MemeMachine Series): Benson, Jim: 9780989081238: Amazon.com](https://www.amazon.com/Why-Limit-WIP-Drowning-MemeMachine/dp/0989081230)

The Tacoma Narrows Bridge Collapse in Washington State

How do you create custom software that stands the test of time? Learn about 9 key strategies that work.

How to Make Your Software Last for 15 Years

How to Make Your Software Last 15 Years

You’ve done it—you’ve struck digital gold! Your SaaS Platform is gaining popularity and your user base is happy and growing! As much as you’d love to sit back and watch your bank account grow, you’d like your users to stay happy. So now you shift your focus to being able to handle the increased load on your system without any decrease in performance.

More users means more requests to servers, more data in databases, more feature requests, and so on. Can your infrastructure handle this increased demand? The decisions you’ve already made will largely determine how “scalable” your system is, but can you do more? With some planning, your platform can be ready to handle these increased demands.

Let’s consider how to handle large numbers of users, what tools are available to you, and what strategies can help you as your platform continues to grow.

## Leveraging AWS for Handling Large User Volume

There are several options available to handle many users accessing your platform at once. Here are three options:

### Using AWS Elastic Load Balancer (ELB) to Manage Traffic

You might think that in order to handle more users, you just need to keep beefing up the server that hosts your app. That’s one way to do it, but it gets very expensive and there is eventually a limit to how much RAM and CPU power you can give a server. 

AWS Elastic Load Balancer (ELB) scales your app by distributing incoming traffic (your users) to your application across multiple servers, containers, IP addresses and even across different regions! This means that no single server is being overworked when handling your traffic. The “load” is balanced across several copies of your application running simultaneously, which we call instances of your application.

### Exploiting AWS Auto Scaling to Manage Resources

Of course, you can manually create as many instances of your application as you anticipate needing. But what if you create too many (wasted money) or too few (frustrated users)? By using AWS Auto Scaling, your application will scale automatically in response to your traffic. 

So if your application sees major spikes in traffic at only a few times of the day, that’s fine. More instances of your application will be created as your traffic grows. Auto Scaling will then save you money by shutting down those instances when traffic decreases. 

### Leveraging AWS Elastic Kubernetes Service (EKS) for Containerized Applications

What if your application infrastructure is based on Docker containers? Not a problem! Package your application and its dependencies into a container, manage instances of those containers with Kubernetes (via EKS), and watch how your applications handle increased demand with ease.\
\
AWS Elastic Kubernetes Service can scale your application instances as needed, so you only pay for what you use. As part of the AWS ecosystem, EKS is compatible with other AWS services, including the previously-mentioned ELB–where traffic is balanced across several container instances as needed.

Enjoy the benefits of a container-based infrastructure (like a consistent testing and production environment) **plus** the scalability of Kubernetes by using AWS EKS.

![An illustration of a girl collapsing under a heavy load of abstract shapes. The circle looks particularly weighty.](/uploads/scalesaas-heavyload-web.jpg)

## Performing Load Testing to Stress Test Your Application

How can you know whether your application will handle heavy loads? Offer a coupon and hope users flock to your app? That’s one way—but will the users come? If they do come, will the disruption and downtime of your system leave users with a bad impression that will keep them from coming back to your application?

Thankfully, your application can be “load tested”; that is, you can place your application under an artificial stress test to discover its breaking point(s). Usually this involves creating and simulating thousands of users interacting with your application at a constant rate. This helps determine your application’s maximum capacity and can identify any bottlenecks that play a significant role in any degradation.

By load testing and addressing the results of your tests, you can ensure that when your application is under a heavy load:

* Your system stays performant and responsive so that user experience does not suffer
* Your infrastructure resources (CPU, memory, disk I/O, network I/O, etc) are better utilized
* You have confidence in your infrastructure’s ability to handle whatever is thrown at it

### Efficient Load Testing Tools

There are several tools you can use, like Apache JMeter and k6, to Load Test your application. AWS offers their “Distributed Load Testing on AWS” solution to support the use of custom JMeter scripts, while automating the entire test and results within the AWS ecosystem: AWS API Gateway to start the test, S3 & DynamoDB to store test details and run scenarios, Cloudwatch to log the test results, and so on.

Once testing is done, analyzing and interpreting the logged results in Cloudwatch will help pinpoint where your application needs optimization to better handle future stress on your system.

## Ensuring Stability with Automated Testing and Deployments

You want to be confident that your scalable application is resilient, stable, and reliable. It’s a good practice to have a QA team test your product, but in addition to that, a suite of automated tests which run on either a schedule or as a result of merging git branches, for example, will prove to be one of your best tools in maintaining the stability of your application.

A common type of test is a **unit test**; these are often written by developers to test that your application responds appropriately in a given scenario. The benefit of these unit tests is that they are easy to create and can be run automatically each time the codebase is updated. This ensures that your application stays stable with each change to the codebase.

And as your confidence in the codebase is strengthened, you are comfortable in releasing updates to your product more often—to the delight of your users.

Even as your product grows and the number of features and edge-cases grow, automated tests allow you to test more features more thoroughly very quickly.

### Understanding Continuous Integration/Continuous Delivery (CI/CD)

You may have come across these terms often. What do they mean and how can they help your product?

**Continuous Integration (CI)** is the practice where developers merge their code changes into a shared repository, usually multiple times a day. When this code is merged, automated tests can be run in order to discover any bugs or issues in the code. The goal is to provide immediate feedback about the state and quality of the application as soon as possible. The result of this automated “build” of the code is typically either “pass” or “fail”.

**Continuous Delivery (CD)** builds on the concept of CI by ensuring that the previously built code, if it did not fail, can now be “delivered” or “released” to customers. Oftentimes, even the release of this code into the testing or production environment can be automated.

### Streamlining Infrastructure Management with AWS CloudFormation

**CloudFormation** is a service that allows you to define in code all of the infrastructure that makes up your application. It’s like a blueprint of all the components that make up your application, allowing your CI/CD pipeline to automatically create/update your application (and all its dependencies & 3rd party resources) according to that blueprint. 

Like using the same blueprint to build many houses, you can very easily create as many copies of your application as you need, whether to scale up to meet high demands in production, to perform load testing, or if you need to create a new environment to test a new feature. AWS even offers many templates to help you get started with infrastructure that meets best practices for security and availability.

## Leveraging AWS Technologies for Enhanced Scalability

Up to this point, you’ve likely noticed that AWS seems to have a tool or a service for basically every aspect of making your application scalable. We haven’t even scratched the surface of all that AWS offers in this regard. But here are a few more services to consider for your SaaS product.

### Monitor and Optimize with AWS CloudWatch & AWS Athena

As you know, you can learn a lot about the health of your application by reading through log files, collecting metrics, and capturing events. But trying to sift through all that data using **Control + F** in a Text Editor can be overwhelming; and you can miss out on some automation.

**CloudWatch** can help you monitor the operational health of your application. CloudWatch collects and processes raw data from your AWS services–even allowing you to set alarms to notify you when certain metrics or thresholds are met. It also offers insights to help optimize your applications!

**Athena** helps you analyze large amounts of data files that you may have stored in an S3 bucket. This allows the use of standard SQL to perform ad-hoc queries to analyze data files in a variety of formats, including CSV, JSON, and much more.

### Enhance User Experience with Multi-Region Deployments in AWS

Deploying your application in regions that are geographically closer to your users can not only improve network latency and user experience, but your application will then benefit from redundancy and will be inherently scalable since your traffic is distributed across these multi-region instances.

AWS offers many services to support multi-region deployments of your application. Whether it’s **Route 53** to direct your traffic to the closest region, **CloudFront** CDN to cache your content at edge locations around the world, **Lambda** functions deployed across multiple regions, **RDS** databases to store your data in multiple regions, or other services, there are likely several tools to suit your needs and to support your growing application.

![A digital view of earth from above, with connections jumping across continents, regions, and states. ](/uploads/scalesaas-embracegrowth-multiregion.jpg)

### Software Offerings for Automated deployments

Another way to simplify the path between code development and scalable, automated code releases is by hosting your source code in AWS CodeCommit. This allows you to easily connect to AWS’ CI/CD solutions: CodeBuild, CodeDeploy, and CodePipeline. The big benefit of using these tools is apparent when most of your architecture and infrastructure is already within the AWS ecosystem: they offer out-of-the-box support for provisioning instances, balancing loads, deploying your various components, or managing any other tasks your application requires.

## Strengthening Technical Staffing for SaaS Scalability

We know you have a talented team of developers and project managers who have helped your product grow into the successful platform it is today. Given enough time, they can probably figure out how to leverage these AWS services to get your platform to the next level in terms of scalability. But scalability is still a complex goal with a steep learning curve, made up of many different components and strategies.

By working with an experienced team of DevOps engineers and Site Reliability Engineers, you can feel secure knowing that you will not have to deal with unexpected outages & system degradation while they work to make your application robust and scalable. You’ll benefit from decades of best-practices and industry-standards by working with experts in the field.

At The Smyth Group, we have an experienced team of DevOps and Site Reliability Engineers ready to help your platform keep up with increased demand. We’ve helped many platforms scale and maintain their platforms, while balancing cost-effectiveness and user experience.

If you think your SaaS has room for growth and needs some help getting to that next level, get in touch with us. Whether you need some guidance to decide which AWS services are right for your organization, you need a team of experts to do the work for you, or you need something in between, we can make it happen. Your customers might just thank you for it.

A funky illustration of a group of young people on their phones. 

As your user base grows, will your SaaS still deliver under pressure? See tools and strategies to scale.

All Posts / Software Strategy

Alexander the Great’s Approach to Software Development

Software Strategy

Why a McDonalds Milkshake Story Should Reshape Your Custom Software

Software Strategy

How to Make Your Software Last 15 Years

Software Strategy

Scaling Your SaaS Platform to Embrace Growth

Software Strategy