Our Blog

React can be so simple and so powerful that it is one of the first choices when it comes to building a web app nowadays. But with great power comes great responsibility. Being so widespread and used, it's easy to find tons of results when looking for solutions that fulfill developer needs, but the most popular solution may not always be the best for every case.

In this article I’m going to cover some common patterns and tools developers tend to blindly stick to without assessing whether they actually apply to their specific use case or not.

Using a Library for State Management

Don’t get me wrong, correct state management is a fundamental part of building a reliable, scalable, and futureproof application. It’s particularly important to take it into account early on in our projects, but you might want to think twice before just starting with a template based off of  [insert popular state management library here]. There are a several reasons why I think this way:

• It forces you to think and model your application in the library's way of doing things, instead of making choices that could reflect the business reality in a more accurate way. Whether you use redux or mobx (or nothing at all) should depend on if it makes sense for your use case, and not simply on what’s trendier.

• You may be making your app less performant. Bundle sizes and performance on lower end devices are metrics that we as developers tend to gloss over, but can end up making a huge difference on the way your users interact with your product. Also, there’s more library code that when used incorrectly may lead to unwanted re-renders, thus making your app less responsive.

• At the end of the day, it’s something new you need to learn, document, teach, maintain, and upgrade over time. This is the key factor when deciding to use a state management library or not: will it save you enough time and make your life that much easier in the long run that it’s worth teaching it to every new developer that joins the project? Will you have the time to document a specific scenario where you do things differently? Are you willing to upgrade all of your codebase because of a breaking change? If the answer to all of these questions is yes, then go ahead.

Creating Too Many Files/Folders

If you come from a framework like angular, you may be familiar with the idea of creating a couple of files and a folder just to organize your independent UI components. Add modules, routing files, indexes, and services and you’ll end up with a lot of boilerplate to make things work the way you want in any given scenario. Boilerplate is not a bad thing per-se, but with React we’re not required to have this much ceremony in order to build our apps.

Now, I’m not saying you should go and delete all of your .js files and bake everything in the same file, but embracing the flexibility the framework gives you will help you create apps that are easier to navigate through, and therefore, are more maintainable. The official React documentation even encourages this approach, and provides us with some guidelines to take into account when laying out our app structure.

Here are some things I do to avoid unnecessary nesting/file creation:

• Don’t create boundaries where there are none: While it’s pretty common to  consider that everything apps are made of is screens and components, what actually differentiates one from another? What you think of today as a component may become a screen down the road, or vice versa. Whenever your domain makes it clear that some things should belong to a folder, then go for it. Creating an extra file folder before the need comes up just creates extra work. Dan Abramov talks more about this in this article where he clarifies the difference between presentational and container components—but beware! You’ll actually find a disclaimer where he talks about how his views have changed since the writing of that article.
• Leverage the power of hooks: You may be tempted to create new files as new complex components start forming, and eventually you might want to put together components that share similar logic in a folder. The thing is, you may be able to avoid all of the added complexity of similar-yet-specific components by using hooks to properly reuse your logic.
• Use Styled Components: Styled Components can help keep all the styling and the logic related to it within the same file most of the time. This depends greatly on each use case, but they’ve gained popularity because of their flexibility and simplicity to setup, read, and maintain across my apps.

Testing the Wrong Places

While a robust testing suite should be a priority whenever you ship a product that will continue being developed in the future, testing the wrong places could be the source of many frustrations and time wastes, especially on the frontend. Let’s first define what these “wrong places” are and aren’t.

Kent Dodds writes in How to know what to test

“When writing code, remember that you already have two users that you need to support: End users, and developer users. Again, if you think about the code rather than the use cases, it becomes dangerously natural to start testing implementation details. When you do that, your code now has a third user.”

In this post we’re talking about how to make the “developer users” happier. If you’re able to write tests that will actually detect bugs in the future, you’ll inevitably be happier. How do you achieve this? By testing your app the way the users would, avoiding high-effort/low-value code chunks, and writing concise and understandable tests.

Let’s break these down one by one:

