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

Our Development Coordinator, Paul, speaking to an audience about a topic.

From our minds to yours—gain from our collective insights on software, business, strategy, design, and beyond.

insights.

Peter Drucker’s famous quote “Culture eats strategy for breakfast”—essentially meaning that a company’s culture impacts its bottom line more than its business strategy does—has been repeatedly borne out in both research and real-world environments. A close cousin of this concept, Conway’s Law, can be applied more specifically to custom software development, and may be the reason why you don’t have the software that you need. So what is Conway’s Law?

In 1967, computer scientist Melvin Conway made this observation: “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.” \[1] 

He illustrated this point with the example of two teams, each tasked with producing the same compiler. The team of 5 people produced a 5-phase compiler, and the team of 3 people produced a 3-phase compiler. The way the teams were organized directly affected the way the technology was structured.

Conway’s Law gained so much traction that it was later studied by Harvard Business School and renamed the “Mirroring Hypothesis.” The results were published in a paper entitled [“Exploring the Duality between Product and Organizational Architectures: A Test of the “Mirroring” Hypothesis](https://www.hbs.edu/ris/Publication%20Files/08-039_1861e507-1dc1-4602-85b8-90d71559d85b.pdf).” Their finding: “We find strong evidence to support the mirroring hypothesis. In all of the pairs we examine, the product developed by the loosely-coupled organization is significantly more modular than the product from the tightly-coupled organization. We measure modularity by capturing the level of coupling between a product’s components. The magnitude of the differences is substantial—up to a factor of eight, in terms of the potential for a design change in one component to propagate to others.”

Loosely-coupled software architecture comes from a loosely-coupled organization. So different services that the organization depends on can be updated in production independently, on demand, without needing to wait on each other to deploy in a specific order. As the study shows, loosely-coupled architecture produces significantly more modular systems. Modular systems are easier to change and quicker to adapt to new demands than monolithic systems. 

Therefore, the modularity of a system is an excellent metric for describing the quality of a software system. The Harvard study notes that its findings “have significant managerial implications, in highlighting the impact of organizational design decisions on the technical structure of the artifacts that these organizations subsequently develop.” So, if you want better, more modular software, it’s time to examine the structure and culture of your organization.

How you manage teams, how you structure them, and how you encourage communication all contribute to an environment that you (consciously or unconsciously) have designed. The software that your organization can produce will mirror this design. Tight, formal hierarchies produce monolithic code bases that are much more difficult to maintain and change as time passes. So how do you make Conway’s Law work for you instead of against you? 

## Think about hierarchy. 

If the hierarchical structure of your organization separates developers from designers and operations and inhibits intimate communication between these disciplines, your software will suffer. 

Ask yourself the following: How do approvals happen? How does communication happen? Are team members collaborating only through change tracking systems and not talking to one another directly? Is there a strictly rigid multiphase review process for rolling out new changes to production? Is there a database person who must apply changes to the database schema separately before you can deploy new production code changes? Are groups separated to a degree that they do not collaborate or communicate well? 

If communication and collaboration are lacking, put people together, either physically or in an online group, and get them talking directly. Then when a new feature is delivered, all the needed code rolls out together. Think about the modes of communication you are structuring and strive for an inclusive playing field. 

## Think about team structure. 

Small (fewer than 20) teams are [better](https://hbr.org/2007/11/eight-ways-to-build-collaborative-teams). Cross-functional teams of 5-10 are ideal. Amazon famously has the “two-pizza rule”\[2]—if you can’t feed the team with two pizzas, it’s too big. 

But it’s not just numbers that matter. Diversity, safety, and independence are just as important. A monolithic organization has isolated teams for quality control, operations, and product development. Splitting these up into 3-4 cross-functional teams with representatives of each skill set and allowing them to work safely and independently will open the floodgates of innovation. 

Consider the example of a team with the following: 1 designer, 2 developers, 1 operations tech, 1 database tech, and 1 marketing specialist. Not only would this team have significantly reduced communication overhead, but studies show that members would be better able to keep project context in mind, respond to change, and make decisions quickly. \[3] 

## Think about communication and coordination. 

How does your team communicate? Is all the “talking” done in Jira tickets without any actual speaking? This will produce terrible software. 

Removing restrictions on communication in the organization allows for greater knowledge sharing and a freer flow of ideas. Use a mono repository so that teams can see and learn from each other’s code. Examine the effort required to coordinate. Do team members work in different time zones? Avoid a strict company hour policy. Give them the flexibility to work during hours when they can maximize their communication with one another. Remove unnecessary bottlenecks such as putting in a ticket to request deployment to production. Trust your people and allow them to act so they will have a greater sense of ownership and engagement with their work. 

![Small teams working together in an open office](/uploads/conwayslaw-teams.jpg)

These principles of communication and coordination are a major component of the DevOps mindset. This cultural movement for high velocity software delivery is based on the experiences of the people shipping the software and is designed to support and encourage the health of an organization.  For example, CI/CD pipelines improve software delivery and are extremely useful for rapidly shipping software and removing and reducing unnecessary coordination. 

DevOps is not one person or team; it is a way of thinking that serves all team members and sets the foundation for a loosely-coupled organization. This communication and coordination will then be mirrored in the software that is produced. 

## Foster a safe and respectful environment.

For any of the concepts we’ve discussed thus far to actually work, there is a crucial environmental factor that must be met. That factor is [psychological safety](https://www.ccl.org/articles/leading-effectively-articles/what-is-psychological-safety-at-work/). When the culture of an organization is characterized by trust and respect, the social structure will encourage free and open communication, resulting in a technical structure that is flexible and adaptable. 

Keep in mind that at a certain point, how we communicate is more important than what we communicate. A team that communicates with empathy doesn’t simply deliver information for information’s sake. Each member purposefully communicates with the goal of helping others make independent decisions. Being free to ask questions, disagree, express concerns, and point out flaws will enable your people to drive innovation more effectively. 

Don’t tolerate a jerk. If someone is undermining the psychological safety of the team via personal criticism, making people feel unsafe to express themselves, acting like they are the final word or smartest person in the room, then team members will not bring their whole selves to that room. You will have missed an opportunity to access the full strength of your team, and innovation will be stymied. 

So be human, show feelings, express yourself, and encourage others to do so as well. If your organization does not have psychological safety, you can’t create the communication patterns to make Conway’s Law work for you, and you can’t create the technical system that works for the organization.

![An angry man yelling at his coworker and gesturing towards the coworkers incompetence. ](/uploads/conwayslaw-jerk.jpg)

## Apply Conway’s Law.

When presented with new information on any topic, we have 3 choices: ignore, accept, or lean in. 

Ignoring Conway’s Law won’t prevent you from developing custom software. It will prevent you from developing good custom software that can adapt to changing environments. 

Accepting the real-world impact of Conway’s Law and ensuring your architecture doesn’t clash with developers’ communication patterns will notably improve the speed and innovation of your team. 

But leaning into Conway’s Law and taking control of your end product by effecting structural changes at the beginning is one of the most effective ways to transform the quality of software you can produce. 

So think about the structure and culture of your organization—it matters. Create small, cross-functional teams that have the power to do their jobs smoothly, without encountering unnecessary roadblocks. Make sure your people are psychologically safe and can bring the full power of their diversity and experience to the table. Embrace the mental shift of making room for more focus on cultural practices, not just technical practices. It’s all part of the same system. 

If your problems are cultural, you will never fix them by focusing on technical issues. Using Conway’s Law artfully requires flexibility and responsiveness to feedback. The benefits, however, will long outlast the initial growing pains, and you will have positioned yourself to continually produce the best possible software for your organization’s purposes. 

\[1]  <https://www.melconway.com/Home/Conways_Law.html> 

\[2] <https://www.amazon.com/DevOps-Handbook-World-Class-Reliability-Organizations/dp/1942788002> 

\[3] <https://martinfowler.com/articles/microservices.html#OrganizedAroundBusinessCapabilities>

Considering hierarchy, team structure, communication, and your environment can lead to better software.

Harnessing Conway’s Law to Create Better Custom Software

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.

Scaling Your SaaS Platform to Embrace Growth | TSG Article

Scaling Your SaaS Platform to Embrace Growth

A software development agency is a team of designers, developers, and project managers who work with clients to research, design, build, test, and deploy new custom software. 

After project completion, that client has a new software system—such as a web or mobile app, enterprise business application, or website—that *they own* and operate independently, which increases their value and helps them scale toward their strategic business goals.

But how can a company know when they should look externally to build custom software?

This article will outline the 5 ways to know when you need to hire a software development agency.

## 1. When Business Needs are Growing Too Fast to Handle

If your company’s demands are expanding faster than your in-house development team can keep up, a digital agency can build custom, scalable software to meet your business goals—shrinking the gap between your growing business demands and your system’s capacity to meet them.

Perhaps your company wants to add new employees and users without crashing or risking productivity, or you want to sell a service to new market segments around the world. You may have an expanding backlog of requests, expanding customer demands, and a developing pattern of unmet deadlines—suggesting your company is growing faster than your system has the means to support. Meanwhile, your in-house team is overwhelmed and overworked. 

Perhaps you only need temporary developer support and don’t have time to vet a qualified new team member. 

In these cases, an agency can plug into your mission and routines, working with your existing team to build a usable, scalable, performative system to move you toward your business goals.

![Woman CEO busily handling multiple tasks, several people asking for her input at once. ](/uploads/growingyourbusiness-toofasttohandle.jpg)

Software developers and designers in digital agencies like ours collaborate in-person or remotely with clients and stakeholders at each step of the development process, beginning by meeting with stakeholders to understand the business goals for their system. Next, we interview real-world users to learn how things have been done up to that point. Finally, we design the new program’s interface and architecture along with a plan and timeline to implement that system.

Throughout the development process, automated release updates keep you informed about real-time development progress, so you can monitor the project and make decisions along the way.

## 2. To Add Something New

If your development team doesn’t have the expertise to build the system your business needs, a digital agency accomplishes two major tasks at once—*building* the system while *cross-training* your team to use, maintain, and build projects like it in the future.

For example, some of our clients already have a web development team, APIs, and a database—but they don’t have the expertise to create a *mobile* app. During the weeks and months of the project, our developers work closely with the client's team. Sometimes the client's team develops the API and our team develops the mobile application that it needs. Sometimes we develop the CI/CD integration pipeline and train the client's team on how to use it. 

## 3. When You Need Something Better

When you need something *better*—a better-functioning team, more efficient workflows and production systems, or new ideas for your company’s software—a development agency provides a fresh perspective to improve what you already have.

### Better Ideas

Many teams go years—or even decades—maintaining outdated systems. This can happen for a variety of reasons: years of not asking good questions to end users, too much time and energy focused on maintaining existing systems, the habit of frequently starting new projects without fully finishing and implementing any of them, or a siloed team that struggles to organize for innovation.

Regardless of the precise reason, companies reach a point where they realize they *need new system ideas.*

A software development agency’s team remains up to date on the latest technological platforms, languages, design patterns, and cloud services—which helps the agency’s strategic designers and engineers identify waste, inefficiencies, and antipatterns during the process of meeting with the client’s departments and teams. 

Identifying these issues helps the development agency design a new or updated system that ameliorates them.

![Company meeting where a man is suggesting an idea while his colleagues listen intently.](/uploads/growingyourbusiness-betterideas.jpg)

For example, our agency worked with a large auto manufacturer whose sales-team training materials were spread across multiple websites and apps. This disorganized system forced new employees to create multiple login accounts and track emails and deadlines from multiple sources—which led to confused employees and high turnover.

We shadowed and conducted interviews with the client’s staff at headquarters as well as salespeople at the dealerships, asking questions to understand how sales employees got trained and where pain points existed. With this holistic view of their internal processes, our team offered new suggestions, perspectives, and resource ideas about how the company could unify training resources and design a smoother new-employee process.

### Better Team

The technological landscape develops quickly, and it’s easy for teams to fall into outdated practices without realizing it.

When a company has retained the same internal team for years, there comes a time when—despite success—leadership decides they want to take steps forward and improve their team’s technological skills in some way.

Digital agencies can mentor internal client teams by putting on workshops, auditing infrastructure or security, or performing code reviews or strategic product design sessions. These processes demonstrate new competencies, technologies, and tools that upgrade the client team’s toolbox and know-how.

For example, some of our clients are eCommerce sites or municipal agencies missing out on critical modern methods: CI/CD pipelines, code quality analysis, continuous integrations, continuous testing frameworks, or automated deployment tools that ensure frequent deployment with the goal of fewer errors. 

A lack of knowledge about how to utilize these principles, processes, and tools holds companies back from rolling out new software or improving the software they already have, leading to missed opportunities for business acceleration and better service.

We create these clients’ pipelines for them, then collaborate and train their staff over months how to use the pipelines and carry out automated testing. After deployment and data migration, clients have more skilled internal teams and a system that minimizes manual testing, saving time and reducing errors.

### Better Systems

In their early days, growth-stage companies often rush to create software systems without a clear vision of the company’s long-term service goals. While this allows quick development and service rollout, over time it can accumulate technical debt—issues like poorly written code and the inability to scale to meet ever-expanding customer demands. 

These rushed and sloppy processes lead to an overloaded system, with frequent downtime or software outages that ruin customer experience and hinder company operations. Often, a company’s outdated software simply breaks down as it fails to support new business needs, leading to massively downgraded functionality.

A digital agency can clear this technical debt and update a client’s software—with services like code remediation, breaking service features into chunks for smoother integration, and managing the software backlog—establishing agile principles so the client can move forward smoothly.

In the event of a software hack, these remediation processes play a critical role in helping your company recover quickly.

## 4. To Become More Profitable

Many custom software clients are growth-stage companies or startups seeking to get acquired for the highest possible valuation.

As a company approaches the opportunity for acquisition, its valuation may be limited by the fact that it is running on inefficient software, relying on third-party systems, or carrying tech debt.

**The following metrics play a critical role in a software asset’s valuation:**

* Ownership of intellectual property (IP)
* Source code
* Ease-of-use
* Efficiency
* Ease of updates and if the language is up to date
* Cost of replacement
* Adaptability, scalability, and integration capabilities 
* Costs involved with running systems

In other words, a company using its *own system and technology*—that runs smoothly and efficiently with up-to-date code—will earn a higher valuation in the eyes of companies seeking to acquire it.

At the same time, a company may hesitate to hire an external party to create custom IP and software because they fear that after deployment, their in-house team may lack the expertise to operate the new system or tool, forcing them to rely on the digital agency in the future and reducing their standalone valuation.

This is why it’s so important to work with a *collaborative* software development agency that will train your in-house team during the project, helping you transition to independent maintenance and operation. Self-sustainment is a huge positive in the eyes of companies seeking to acquire your company, who want to know you can operate your own technology moving forward.

## 5. To Save Costs

Upfront expenses often present a major concern for companies considering a software development agency. 

These companies may continue using third-party software that requires monthly licenses and subscriptions. As these subscriptions begin to pile up, companies begin to think about *buying*—instead of renting—their software.

Over a multi-year timeframe, the upfront investment in building custom software saves clients a lot of money, increasing ROI in multiple ways.

Ways that custom software generates a favorable long-term ROI:

### Fewer subscriptions and licenses

Running and maintaining your own software–rather than paying a third party for their solution–saves you thousands of dollars each month in subscription and licensing costs.

### Reduced IT, development, and maintenance staff

An inefficient or outdated system can lead to outages and downtime, plus the extra time required for setup and training. This taxes your IT and development teams and may force you to hire extra employees compared to an easier-maintenance option.

### Improved customer experience

Investing in well-running, fast, user-friendly software improves your customers’ experience, making them more likely to remain long-term customers.

### Reduced training costs

Outdated and clunky software systems can be difficult for new employees to learn. Many frustrated new employees will quickly seek employment elsewhere, meaning a high turnover rate and extra training expenses for companies that don’t invest in new, user-friendly systems.

### Easier scaling

Outdated and inefficient software can prevent your company from expanding your customer base, costing business opportunities and returns. New custom software can generate massive ROI by helping you scale towards business goals faster, adding new team members without racking up subscription fees.

### Error reduction

Software development agencies build a pipeline for the ongoing automated testing and integration of new code. Without streamlined testing and deployment automation, the risk of future error increases exponentially. This could result in costly security issues, future bugs that require staff resources to fix, and downtime.

To learn more about how a digital agency can help your company scale, take on new challenges, improve your systems, build new services and tools, and save costs—get in touch with us.

A growing business needs a big building—this is a big building.

Struggling to meet your business's tech demands? Discover when a software development agency could help.

When In-House Isn't Enough—5 Signs You Need a Software Agency

When In-House Isn't Enough: 5 Signs You Need a Software Agency

As a business owner seeking to reach as many users as possible with a custom mobile app, or as a developer responsible for its creation, you know that the ideal app will need to run seamlessly on both Android and iOS platforms. In the past, the only way to do this well was by writing the app twice—once for Android in Java, and once for iOS in Objective-C or Swift. 

Since duplicating efforts is time-consuming and costly, this led business owners and developers toward a common goal: Build an app just once, and have it work effortlessly across multiple platforms. Obviously, this would significantly cut costs by reducing the amount of code that needs to be written, tested, and maintained. 

So what methods have been developed to fill this need, and are they any good? This article explores cross-platform development strategies, with a particular focus on Flutter, the recent game-changer in the field. 

## Tracing the Roots of Cross-Platform Development

Java was one of the first languages to offer the promise “write once, run everywhere.” It was extremely popular and held up in many ways. Unfortunately, it never fully delivered user interfaces that looked like native apps.

Soon, other attempts at cross-platform applications were made using web technologies—with mixed results. Initially these tended to be slow, glitchy, and resource-hungry. As time went on, many cross-platform solutions had a virtual machine running in the background, effectively running an app to run your app. Naturally, performance took a big hit in these cases. Some apps used web technologies, which had the appeal of enabling web developers to become mobile developers, but these apps rarely lived up to users’ expectations. The quality just wasn’t there.

In the face of these challenges, it has become something of a best practice to “always go native” when developing an app. The extra cost is simply the price of quality. In some cases, this is still true. But in 2017, a new player entered the field—Flutter, an open source framework created by Google for cross-platform app development—and the game has never been the same. 

Recent solutions for cross-platform development have centered on the practice of translating a command into a native component. 

Tools like Xamarin and React Native allow developers to define a UI that runs on Android and iOS by translating to the underlying native UI layer. However, this means that the developer is restricted by the pre-existing control set defined by either UI system. These constraints, for instance, can result in a button's size and behavior varying slightly between the two platforms, leading to subtle differences in the look and feel on different devices. 

This method of development can be likened to the difference between an original painting and a collage. In an original painting you have the freedom to make any shapes or colors you like, but if you are assembling an image with cut pieces of paper, you will be limited to the shapes and colors as they already appear on the pieces. 

![A cut-paper collage of the Mona Lisa](https://lh3.googleusercontent.com/e3YZvaBeGtklz_OVH8u5WEBef7yNJH3XAVc_F2zsHsPME8qhIji421QPBKc32obN92powDuKWUYGHcPKCxVpiBrIxZYA0rhSf37UpmcPl4JK0X5wKDlbmAx-PRHOlAyt3izspw-fT26ttqbT0Nt80j0 "A cut-paper collage of the Mona Lisa")

## Unpacking the Benefits of Flutter 

Flutter, on the other hand, treats all platforms like blank canvases, drawing every single pixel as defined by the developer. It’s like an original painting, unlimited by predetermined parameters. This results in the same UI on iOS and Android, losing nothing in translation. 

 This sounds fantastic in theory, but how well does Flutter perform in real-world professional use? Here at TSG, we have used Flutter on a number of production customer projects. These apps are now successfully in the hands of the end users. 

Here’s why we like Flutter:

### Reliability: Flutter Actually Works! 

We encountered no major issues with Flutter itself, its stability, or its performance. Features typically work as described—a rare delight in the world of programming—and the documentation for getting up and running was excellent.

### Enhanced Developer Experience

Our team was very impressed with Flutter’s hot reloading right out of the box. Some even prefer it to the Swift previews found in native iOS development. The unit and UI testing out of the box are also excellent. We were especially impressed that UI tests can be run without starting up a device or a simulator. This pre-configured, ready-to-use functionality not only proved efficient but also significantly expedited our production process, leading to notable cost savings. If tests take a long time to write or run, a team will be reluctant to use them, and they can decay over time. However, in our case, the experience was so enjoyable that one of our developers went so far as to say, “It’s fun to write unit tests in Flutter!”

Another benefit is the robust first party support for Integrated Development Environments (IDEs), with Visual Studio Code (VS Code) standing out. The available extensions make it genuinely easy to work directly in your editor.

Something that might initially scare people away from Flutter is that it uses the somewhat esoteric Dart language, but its similarity to modern languages (especially Typescript) makes it accessible and easy to learn. Our team had no complaints about using Dart. We were also impressed with the debugging functionality. Setting breakpoints in VS Code at an exact line worked well and quickly. To top everything off, the documentation is excellent. Google has clearly invested heavily in Flutter and Dart, from YouTube demonstrations to interactive written documentation. If GitHub is more your speed, the open-source nature of Flutter makes it possible to dig into the source code and find exactly what you’re looking for.

### You Can Still “Go Native” 

For those moments when you need deeper integration with the Operating System (OS), Flutter provides a seamless API. You can even selectively introduce Flutter into an existing app. For example, you could write just a sign-up screen in Flutter and integrate it into your Swift app. Conversely, it’s also possible to use iOS technology in your Flutter app. 

### Simple and Intuitive UI and UX Design

As with any system, there is a learning curve involved, but it’s not overly complicated. Widgets in Flutter are the basic building blocks of the app's UI. They can be as simple as a button or as complex as a fully functional screen. Widgets can have child widgets, forming a hierarchical structure similar to a tree. This hierarchical design allows for efficient and modular design. Flutter also currently has built-in UI components for Material design (Android) and Cupertino (mimicking iOS). This is great not only for designers, but also helps support staff down the line. Not having to learn how two different versions of the app work makes it much easier to support the end user. Additionally, there is no visual (drag and drop) UI design tool. This may initially sound like a missing feature, but seasoned developers often prefer defining an app's UI programmatically. Writing human-readable code allows for peer review and better transparency of changes, especially in a team environment.

### A Responsive and Growing Community 

Our team found some bugs in the Flutter code itself and reported it to the Flutter team on GitHub. Within a matter of hours, they had a response, and within days, a fix. Knowing that there is an active, responsive community behind this product is a major upgrade from other frameworks, where issues can linger for months or even years, often resolved with mere workarounds rather than genuine fixes.

## Understanding the Downsides of Flutter

We clearly like Flutter, but do we consider it perfect? No. Here are some of the challenges we ran into. 

### Facing the Learning Curve in Flutter’s Layout System

In Flutter, each widget's size and position are dictated by “constraints.” These constraints can be set by the widget itself, or inherited from its parent widget in the hierarchy. While powerful, understanding and using constraints effectively can be challenging for developers new to Flutter.

### The Downside of Flutter’s New Community

Not all the developers understand Dart to the degree that they understand other programming languages, and some will sometimes try to make Dart and Flutter fit the principles of whatever language they’re most familiar with. This creates some very questionable third-party packages. Our team ran into a major security package that was untested, written in incomprehensible code, and was in fact bypassing security in several places. It's important to note that high ratings on GitHub may not always equate to quality, given Dart's limited range of options. You can assume that a similarly rated package in other communities is high quality, but you’ll need to do your due diligence with Flutter.

### Google Support: A Necessary Requirement 

True, it is open source, but Google is currently paying senior level full-time developers to maintain and support it. If that were to go away, the most likely result would be that Flutter would fizzle out, and you could be left with an app that would need to be rebuilt. Based on the amount of resources that Google is currently investing, we think it’s highly unlikely that they will discontinue this product (and if they did there would be time to move off of it), but it has been known to happen.

### The Challenge of Non-Native Controls

Apps that interact with other apps, such as 1Password, need to see native controls in order to function, and therefore do not work with Flutter. Workarounds are possible, such as designing the login screen in both native languages, but this isn’t a ready-to-use solution. You’ll also notice that native control updates won’t appear in your app until the framework is updated. Xamarin and React Native don’t have this issue because they are working with native controls underneath the translation layer, which allows native apps to receive all updates automatically and without extra work.

### The Limitations of Native Development Tools 

Xcode and Android Studio only work to a limited degree with Flutter. Building and debugging tools may be missing if the Flutter team has not yet fully integrated them, and Play Store automated testing does not work at all.

## In Conclusion: Weighing the Pros and Cons of Flutter

Depending on the needs of your business, Flutter may be the most efficient and cost-effective option for getting your mobile app built for multiple platforms. Our team has found that in most use cases, the positives greatly outweigh the negatives. As a developer, you still need to know and understand the platforms you are developing for; Flutter is not a shortcut. And for business owners who desire the highest level of user experience, seamless platform integration, and customized native features, opting for native development may be necessary. But for many apps that simply call for data input, data output, and maybe a little more, Flutter will easily serve your needs at half the price.

Flutter logo on a background of digital waves

Flutter—“write once, run everywhere”—a cost-effective and high-quality reality in software development.

How Flutter Is Revolutionizing Cross-Platform Development

As a decision-maker at a small or midsize startup, you are constantly challenged to meet consumers' expanding expectations while maintaining high performance, dependability, and cost effectiveness in your operations. 

With cloud services such as Amazon Web Services (AWS), the days of configuring and maintaining your own on-premises servers to manage your data are happily a thing of the past. Digitally speaking, utilizing cloud services in today's fast-paced digital world—when competition is at an all-time high and consumer demands are increasing by the minute—offers organizations a cost-effective way to be flexible and scalable.  

In this article, we'll look at some of the advantages of building a scalable cloud infrastructure, explore the tools and strategies needed to do so, and talk about how The Smyth Group teams can support you at any of the stages discussed below.

## What is Scalability?

If you’ve ever driven in a city like Los Angeles during rush hour, you understand what it means to be beholden to an infrastructure that has not grown to accommodate the city's growing population and offers a dismal public transportation system. 

On the other hand, cities like Tokyo that offer extensive public transportation systems can effectively control traffic and mitigate congestion despite surges in demand—all while maintaining punctuality. This is what it means to scale.

![Cars stuck in city traffic during the twilight hour.](/uploads/traffic.jpg)

Just like a well-designed transportation system, in the context of cloud architecture, scalability refers to the ability of a system or application to handle increased workload and grow seamlessly as demand grows without compromising performance, dependability, or racking up astronomical expenses. You can easily accommodate expansion, handle surges in user traffic, and maintain a positive user experience with a scalable infrastructure, which leads to the organic growth of your company.

## Infrastructure Planning

System requirements vary—what works well for one system won’t be the best fit for your use case.  That said, before we dive into the implementation, it is important to analyze the system requirements and the scaling needs. 

AWS offers more than [200 fully featured](https://aws.amazon.com/products/?pg=WIAWS-N&tile=learn_more&aws-products-all.sort-by=item.additionalFields.productNameLowercase&aws-products-all.sort-order=asc&awsf.re%3AInvent=*all&awsf.Free%20Tier%20Type=*all&awsf.tech-category=*all) and robust services, which can help your company accomplish its objectives. Some of these services can be configured to autoscale based on demand. A virtual server functions like a real, physical server but is actually a piece of software that allows several servers to run on one actual machine and is hosted on the cloud. These servers, known as AWS Elastic Compute Cloud ([EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/concepts.html)), can vary in size and compute power. AWS [Lambda](https://aws.amazon.com/lambda/features/) is a serverless approach to offer compute power without the need to configure servers. 

On the other hand, [DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Introduction.html) is a high-performance NoSQL data storage, which means it can handle a considerable amount and variety of data. It can be replicated seamlessly across multiple zones and regions, meaning that your data will always be safe and available. [RDS](https://aws.amazon.com/rds/features/) is a managed relational database service that hosts and manages relational databases and can scale up or down based on some configurable policies.

## Provisioning Infrastructure

Now that we have a clear vision of the infrastructure components, the next step is to set up, or provision them. While the AWS console offers a user-friendly way to provision services, as your startup grows and you begin using more services, it might become  difficult to keep track of everything. 

Additionally, some features aren’t fully supported on the web console for advanced use cases. For example, you can construct and configure AWS Lambda functions using the web portal, but it can be time consuming and difficult to release a new version of the code. And while it is possible, the new version might not be done in time to accommodate other integrations that are dependent on it.

That is why our preferred approach is utilizing a different solution called infrastructure-as-code (IaC). This process allows a developer to write a code script that tells a program how to automatically provision, or set up, other cloud services.  This means you don’t have to manually set up each service—the setup process can be replicated, and this allows for scalability. 

A lead tool for IaC is [Terraform](https://www.terraform.io/) by HashiCorp. Terraform allows you to define and manage your infrastructure resources in a declarative and version-controlled manner. With this tool, we can effortlessly configure and provision various AWS services such as EC2 instances (virtual servers), Lambda functions, DynamoDB tables, and RDS instances, ensuring consistency and scalability across your environment.

## Scalable Computing

As discussed, there are many ways to scale computing power. In this section we will focus on scaling AWS Lambda since Lambda allows your startup to focus on what really matters, which is building application logic without worrying about managing servers.

For example, when implementing business logic functions using Node.js (a popular JavaScript runtime environment used for server-side applications) and deploying them to Lambda, you can leverage the auto-scaling offered by AWS Lambda. There is no need to manage the load at all as AWS Lambda will react to fluctuating workload by either scaling up or down. This means no more paying for idle servers.

## Scalable Data Storage

Your startup's growth is mirrored in the complexity and amount of your data. The scalability and performance you need to manage heavy workloads are provided by multiple options.  When using DynamoDB, effectively setting tables will enable efficient data storage and retrieval, guaranteeing that your application will stay responsive as the user base grows.

When choosing Amazon RDS, there are multiple scaling options:

* **Vertical scaling,** also known as scaling up or scaling down, refers to increasing or decreasing the capacity of a single resource.You can add more capacity in your database, which is as easy as toggling a switch by swapping the underlying server with a bigger one.
* **Horizontal scaling,** also known as scaling out or scaling in, refers to distributing workload across resources. You can expand database activities over multiple nodes (i.e. servers within the network). For example, if there are specific operations that require read only processes (perhaps to generate analytics data), then AWS can handle that for you either by using Terraform to add a secondary replica or by configuring change quickly with a few clicks on the console.

## Saving Money with Cloud Cost Optimization

While the Cloud offers many advantages, it can become expensive if used without understanding the pricing models for each of the services. But that doesn’t mean you have to break the bank trying to achieve the scalability needed to run your applications and services. AWS provides a number of methods for creating a cost-effective architecture. 

You may reduce expenses while maintaining performance and availability with the use of reserved instances, spot instances, and auto-scaling. Reserved instances offer a discount when you commit to a certain number of resources within a specific period of time (a great option if you know you’ll need them). Spot instances offer last-minute reduced prices for unused resources. These are ideal for tasks that can withstand interruption because AWS has the right to take back these resources if needed. 

By carefully choosing between these two options, you can reduce costs. Also, AWS Lambda and DynamoDB automatically scale resources based on demand, further aiding in cost optimization. 

To make things more visible for you as a decision-maker, AWS offers ways to help you be informed. You can see a detailed billing dashboard that will help you visualize where your dollars are spent and a budget limit can be added to help you get notified when it is exceeded. These features give you insight to make informed decisions.

![Blocks stacked on top of each other in an ascending order. ](/uploads/aws-scalingup.jpg)

## Scaling Up

Scaling up becomes necessary when user demand grows and your startup receives more traction. To support this expansion, AWS offers a wide range of tools and tactics. And that is where we can be of help. 

Our teams have been building and scaling up applications for years on the cloud. We would love to discuss how we could partner up with you to bring our knowledge and expertise to facilitate the use of the cloud at scale!

Two developers coding together with the AWS logo overlaying

Explore the tools, strategies, and advantages of building a scalable cloud infrastructure. 

Building Scalable Cloud Infrastructure on AWS

Building Scalable Cloud Infrastructure on AWS: A Startup’s Guide

A decorative image of a graph made of dots.

McDonalds sign lighting up the sky in the early hours of morning. 

When fast-food powerhouse McDonald’s wanted to increase its milkshake sales, they did the seemingly sensible thing—researched demographics, built focus groups, and collected input from customers. Then, McDonalds made and sent “better” milkshakes out into the world, and waited for sales to spike. Instead, sales remained bewilderingly the same. What went wrong? 

Get it while it’s hot!

popular.

Looking to stay on top of best practices or industry standards when it comes to software? You’re at the right place. Subscribe for updates on our new articles, videos, and podcasts—all interesting content that you won’t want to miss.

3D cubes in the shape of an ascending graph.

stay informed.

A person sitting on a staircase listening to a podcast on their phone through their headphones.

Healthcare

Vacation

Education

Retail

Automotive

and more

Check out our podcast **ideate.** where our UX designers delve into the UX challenges in various industries and discuss potential solutions.

listen.

Watch our developers, designers, and strategists as they educate audiences on best practices in their field of expertise. Covering topics from software and design practices to organizational methods and project management, we’re sure you’ll find our content informative (and a little humorous). 

Composite image of 2 developers and CEO, Jamie, on a video call. The 3D graphic of interlocking box shapes overlays the image.

Videos featuring our experts as they share insights and solve problems.

watch us.

See the latest insights on software, business, strategy, design, and more—all straight from our experts. Page 2

Software Insights—Articles, Videos, Podcasts, and More | TSG | Page 2

I consent to have software-related content delivered to my email by The Smyth Group and I accept the **[Privacy Policy](/privacy-policy)**.

From our minds to yours—gain from our collective insights on software, business, strategy, design, and beyond.

Get it while it’s hot!

Why a McDonalds Milkshake Story Should Reshape Your Custom Software

By Japheth Smellie • 9 minutes

Harnessing Conway’s Law to Create Better Custom Software

Team Culture

Scaling Your SaaS Platform to Embrace Growth

Software Strategy

When In-House Isn't Enough: 5 Signs You Need a Software Agency

Business Development

How Flutter Is Revolutionizing Cross-Platform Development

Software Development

Building Scalable Cloud Infrastructure on AWS: A Startup’s Guide

Systems Support

Looking to stay on top of best practices or industry standards when it comes to software? You’re at the right place. Subscribe for updates on our new articles, videos, and podcasts—all interesting content that you won’t want to miss.

Thanks for signing up!

Whoops, there was a problem!

Check out our podcast ideate. where our UX designers delve into the UX challenges in various industries and discuss potential solutions.

Videos featuring our experts as they share insights and solve problems.