Regression testing is a QA process of re-running select test cases after a software change (like a bug fix, update, or new feature) to make sure the existing functionality still works as expected. In other words, when developers modify code, testers execute regression tests to confirm nothing that worked before has broken due to the change. This acts as a safety net against unintended side effects.
Start Today
In practical QA terms, regression testing means verifying that recent code changes haven’t introduced new bugs or regressions in previously working areas. For example, if you fix a login bug, regression testing isn’t just re-testing the login (that’s retesting, more on that later) – it’s also running other authentication and user-flow tests to ensure the login fix didn’t break other features like sign-up or password reset. By re-running a suite of existing tests whenever code changes, teams can release updates confidently, knowing that “fix one bug, break three features” won’t happen on their watch. As one guide notes, regression tests let teams move fast without breaking things by catching issues before users do.
Modern development moves quickly – frequent releases, continuous integration, and rapid user feedback are the norm. Regression testing is critical in this fast-paced environment to prevent nasty surprises in production. Even a small code tweak can have ripple effects; without regression tests, those side effects might go unnoticed until users encounter them. Robust regression suites act as a safety net, flagging issues early so you don’t deploy bugs that undo previous good work.
Skipping or skimping on regression testing can be very costly. Studies show that fixing bugs in production can cost up to 100× more than fixing them during the testing phase. In other words, catching a regression bug before release saves significant time, money, and customer trust compared to dealing with it after it’s live. By running regression tests regularly, teams avoid the “two steps forward, one step back” dilemma of introducing new features at the expense of breaking old ones. These tests also protect critical user journeys and revenue paths – for example, ensuring a new checkout feature hasn’t broken the payment processing flow. In fact, regression tests are so integral to quality that they often account for roughly 80% of total testing effort and cost, reflecting how much organizations invest in staying confident that nothing vital has regressed.
Regression testing matters because it helps maintain stability, user trust, and speed. It gives your team the confidence to innovate quickly without constantly worrying about unraveling past fixes. A solid regression practice reduces hotfix fire drills, protects your brand’s reputation, and ultimately ensures a smoother experience for users with each new release.
Where and when do you perform regression testing in the software development life cycle (SDLC)? The short answer: anytime the software changes. Regression testing isn’t a single phase – it’s an ongoing activity woven throughout modern SDLC and DevOps workflows. Here are common points where regression tests come into play:
Whenever a defect is fixed, you should rerun tests (including the one that caught the bug and related tests) to ensure the fix solved the issue and didn’t break anything else. A regression test suite is typically executed after each bug fix to verify no new issues were introduced.
In Agile teams, regression testing often happens continuously within each sprint. As new user stories are completed, testers run a subset of regression tests to confirm existing features still function alongside the new changes. This prevents a pile-up of unseen bugs at the end of the sprint.
A full regression test cycle is usually part of the release hardening phase. Before deploying a major release or update, teams run a comprehensive regression suite to catch any integration issues or unexpected side effects in the final build. This acts as a final gate for quality assurance.
Importantly, regression testing isn’t confined to just the testing “phase” of a traditional SDLC. Because it “freely floats” across stages, you might conduct regression tests anytime you integrate new code – during development, testing, staging, or even post-release (for example, running regression checks in a staging environment after a hotfix). The key is to make regression testing a continuous habit so that quality is constantly being validated. By fitting regression checks into every stage – from development (unit/regression tests by developers) to QA to pre-release and production monitoring – you ensure that no change slips through unchecked.
Not all regression testing is one-size-fits-all. In practice, QA teams use different types of regression testing strategies depending on the scope of changes, risk, and time available. Here are some common types:
Full regression testing (also known as “retest-all”) means re-running the entire test suite against the application after a change.
This approach is the most thorough – it checks every feature and component for regressions. Full regression is typically done when there are significant changes or before a major release. For example, after a large refactor or a major version update, a full regression ensures nothing in the broad system was impacted. The downside, of course, is that running all tests is time-consuming and resource-intensive.
A complete regression suite might take hours or even days if you have thousands of tests, so teams usually reserve it for when maximum confidence is needed (e.g. a big launch or an overhaul of core code).
Partial regression testing, on the other hand, runs only a subset of test cases relevant to the changes. Instead of testing everything, you select tests for the areas of the software that the latest code modifications are likely to affect.
This focused approach saves time and is useful for smaller updates or frequent iterative changes. For instance, if the only change in a release is updating the payment gateway module, a partial regression might rerun all tests related to payments and perhaps a few high-level smoke tests, but skip unrelated areas like user profile or search. Partial regression is most effective for small tweaks, bug fixes, or patches, where you know the impact scope is narrow.
It provides a targeted assurance that only the intended parts changed, and nothing else unexpectedly “rippled” out into the rest of the application
There are also specialized subsets of regression testing often referred to as smoke tests and sanity tests, as well as generally “targeted” regression approaches:
Smoke Testing (Build Verification Testing): This is a lightweight form of regression testing aimed to verify that the basic, critical functions of the application work after a new build or change.
Smoke tests are a small set (often 5–10% of the full test suite) of high-priority test cases (the “happy path” flows) that you run on a new build to make sure there are no showstopper issues before proceeding to more exhaustive tests.
Think of smoke tests as a quick health check – “does the app launch, do key features like login or checkout still work at all?” If a smoke test fails, it signals something fundamental is broken, and the team should fix that immediately before any further testing. Smoke testing is typically automated and runs fast (minutes), acting as an entry gate for deeper regression testing.
Sanity testing is a narrow and deep form of regression test focusing on one or few areas of functionality to ensure they work correctly after minor changes or bug fixes. It’s like a targeted subset of regression testing done when you don’t need or have time for a full sweep.
For example, if a bug was fixed in the search results pagination, a sanity test would quickly validate the pagination on search results (including a few edge cases like first/last page) without re-testing the entire search module or other features.
Sanity tests are often used after very small code tweaks or as a final quick check right before a release on a specific component. They are faster than full regression because they only cover the modified functionality and its closely related features
This approach overlaps with partial regression – it means choosing a specific set of regression tests based on what parts of the code were changed (often informed by impact analysis). A targeted regression test suite exercises the components or features most likely affected by the recent changes.
It could include relevant integration tests around the changed module, and perhaps some high-level end-to-end tests to ensure the changed module still plays nicely with the rest of the system. Targeted regression is essentially risk-based testing – you focus on the areas of highest risk for breakage. For example, after updating the user profile component, you’d run regression tests for user profile update, maybe login (if profile ties into authentication), and view profile, but not bother re-testing unrelated modules like payments or search. This strategy keeps regression cycles lean and efficient during frequent deployments.
One big strategic question for any team is how much of regression testing should be done manually by human testers versus automated by scripts/tools. Regression testing by nature is repetitive, making it a prime candidate for automation. In fact, regression testing is often cited as a perfect use case for test automation. Once you have a stable set of test cases that need to be re-run over and over, having an automated test framework execute them can save enormous time and ensure consistency in results.
Automated regression testing means using scripts or testing tools to run your regression suite without manual intervention. The advantage is speed and reliability: automation can execute a large volume of tests much faster than a person (especially in parallel on multiple environments), and it will do so exactly the same way every time. This is crucial in Agile and CI/CD contexts where you might be running regression tests daily or even on every code commit.
By automating the stable, repetitive test cases, teams get immediate feedback on each change and free their human testers to focus on more complex exploratory testing. For example, an automation tool can re-run hundreds of API regression tests after every backend change to ensure all endpoints still return correct responses.
Without automation, doing that level of check continuously would be impractical. As IBM notes, automation “ramps up” the speed of regression execution even for large systems, allowing you to cover more in less time.
Manual regression testing still has an important role. Not every test is easily automated – especially tests requiring human observation or judgment. Certain scenarios require human understanding, such as checking visual elements or the user experience across different devices. For instance, after a UI change, a manual tester might need to verify that a layout still looks correct on various screen sizes or that an animation still feels smooth – things that are hard for an automated script to judge. Manual regression testing is also useful for exploratory regression, where testers freely roam the application around the changed areas to see if they can discover any odd behavior that scripted tests might miss.
When to favor manual vs automated? The general best practice is: automate the predictable, repetitive regression tests (especially those critical path tests you run every time) and use manual testing for the cases that benefit from human insight – such as UI/UX nuances, exploratory probing, and edge cases. For example, automate your login, checkout, and API response regression checks, but a complex new feature with lots of subtle interactions might get a manual regression pass the first time until it stabilizes enough to script. Remember that manual testing is slower and can be error-prone for rote checks, so you want to minimize manual effort on things a script can do. At the same time, don’t blindly automate tests that frequently change or require subjective evaluation, or you’ll spend too much time maintaining scripts.
Typically, a hybrid approach works best: automate stable high-value regression tests (to accelerate your cycles and catch regressions quickly) and rely on skilled QA engineers to manually cover the areas where automation falls short (visual polish, complex user journeys, unpredictable scenarios). This way, you get the efficiency of automation plus the insight of human testing. Done right, automated regression testing in your pipeline will handle the heavy lifting and “provide fast feedback on each code change, reducing tedious manual regression runs,” while manual testing will add an extra layer of assurance for the trickier parts.
Designing a regression test suite isn’t just about piling up all your tests and running them over and over. A bloated or poorly structured suite can become unmanageable or inefficient. Here are key tips for building an effective regression test suite that stays lean, high-value, and maintainable:
Use a Risk-Based, Critical-Path Focus: Start by identifying the most important functionalities and the areas of the application most likely to be affected by changes. An effective regression suite is selective – it emphasizes high-risk, high-impact, and frequently used areas of your application. These often correspond to real user journeys (e.g. account signup, adding to cart and checkout, generating a report) and past problem spots. By prioritizing tests for core features and known fragile areas, you ensure your suite has maximal bug-detection power where it matters most. Not every minor feature needs equal regression coverage – focus on what would hurt most if it broke.
Leverage Test Case Prioritization: Within your regression pack, assign priority levels to test cases. This way, if you’re ever time-constrained, you run the top-priority tests first. Common prioritization factors are business impact, frequency of use, and historical failure rate. For example, login or payment processing tests would be very high priority (critical business function), whereas an admin settings edge-case might be lower. Many teams implement a tiered regression suite (e.g. Tier 1 smoke tests, Tier 2 broad regression, Tier 3 extended tests) and execute them in sequence until time runs out. By prioritizing, you catch the most critical regressions early even if you can’t run everything every time.
Analyze Changes & Select Tests Smartly: Each time there’s a change, do a quick impact analysis to choose relevant regression tests. Look at the code modified or the feature added and map it to existing test cases. If you have traceability (mapping of tests to requirements or modules), use that to pull the subset of tests that cover the affected components. The idea of “regression test selection” is to reuse only the tests that are likely to reveal issues from this change. This keeps regression cycles efficient. Additionally, consider adding new test cases when new features are developed or new bugs are found (to prevent repeats). Over time, your regression suite should evolve with the product.
Keep the Suite Up to Date (Maintenance is Key): An effective regression suite requires continuous curation. Periodically review your test cases and remove or fix those that are obsolete, redundant, or consistently flaky. If a feature is deprecated, drop its tests. If you find two tests overlapping heavily, consolidate them. Regular maintenance prevents the suite from becoming bloated with tests that rarely catch issues. A leaner suite runs faster and is easier to manage. It’s also important to update existing test cases when features change; outdated tests that don’t reflect the current application can lead to false failures or misses. Teams that neglect maintenance often end up with a huge suite where many tests are broken or irrelevant, undermining confidence. Don’t be afraid to refactor the test suite as you would code – it’s a living artifact that needs care.
Incorporate Real Data and Usage Patterns: Designing tests based on how users actually use your software can make regression testing more meaningful. If you have analytics or logs, identify the most common user flows and make sure your regression suite covers those heavily. Also consider edge cases and past production bugs – include tests that would have caught those issues so they don’t recur. By basing regression tests on real-world usage and historical defects, you maximize the chances of catching the kind of regressions that would impact users in production.
Plan for Speed and Parallelism: As your application grows, even a well-curated regression suite might become large. To keep execution time reasonable, design your suite and infrastructure to support parallel test execution. This might involve splitting tests into groups that can run on multiple machines or threads simultaneously (especially UI tests which tend to be slower). Also optimize individual test scripts for speed (setup test data efficiently, avoid unnecessary waits, etc.). Knowing how long your full regression takes helps you integrate it into CI pipelines appropriately (for example, maybe full suite runs nightly if it’s a few hours, whereas a quick subset runs on each commit). The goal is to establish reliable test windows – developers should know if they merge code by 5pm, the nightly regression will catch any issues by next morning, for instance.
Balance Automated vs Manual Cases: As discussed earlier, plan which test cases will be automated and which will remain manual. Generally, your regression suite documentation can include both, but you might have a core automated regression pack and a manual exploratory checklist for regression. Make sure it’s clear who/what executes each test and when. Having this structure prevents gaps where some features might not be covered by either manual or automated tests due to assumptions. Each important scenario should have an owner (either an automated script or a manual test case assigned to a tester).
By applying these practices, you can build a lean, powerful regression test suite that provides strong coverage where it counts, runs in a reasonable time, and can adapt as your product evolves. The payoff is a regression suite that acts as a true guardian of quality – efficient to run, likely to catch real issues, and not a maintenance nightmare. Remember the adage: test smarter, not just harder. A smaller set of well-chosen, well-maintained tests will outperform a brute-force suite that tries to test everything under the sun with no prioritization.
When we talk about regression testing, we often think of functional bugs – features not working correctly. But code changes can also cause regressions in non-functional aspects like performance, security, or reliability. Modern QA strategies include checking these as part of regression to ensure overall software quality doesn’t degrade with changes.
Performance regression testing involves re-running performance tests (or monitoring key performance metrics) after changes to verify the application hasn’t gotten slower, more resource-intensive, or less scalable. For example, if a new version of your app loads a dashboard 2 seconds slower than before, that’s a regression in performance. Teams often maintain baseline performance metrics (response times, throughput, memory usage, etc.) and compare new builds against them. If a change causes page load time to spike or CPU usage to double, the performance regression test would flag it. As IBM highlights, if new functionality increases page loading times, that indicates a regression in performance. Catching these issues early is important – performance degradations can creep in unnoticed if you only focus on functional tests. By including automated performance tests (like running a quick load test or measuring response time of critical APIs) in your regression suite, you ensure that speed and efficiency remain within acceptable ranges release over release.
Similarly, consider security regression testing – ensuring that a change hasn’t opened up a vulnerability or broken a security control. For instance, if you update a library and it disables some authentication check, you’d want to catch that. Security tests (like automated vulnerability scans or specific test cases for known security requirements) can be rerun after changes. They act as regression tests for security features. Another example is after a bug fix, re-testing that user roles and permissions are still enforced correctly (to confirm the fix didn’t inadvertently grant access where it shouldn’t).
Other non-functional areas include usability and reliability. If you have tests or metrics around these (like uptime, error rates, UI accessibility checks, etc.), you can incorporate them in regression cycles. Sometimes this is as simple as monitoring error logs or uptime after deployment (to catch crash spikes which indicate stability regressions), or running an automated accessibility audit to ensure new UI changes didn’t break compliance.
The concept of non-functional regression is essentially validating that changes haven’t harmed the “quality attributes” of the system beyond just correct features. A robust regression testing strategy will tie functional and non-functional tests together. For instance, you might run your functional regression suite, then also run a quick performance test and a security scan in the same pipeline. If all pass, you have confidence not only that features work, but also that the software is still fast, secure, and reliable as before.
To illustrate, imagine you fix a database query bug in an e-commerce app. Functional tests show all features still work – great. But a performance regression test might reveal that the new query, while correct, is much slower under load, threatening your page response SLAs. That’s critical info you’d want to know before releasing. Performance regression testing would catch it, giving you a chance to optimize the query further.
In practice, teams might maintain separate regression suites for non-functionals (like a set of automated performance scripts). Some integrate basic performance checks into functional tests (e.g. asserting an API call returns within X milliseconds).
The key takeaway: don’t neglect non-functional aspects when thinking about regression. Ensure your QA strategy includes checks so that code changes don’t degrade things like speed, security, usability, or compatibility. Your users care about these just as much as they care about features working. By treating performance and other qualities as first-class citizens in regression testing, you safeguard the overall user experience and system health with each release, not just the feature checklist.
At Total Perform, regression testing is in our DNA. We were founded as a QA and performance engineering consultancy back in 2005, so we’ve spent years refining how to build robust regression testing practices that fit into modern delivery cycles. Our approach to regression testing is both strategic and hands-on, focusing on tailoring solutions to each client’s needs while leveraging our deep QA expertise.
Here’s how we typically approach regression testing for a client:
Assessment of Current State: We usually begin with a thorough review of your existing QA process and test suites. This is essentially a regression testing assessment or QA audit where we evaluate your current regression coverage, tools, and pain points. Our experts will pinpoint gaps (e.g. critical functionalities not covered by tests, or tests that are consistently flaky), inefficiencies (perhaps you’re running too many redundant tests, or your tests aren’t integrated into CI), and any bottlenecks in your regression cycle. This assessment gives a clear picture of where you stand and forms the basis of a roadmap to improve.
Designing a Lean, High-Value Test Suite: Based on the assessment, we help design an optimized regression test suite that is risk-based and lean. This means identifying the tests that truly add value and eliminating or deferring those that don’t. We prioritize creating test coverage for the most important user journeys and business-critical flows (often using analytics and our experience to determine high-risk areas). If your current suite is bloated or unfocused, we’ll work on trimming it down to a core that provides maximum assurance with minimal noise. We also ensure that new test cases are designed for any gaps we found – for example, if a critical integration wasn’t being tested, we’ll develop the necessary test cases to cover it. The outcome is a regression suite that is “lean and mean” – covering the right things with as little waste as possible.
Blending Manual and Automated Strategies: Total Perform’s approach recognizes that both manual and automated testing have roles. We’ll identify which regression tests should be automated (usually the repetitive ones and those needed in CI pipelines) and which might remain manual/exploratory for now. Our team has deep expertise in test automation, so we often implement or improve automation frameworks as part of regression testing engagements. For example, if you don’t have an automation framework, we can help you choose the right one (Selenium, Cypress, JUnit, etc.) or build a custom framework that fits your technology stack. We ensure your automated tests are reliable and maintainable - leveraging practices like page object models, robust waiting mechanisms, and clear reporting. The goal is to integrate automation such that running the regression suite is largely push-button. At the same time, we often introduce process improvements for manual regression (like better test case management, exploratory charters for new features, etc.) so that any manual aspects are well-organized and effective.
CI/CD Integration and Tooling: Because rapid feedback is crucial, we work on integrating regression tests into your CI/CD pipelines. This might involve setting up test environments that deploy on each build and hooking automated tests to run on your CI server (Jenkins, GitLab CI, etc.). If you already have CI, we make sure the tests can run headlessly and report results in a dashboard or messaging channel for the team. We also look at test data and environment management – setting you up with strategies for test data resets or using containerized environments so that regression tests are running in production-like conditions reliably. Essentially, we bring engineering rigor so that regression testing happens continuously without heavy manual triggering. Our performance engineering roots also mean we consider performance regression checks as part of this integration when relevant.
Continuous Improvement and Coaching: Implementing regression testing isn’t a one-off project for us. We often work side-by-side with your team to instill good testing practices. That might include training your QA engineers on using new automation tools, coaching developers on writing unit/integration tests (shift-left), and establishing guidelines for when to add new regression tests (like after every bug fix or feature). We try to build a regression testing culture where quality is everyone’s responsibility. Over time, we help you refine and adjust the regression suite as your software evolves – ensuring it remains effective and efficient.
Our approach is very much customized: a startup releasing daily might need a lightweight, fully automated smoke/regression set, whereas an enterprise product might need a more extensive suite with formal test management. In all cases, the core principles we bring are risk-based focus, automation excellence, and integration into the development workflow. We pride ourselves on designing regression testing processes that catch more bugs while running in less time. And importantly, we align regression testing with business goals – protecting the user experiences and features that matter most to your success.
By partnering with Total Perform, clients get the benefit of our QA and performance engineering heritage. We’ve seen a lot of regression testing pitfalls (and fixed them) across industries, so we bring those lessons learned straight into your project. Whether you have a bare-bones testing setup or a massive suite that needs overhaul, we can help implement a regression testing strategy that gives you confidence in each release. Our consultants often say the goal is to enable clients to “release with confidence, not fear.” A solid regression testing practice is the cornerstone of that confidence, and we’re here to build it with you.
Talk to us about a regression testing assessment - our QA experts can review your current suites, identify gaps, and design a lean, automated regression strategy that fits your delivery pace.
SCHEDULE A CALLHave a question? Click "Get Started" above to schedule a free consult and discuss your specific engineering needs.
Ideally, regression tests should be run whenever code changes are made – the more frequently, the better. In practice, teams run regression suites at multiple stages: after individual bug fixes or feature merges, as part of each daily/CI build, and certainly before any major release. With a well-automated suite, it’s common to run a subset of quick regression tests on every code commit (or at least every day) and the full suite nightly or weekly. The key is to integrate regression testing into your regular development cycle so that no change goes un-checked. In Agile/CI environments, it’s typical to have automated regression tests running continuously (for example, smoke tests on every commit and a broader set on each nightly build). At minimum, always run regression tests before releasing to catch any showstopper issues in existing functionality.
You can (and should) automate the majority of regression testing, but not necessarily 100% of it. All the repetitive test cases that run frequently are excellent candidates for automation – and modern tools allow a high degree of coverage through automated UI tests, API tests, and integration tests. In fact, regression testing is considered a perfect candidate for test automation, because it’s repeatable and needs consistent execution. Many teams achieve a mostly automated regression suite, which runs unattended in CI pipelines. However, certain things like very visual checks or unusual use cases might remain manual. Also, whenever new features are first developed, you might do some manual regression around them before investing time in scripting tests. So while you might not literally automate every single test case, you can automate the core suite that covers the vast majority of scenarios. The goal is to have as much automated as possible so that regression tests can run fast and frequently. Remember, even if regression testing is highly automated, you’ll still do some manual exploratory testing around the edges – automation and manual efforts complement each other to catch different kinds of issues.
Retesting (also known as confirmation testing) is about verifying that a specific bug fix actually resolved the issue, whereas regression testing checks that no new bugs were introduced in other areas. When you retest, you focus only on the exact scenario of the defect that was fixed – essentially, “has the bug I fixed now passed the test that it failed before?” Regression testing, on the other hand, is broader: you run a selection of tests across the application to ensure the recent code changes didn’t break anything that was previously working. One way to put it: retesting tests where a bug did exist to confirm it’s gone, regression testing looks at where bugs did not exist (previously passed tests) to see if any new ones appeared. Both are important – you first retest to validate the fix, then do regression testing to check for side effects. For example, if a save button had a bug, you’d first retest that the save button works now (bug fixed), then you might run regression tests on related features (maybe loading and editing of that item, or other buttons) to ensure those still work too.
A regression testing assessment (or QA process audit) is a comprehensive review of your current regression testing practices by QA experts. In an assessment, the team will look at things like: what test cases you have and their coverage, how you manage and execute your regression suite, what tools you’re using, how long tests take, and where your pain points are. They’ll identify any gaps – for example, maybe some critical features aren’t being tested in regression, or perhaps you have a lot of overlap in your test cases. They also evaluate efficiency issues: is your suite too slow? Are tests flaky? Do you have proper test environment and data strategies? After gathering this information (often through interviews, observing test runs, and reviewing test artifacts), the assessors will provide recommendations for improvement. This might include suggestions like tests to add or remove, areas to prioritize, introducing automation or new tools, better scheduling of tests (like integrating into CI), and process changes for maintaining the suite. Essentially, it’s a roadmap of practical steps to level up your regression testing. At Total Perform, our assessment would result in a report and debrief where we outline the quick wins and longer-term enhancements for your regression strategy.
Total Perform can help in several ways, drawing on our QA consulting expertise. First, we can audit your current QA and regression process to pinpoint gaps or inefficiencies – giving you a clear picture of what’s working and what isn’t. Then, we work with you to design a tailored improvement plan. For instance, we might help you build a leaner regression test suite that focuses on high-risk areas and cuts out unnecessary tests. We also specialize in test automation and CI/CD integration – our engineers can implement or enhance your automation framework and integrate regression tests into your development pipeline for continuous testing. If your team is new to automation, we can create the initial set of scripts and frameworks and train your team to extend them. Additionally, we bring best practices to reduce flakiness and improve test reliability (so your regression results are trustworthy). In short, we provide both strategic guidance (what to test, how often, with what priority) and hands-on help (building the actual tests and infrastructure). The outcome of engaging with Total Perform is a regression testing approach that is faster, more reliable, and fits your delivery pace, allowing you to release software with greater confidence and less fire-fighting. Whether you need a one-time assessment or ongoing QA support, we adapt to what makes sense for your organization and drive tangible improvements in your QA outcomes.
Nearshore teams that onboard fast, collaborate deeply, and build better products.