• Testing the way users would use the app: Here I strongly recommend reading Kent Dodds Testing Implementation Details, who elaborates on how testing implementation details can lead to error prone tests that aren’t actually very useful for catching bugs.
• Avoid high-effort/low-value code chunks: If you’re solely using code coverage as your metric to determine the quality of tests (which has its own problems), you’ll often find there’s some code dependant on a third party library that doesn’t quite work as you expected and drags the coverage down. In this case you’ll have to weigh how critical the feature is to the application vs the amount of time you’ll have to spend coding, maintaining, and replicating the functionality across several sections of your app.
• Write concise and understandable tests: The more simple, explicit, and understandable a test is can reflect how well a functionality is written. While you should avoid making your implementation more complex just to simplify the tests, if your test can describe what the end goal of a functional piece is, a new maintainer might find it easier to read and make changes to the codebase.

While there are no rules set in stone for writing perfect React code, following these guidelines has saved me time and spared me from bugs and unnecessary meetings in my career. I hope it does the same for you.

Do you have any examples of over-engineering in your favorite framework? How do you usually solve them? Leave it on the comments!

There’s plenty of material telling you about the benefits of outsourcing software development services to nearshore companies. The upsides are similar time zone, cultural affinity, a high-quality talent pool, and cost reductions. Even though these things are true, that’s just a general idea of what nearshore outsourcing is all about.

You might be already interested in it, but given how many software development teams are out there, how do you know which one you should partner with?

Read on as we point out what factors are most important to consider when choosing your next nearshore software partner.

A bargain might compromise your business

If you’re considering nearshoring just to save as much money as possible, then you’re missing the point. In fact, just considering the cheapest option could lead to bad experiences.

Magne Jørgensen, researcher and professor at the University of Oslo, showed in a research paper that software providers with bids 25% lower than the average correlate to a 9% increase in the frequency of project failure for the same skill level, suggesting that an excessive emphasis on low prices makes it more likely that projects fail.

Software development is no simple task. It takes hard work, knowledge, skill, and most importantly time, to end up with a scalable, testable, and user-friendly software product ready to run.

Promises of exceptionally quick work at the lowest price should be viewed with healthy skepticism. You might know of folks in your community who have already gone through bad situations when their cheap outsourced software turned sour, like Boeing's offshore outsource fiasco.

Don’t get discouraged though!

Finding quality nearshore software development companies while not breaking the bank is still possible because of the exchange rate, salary differences, and great talent pool. You just need to take your time and correctly assess your potential partners before making a decision, which leads me to my next point.

Agile methodology is key to success

Avoid injecting money into a black box, only to open it months or years later and find something completely different than what you were expecting. Partnering with software companies with a strong agile approach is a great way to prevent this.

The Forbes Technology Council agrees that an agile software development process translates into quality project management: faster feedback cycles, effective problem identification, disrupting changes prevention, flexible prioritization, maintaining high customer satisfaction, identifying benefits sooner, free commitment and continuous improvement.

Software development does better in an ongoing back-and-forth process, where you describe your desired result to your IT partner, evaluate the intermediate results, both parties provide feedback and exchange opinions, and iterate the process until convergence is finally achieved.

And how do I identify a software company with a strong agile culture you ask? You should evaluate how they behave. Shy away from those trying to sell you pre-established solutions, and stick to those who are honestly trying to understand what your needs are and how your business model works.

A good agile team will not only come to the Scrum Ceremonies with regular updates, but they will dive deep into your ideas and actively look to suggest recommendations and improvements to your product.

Every project is unique, and will require the most focused, responsible, and committed development team to bring your ideas down to earth and successfully deliver. Checking references is a good starting point.

The importance of user experience (UX)

Nowadays our brains are being bombarded with information and stimulus coming from everywhere, specifically from our computers and cell phones, constantly distracting us with our social media feed, news updates, work info, and more.

Therefore, customers aren’t only needing, but are demanding, simple and easy-to-use UX/UI that lets them quickly understand and make use of your services, giving a necessary rest to their busy heads meanwhile.

To get an idea of how important this is, take for instance a research study by Baymard where they tracked the global average e-commerce cart abandonment rate for 9 years, concluding it was around 69%. The main reasons were UX/UI flaws at the design and check-out flow that frustrated or made it hard for users to buy.

