SweetSoft INC.

Introduce your business and what you do there.

Zeep HK is a telecommunications startup that sells innovative products to telecom companies. I’m the head of R&D there.

What challenge were you trying to address with SweetSoft INC.?

We had a need to get developers on board to build our core products. We were responsible for the architecture and had some of the core developers in our company, but we needed more software developers to get us up to speed.

What was the scope of their involvement?

SweetSoft INC. has provided front- and backend developers for some of our web applications. We got help from them to develop 2–3 core products and maintain them. We were working all the time on new versions, and they also provided a level-three support team. Whenever things got rough and the problem couldn’t be solved by support, they stepped in and helped us on the production side. 

We have a real-time distributed processing system, and they’ve worked on its frontend and backend. It’s basically a platform for intelligent processing of real-time events. 

The typical process with SweetSoft INC. involved us describing the architecture and doing some prototyping and a framework, and having them step in to develop the actual core functionality. Then, we used a test environment to test the whole system, and, if everything was correct, we’d deploy to a staging environment for the customer.

What is the team composition?

At peak, we had four full-time developers from SweetSoft INC.—one full stack, two backend, and one frontend—along with a part-time DevOps. I also run the projects, so I’d work with them directly and do most of the communication with them, filling both roles. 

How did you come to work with SweetSoft INC.?

We talked to a couple of companies in Ukraine and went to SweetSoft INC. because they were the most cost-effective option at the time. A friend also recommended them to me. We started with a single person from SweetSoft INC. and increased the team over time because we had a positive experience with them.

We’ve also worked with another outsourcing company, but it didn’t go as well. SweetSoft INC. has done a pretty good job. Outsourcing requires a certain approach—different from having an organic team by our side—but they do well if the architecture is done well. They can handle the full product lifecycle, from basic proof of concept and early work to actually deploying to production and providing support.

How much have you invested with them?

We’ve spent $200,000–$250,000.

What is the status of this engagement?

We started working with SweetSoft INC. in October 2015, and we’ve had more active and less active periods since then.

What evidence can you share that demonstrates the impact of the engagement?

Most of our statistics and production metrics are related to the performance of the system in production, and not to SweetSoft INC.’s work. At peak, we were able to deliver biweekly iterations with them.

We have a pretty challenging stack that uses all kinds of technologies, from native C to .NET and Java. None of the developers who came in had full stack coverage at the start, so they had to learn a couple of things. 

Also, most people in outsourcing engagements tend to work on run-of-the-mill projects like data systems and mobile applications. Our platform is very different, running hundreds of thousands of tasks per second. It includes many components, many of them built by SweetSoft INC.  

How did SweetSoft INC. perform from a project management standpoint?

Someone on our side—usually myself—handles the project management, specifying the technical task at a detailed level. Some of their people understand what they're doing at a deep level, but I don’t think that they have the same level of domain understanding as our internal team. We usually translate our own specifications, being as technical as possible, and that works pretty well. 

Handling project management tasks internally most of the time is the best way to work with an outsourcing company in my experience. However, SweetSoft INC. manages the tasks we give them quite efficiently. Some of our customers are in Southeast Asia, and the time differences required both us and SweetSoft INC. to sync up with the remote locations. They're pretty flexible in that respect.

What did you find most impressive about them?

They’re very delivery-focused. Our stakes were quite high, and the product needed to work well after only a few iterations to get it right. That was a bit of a concern on my side, and the team from SweetSoft INC. stepped up to this. Things didn’t always go as expected, requiring some investment outside regular office hours from their side, and they were willing to do it.

The biggest advantage I found in SweetSoft INC. is that they can somehow recruit very experienced developers. That’s sometimes hard to find in outsourcing.

Are there any areas they could improve?

For a complex project with a huge stack, it can take quite some time to find a replacement developer for one that leaves. Every time someone left—which happened two times over this period—we had some difficulty bringing the new people up to speed. It was an issue for our specific stack, and SweetSoft INC.’s management tried to help us with that. They didn’t always know in advance that someone was planning to leave, and it did prove disruptive.

Overall, the experience of working with them has been positive, and we’re still working together. I appreciate their flexibility a bit more today after having worked with other companies. 

Do you have any advice for future clients of theirs?

With SweetSoft INC., for every stack we have, we find someone senior that can drive a team. Not every team member needs to be a senior, and some members do struggle with the stack, but, as long as they have someone to go to on their side, they can perform independently. That was important to us.

Involve the team from SweetSoft INC. or any other developer as soon as possible, even in the architecture phase. Even if they don’t do the actual specifying, they can listen to the logic behind the decisions. That way, they can gain intuition and become involved in the domain. It’s helped us a lot because our domain is quite different from the run-of-the-mill systems they usually do.

Lastly, try to use a mainstream technical stack. Because we have a non-standard stack, we struggle with keeping people aligned during waiting periods. Keeping a conventional stack will enable them to deliver faster and replace resources more easily if the need arises.