If this wasn’t enough to make a point, suffice to say that after a no-ROI period, Walmart decided to redesign its website in 2018, paying special attention to UX/UI. The results: Walmart’s e-commerce sales grew by 43%.

The important question here is whether your software consultant can turn all those lines of code into something accessible and easy for your customers to use and love.

When searching for your next nearshore software development agency, take a look at their case studies. See if their previous projects not only do what they say but also look professional, simple, and smooth.

Don’t forget that even if you have the most solid software engine running, it's worthless if users find it counterintuitive.

Go for flexibility

Today's world moves fast. To survive, you must have the ability to quickly adapt to new situations.

What worked for you in the past might not be useful now. Committing to long-term relationships with a partner through hard-binding legal contracts might not be your best bet.

Outstanding nearshore digital transformation agencies know and embrace this. Moreover, they will offer flexible working frameworks where you can easily ramp up and down without any bureaucracy.

They will freely let you decide if you want to stay or leave because they’re committed to consistently providing you with the best service. That way you’ll want to keep choosing them as your software development partner because you continue to see ROI in the relationship. That’s the kind of value-based relationship you’re looking for!

Look for stable countries

So far we’ve talked about software companies and business, but given that nearshoring is the central topic of this post, we can’t avoid talking about countries.

Their strengths and weaknesses vary a lot from region to region, making it difficult to establish generalities. However, there are some key factors you should keep in mind when researching countries: political, economic, and judicial stability.

Usually, nearshore countries fall into the category of “developing countries”, which makes them interesting because of lower costs, but many often suffer from social upheavals, economic crises, and mismanaged governments.

Any of these issues can put your investment or business at risk because they could lead to exchange rate restrictions, massive layoffs, authoritarian governments, or expropriations.

When looking at which country to choose, consider Uruguay. This South American country is recognized worldwide for its enduring democratic institutions and solid rule of lay, high human development index, stable and open economy, excellent English level, the fastest internet connection in the region and massive tech education investment.

Summary

Key things to keep in mind when choosing which nearshore digital transformation agency to partner with:

• Take advantage of natural nearshore lower costs and aim for quality providers rather than blindly going for the cheapest option available
• Get close to development teams genuinely trying to understand what you need, instead of imposing their solutions. Value honest and involved development teams who aren’t afraid of telling what they think
• Give special consideration to software companies with UX/UI expertise. You want your users to experience software that runs as good as it looks
• Stick to firms that let you freely come and go within flexible working frameworks. They’ll sustain value-based relationships, providing ROI to you
• Look for the most stable countries to invest in. Stay updated on news about political instability, economic crises, or social upheavals. This way you’ll avoid future pitfalls.

Looking for a true nearshore development partner?

GET IN TOUCH

Nowadays, JavaScript is all over the place. As the code evolved, testing libraries and strategies like TDD and BDD also did. Indeed, we all agree on the same thing: Code must be tested.

In the past years, a big part of the community shifted towards Functional programming. As a side effect, the paradigm shift brought us a more straightforward way of defining and writing unit tests.

So the thing is …

What is Functional programming?

Functional programming is a programming paradigm — a style of building the structure and elements of computer programs — that treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data — wikipedia

Let's take a look at an example of code which will be the system under test:

const showResponseMessage = (response, source) => {
 let message = source.message;
 if(response.data.status) {
   message += response.data.status;
 }
 if(response.data.title) {
   message += " " + response.data.title;
 }
 return message;
}


Pretty simple, right? The function receives a response and a source, we compose the message based on data received on the response, and we return it. Let's test it!

describe('It should show the error message', ()=> {
 const response = {data: {status: 'fail', title: 'edit'}}
 const source = { message: 'The post action had '}
 it('Adds the extra info', ()=> {
   expect(showResponseMessage(response, status)).toEqual('The post action had fail edit')  
 })
})


Looks simple, right? Straight forward I'd say, let's improve it:

const showResponseMessage = (response, source) => {
 let messageResponse = getMessage(source);
 const {status, title} = response.data;
 messageResponse = addStatus(status, messageResponse);
 messageResponse = addTitle(status, messageResponse);
 return messageResponse;
}
const getMessage = source => source.message;
const addStatus = (status, message) => {
 return message + " " + status
}
const addTitle = (title, message) => {
 return message + " " + title
}


I know, the number of code lines increased, at a glance, it just seems like a more sophisticated way of achieving the same thing. But, we increased the number of tests too, enhancing the overall quality assurance.

describe('It should show the error message', ()=> {
 const source = { message: 'The post action had'}
 const response = {data: {status: 'fail', title: 'edit'}}
 const {status, title} = response.data;
 it('gets the message from source', ()=> {
   expect(getMessage(source)).toEqual('The post action had')  
 })
 it('Adds Title properly', ()=> {
   let message = getMessage(source);
   expect(addTitle(title, message)).toEqual('The post action had  edit')
 })
 it('Adds Status properly', ()=> {
   let message = getMessage(source);
   expect(addStatus(status, message)).toEqual('The post action had  fail')
 })
 it('Adds returns the right message', ()=> {
   expect(showResponseMessage(response, source)).toEqual('The post   action had fail edit')
 })
})


In the first example, if we change the structure of the response and title, the test will fail, but we won't know why the test failed. Did it fail because of a missing response message or a wrong title retrieved as part of the response?

In the second example, we are testing each functionality separately. By assigning each function it's own responsibility, we make the code more maintainable, efficient, and versatile. For more information, check the single responsibility principle.

Let's consider the following scenario, suppose that our business logic changes, and we want to prevent the spaces on title and status. In such a case, we will have to create a function that receives a text and returns the sanitized version. To test that function, we have to create a test that solely asses that requirement; this test will not be related to showResponseMessage, but to space trimming.

That example points out a single case. However, as the logic and size of the application grow, the more relevant this approach to testing will become. When we start working with async calls, with the ability of composition and Higher-Order functions, we can make our "features" readable and our functions real units.

Furthermore, all of our original values are immutable. In the first example, we modified the message variable, now we don't, we still have our original message — And why is that important? Mutation means change, change adds complexity, opens the door for bugs, and sometimes makes things unpredictable.

When our code is predictable, self-explanatory, and easier to track and read, it's much easier to write cleaner tests.

'Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write a new code. ...[Therefore,] making it easy to read makes it easier to write.' Robert C Martin.

So stay functional for simple testing and happier code reviews :)

End to End (e2e) testing is a technique that helps ensure the quality of mobile applications in an environment as close to real life as possible, testing the continuous integration of all the pieces that integrate a software automatically. On a mobile app, this could be particularly useful given the diversity of real devices and platforms our software is running on top of.

Due to the cross-platform nature of React Native, e2e testing proves to be particularly messy to work on. As a result, we have to write all of our tests bearing this in mind, changing the way we access to certain properties or query elements no matter the tool we use for connecting to it. Still, automation testing tools like Appium and WebdriverIO allow us to work over a common and somewhat standard interface.

The following instructions assume we already have React applications built with expo, and use Jest for our unit-testing solution.

Disclaimer: The following instructions are based on a Windows machine running an android emulator. output/commands may vary slightly on different architectures.

Setting Up Appium

• Install required dependencies

$ npm i -D webdriverio babel-plugin-jsx-remove-data-test-id concurently


WebdriverIO will work as our “client” for the appium server in the case of JS. There is more to come regarding how to use other clients such as python.

babel-plugin-jsx-remove-data-test-id will help us remove unwanted accessibilityLabels from our mobile app, since that’s the preferred way of targeting elements for both IOS and Android platforms

concurrently will help us automate the running of appium server and jest to do our e2e tests

• Install Appium Doctor

$ npm install appium-doctor -g


This will help us identify if we have all of the needed dependencies to correctly run appium in an emulator.

• Run Appium Doctor

Depending on the host OS we want to test in, we could run:

$ appium-doctor --android


or

$ appium-doctor --ios


For this particular case I’ll be running the android version. This will prompt some output on the console. If we have all the required dependencies installed we should see a message similar to the following

If not all necessary dependencies are met at this point, instead of checkmarks before any given item you’ll see a red X symbol. Check the end of the input for more information on how to fix the particular Issues you’re prompted.

We’re not going to fix the optional requirements that appium-doctor prompts for the time being, feel free to go over those once you have the testing solution working.

• Run Appium

By this point, you should be able to run your appium server without any issues, in order to do so just type

$ appium


You should see something similar to

If you do so, congrats! you have correctly set up appium.

Now, let's set up our tests.

Write tests once, run in any platform

One of the key features of React Native is its ability to write code once and run it in both iOS and Android, that is what we want our mobile tests to behave in the same way. There are some limitations for this, since the only way we can write a selector for both platforms is through the accessibilityLabel attribute in React Native.

This may become an issue if your mobile app depends on accessibility features. Make sure to use correct, semantic and descriptive accessibility labels at any place you intend to use them.

If a great accessibility is not on the scope of your current project (it should), you can use accessibilityLabel as a perfect target for querying your elements, just make sure you don’t accidentally worsen the experience of people using screen readers or any other assistive technology.

In order to do this, we’re going to configure our babel setup to remove the accessibility labels whenever we build for production:

/// babel.config.js
module.exports = function() {
return {
presets: ['babel-preset-expo'],
env: {
production: {
plugins: [
[
'babel-plugin-jsx-remove-data-test-id',
{ attributes: 'accessibilityLabel' },
],
],
},
},
};
};


Let’s write our first test script now:

I’ve created a called LoginTest.spec.js inside a new folder called e2e. Inside the file you can find the following:

// myapp/e2e/LoginTest.spec.js
import wdio from 'webdriverio';
jasmine.DEFAULT_TIMEOUT_INTERVAL = 60000;
const opts = {
path: '/wd/hub/',
port: 4723,
capabilities: {
platformName: 'android',
deviceName: 'emulator-5554',
app: 'my-app-name.apk',
automationName: 'UiAutomator2',
},
};
describe('Expo test example', function() {
let client;
beforeAll(async function() {
client = await wdio.remote(opts);
await client.pause(3000);
const pack = await client.getCurrentPackage();
const activity = await client.getCurrentActivity();
await client.closeApp();
await client.startActivity(pack, activity); //Reload to force update
await client.pause(3000);
});
afterAll(async function() {
await client.deleteSession();
});
it('should allow us to input username', async function() {
// Arrange
const field = await client.$('~username');
const visible = await field.isDisplayed();
// Act
await field.addValue('testUsername');
// Assert
expect(visible).toBeTruthy();
expect(await field.getText()).toEqual('testUsername');
});
});


That may be a lot of new code to digest at once, so let’s go line by line:

import wdio from 'webdriverio';


First, we import the WebdriverIO client. This is the main package that will include the functionality we need to query elements from the react app and simulate events on the emulator.

jasmine.DEFAULT_TIMEOUT_INTERVAL = 60000;


This will tell our test runner (in this case jest) to make the tests error after a certain number of ms have passed. Here we’re setting it explicitly in the test, but if you’re using jest you can modify the testTimeout property on your jest configuration. If you’re using any other test runner, I’d recommend going through their documentation, most of them have a similar property.

const opts = {
path: '/wd/hub/',
port: 4723,
capabilities: {
platformName: 'android',
deviceName: 'emulator-5554',
app: 'my-app-name.apk',
automationName: 'UiAutomator2',
},
};


These are the configurations for our driver to know what to look for when using the appium interface to query and save elements.

You can get the device name going on your emulator > help > about

In order to generate an app from expo, you have to run the command:

expo build:android


And wait in the queue for it to build.

In this case, I placed the downloaded apk in the root folder for my project, and renamed it my-app-name.apk.

Since we’re using WebdriverIO, the automationName will be UiAutomator2, as that’s how appium recognizes it.

Since lines 18-33 are mostly about setup, we won’t focus on that for now. The next part focuses on line 34 and forward.

Writing the actual test

The idea of this test is just to showcase a normal flow on a test, therefore we will be dealing with a fairly simple use case: Checking that we have a valid username input:

const field = await client.$('~username');
const visible = await field.isDisplayed();


The first line allows us to query an item by accesibilityLabel. As I have previously mentioned, for more information about specific selectors go to the WebdriverIO documentation.

The second line checks whether our previously selected item is visible on the current screen, more information here.

await field.addValue('testUsername');


This line simulates user typing into the selected field. In this case, we’re inserting the ‘testUsername’ text inside the previously selected username field:

expect(visible).toBeTruthy();
expect(await field.getText()).toEqual('testUsername');


Lastly, we use Jest to check that the field is indeed visible on our Login Screen, and that the text on the given username field is the same as the one we wrote in it.

Running the test

Since we’re using Jest as our test runner on our React Native app, I’ve set up a command on my package.json to run the appium server and to run Jest in watch mode at the same time. It looks like this:

Here we’re using concurrently, a simple npm package that allows us to run several npm scripts at the same time. In this case we run the appium server and jest in watch mode, add their names and different colors to easily recognize them in the console, and pass the standard input to the jest command. This way we can narrow down our tests or do things like run coverage reports.

With this done, we simply have to run npm run test:e2e on our console, and expect something like this:

to be run, and something like this:

to be the output. If so, congratulations, you’ve correctly set up your integration tests for your react native app.

Wrapping up

While we’re far away from calling it a day on our e2e react app testing solution, the main automation testing setup it’s done. Next steps include integrating it with a CI/CD pipeline and making it work on IOS platforms.

Further Reading
https://webdriver.io/
https://discuss.appium.io/
http://appium.io/

The times they are a-changin' at Kaizen Softworks. We have a new CEO at our company: Bruno Bologna. Bruno brings more than 10 years of experience in the IT industry, having roles under his belt from client support, sales, business analysis, process improvement, to a software developer, technical leader, and software architect.Since his incorporation to our company in December 2015, he has been playing a key role in the direction of Kaizen. He is a member of the Board since then and has been involved with several projects. Starting his career at Kaizen as Software Developer, with roles of Architect and Tech Leader, he has evolved during the last 3 years to a role where he is more actively engaged in the general direction of the company. With a great interest in people & process, he has been a key player in suggesting, implementing, and developing new and better ways of running the firm, in line with our continuous improvement motto.

The decision of passing the direction to a new CEO comes from both of our founders, Fabian Fernandez (former CEO), and Rolando Larrainci (former CTO), who will be leaving their executive roles in January 2020, engaging only at the Board Member level to collaborate with Bruno with the strategic vision and direction of the company. This movement will allow our founders to focus more on the general picture and not in the daily operations of the company, gaining time to develop new ventures and pursue new dreams.The change is bringing great news to everyone involved as the reorganization is generating new roles and allowing people to grow in their career paths taking new and more challenging responsibilities as the ones executed once by Fabian and Rolando are being appropriately delegated into our new CEO, Bruno, and new roles like Account Managers, People Care, Client Care, and Sales Manager, among others.

2019 has been a great year of growth at Kaizen along with several hours of continuous work on how to best proceed with the transition to our new CEO. He will have a challenging 2020 where one of the main objectives is to implement OKRs (Objectives and Key Results) at the company and team levels. Bruno has been studying OKRs all along 2019, thinking about how to best implement this process at Kaizen. Together with our founders, they have come to the following company-wide OKRs.

2020 OKRs

Company-wide objective: Mature and grow in this new stage, promoting our values in the process.Objectives:

• Prioritize professional growth and increase satisfaction while maintaining retention.
• Carry out the reorganization promoting and reviewing culture and values within Kaizen.
• Increase revenue, maintain the profit margin.
• Exert a positive influence on the client beyond the limits of each project (Driven by passion we provide ever-improving software engineering services).

Here's John Doerr on OKRs: https://youtu.be/L4N1q4RNi9IWe look forward to the success of Bruno as CEO at Kaizen and to keep the continuous improvement our founders have promoted since day one. Cheers! You can get in touch with Bruno on LinkedIn if you want to continue the conversation.

2019 Kaizen's End of the Year Party

It's December 1st and Kaizen is 5 years old now since it all started back in 2014. As every year, we celebrate by engaging with the whole team and their families renting a big house with a pool and bar for a full week. Check how much fun we had in this post!

During December of 2019, we rented a house in Punta del Este, one of the most beautiful tourist spots in Uruguay, especially during Summer. It was a great week where part of the team spent the weekdays at the house working and having fun. Then by the weekend, the whole team gathered at the house to spend all day Saturday having an asado, drinking and laughing.

As every year, we had the "Kaizen Awards", a fun way of celebrating the things that happened in our company during the year.

While eating and drinking with our family and friends, we had a ton of fun playing ping-pong, playing board games, tennis-football, and swimming in the pool!

See you next year!

Team collaboration is key to develop quality software. While we work most of the time from our Delivery Center to deliver software applying agile methodologies, having the chance to meet in person with our clients to collaborate, work on details, and reduce ramp-up time, usually at the beginning of the project, is highly valuable for everyone involved.

During 2019 our team traveled 4 times to meet with customers based in Boston, MA and Buffalo, NY. SmartBorder, Blueport, and SmartSense are some of them. You can learn about their feedback in our success cases section.

Usually, these trips take 1 week where we visit the client, have several meetings, work side by side, adjust details, and of course have some fun outside the office to build a great and trusting relationship.

For small to mid-size companies, hiring a software development firm to help with your IT needs is essential to its success today. There are more than 500,000 software development and IT services companies in the U.S. alone, so how do you know who to hire?

For the firms that have entrusted us with this responsibility, we are grateful for them and proud of the success they have achieved using our services.

Our clients recently left us great feedback on Clutch, a ratings and reviews platform headquartered in Washington, D.C. This has allowed us to be named amongst the top software developers.

We recently worked with a Learning Solutions company to update its education platform, building its eighth and most recent version. We integrated it with email notifications and dashboard plugins, and we continue to provide maintenance.

In the 5-star review, the Director said:

“Potential clients are amazed at the platform’s functionality and the way it’s built.”

This is something that all of our clients can expect if they choose to work with us. Client satisfaction and feedback are very important to us.

Another example of a satisfied client is SmartBorder, an import/export software company in Buffalo, New York. We worked on a multi-year project, upgrading and developing its main platform. The SmartBorder Director of Technology, Ron Barone, in this 5-star review, said:

“They’re hungry programmers that do a really good job.”

You can expect this type of commitment in terms of quality and quantity if you choose to partner with KAIZEN Softworks for your next project.

“Customer feedback is very important to Kaizen Softworks. It's one of the main tools that allows our company to continually improve and provide better services for our customers. Services like Clutch help us gather this feedback, and it has been a great source of validation for potential customers, too.” – Kaizen Softworks former CEO and Co-Founder Fabian Fernandez

How can we help you achieve your business goals?

GET IN TOUCH

In a dynamic world driven by mobile technology, the demand for exceptional mobile app developers has never been higher. In this context, Kaizen Softworks has been recognized as top mobile app developers in the United States during Clutch's 2018 research.

Kaizen Softworks Team Members Shine as Top Mobile App Developers

Clutch's research team, led by Business Analyst Sara Philibotte, scoured the mobile app development landscape to uncover the industry's top talents.  The rigorous selection process took into account a myriad of factors, including the quality of client feedback, the range of service offerings, the richness of the portfolio, and the overall market presence of the contenders.

Out of a pool of more than 640 companies, Kaizen Softworks stood out as a true mobile app development powerhouse.

Sara Philibotte, the Business Analyst behind the research, emphasized the exceptional qualities that set Kaizen Softworks apart from the competition.  She noted: 'These app developers have risen to the top of our research rankings due to their phenomenal dedication to their clients and their mobile app development prowess'.

This recognition serves as an inspiration to aspiring developers and a testament to the tremendous potential of the Nearshore mobile app development industry.

A Glimpse into the Future

Our dedication to providing exceptional services, tailored to meet our partners' specific needs, is to none. The Clutch recognition is not just a culmination of our efforts; it's a harbinger of even greater achievements on the horizon.

As we continue to set new standards in the industry, we anticipate an even brighter future for our exceptional mobile app developers.