Or: how our product focused company works
Experience has taught us that the biggest risk of any project is developing the wrong thing. Being a product focused company, we prevent this by first understanding what the project needs. Only then do we choose the best tool for that job, based on requirements and dependencies.
As a result, our clients save money, because they won’t spend it on unnecessary subsystems.
This is especially important in the startup world, where everything is dynamic and resources are limited.
Even if the most efficient solution involves a coding language we’re not familiar with, learning it comes easy for us. Once you’ve worked with 5 web frameworks, you just breeze through the 6th one.
This is possible because our team members are CTO-level engineers, with a broad technical background.
Why do our clients choose this approach and don’t mind paying for our learning curve?
We deliver value quickly
This is our rule of thumb for every project we take on: focus on the most pressing business need, solve it, move to the next one.
One of our clients, LoyalSnap, uses Ruby as a framework. We weren’t familiar with it at first, so Gavin, the CEO, didn’t feel comfortable with us working on it. But they had outstanding bugs that needed to be solved by yesterday.
Sometimes people use the wrong shortcuts, because they want something that is “yes/no”, rather than qualitative. It’s a lot harder to answer the question “Do I think these guys can learn Ruby quickly?” versus “Are they Ruby experts?” Even if that isn’t the right question to ask.
— Gavin Apter, CEO at LoyalSnap, USA
Catalin decided to take matters into his own hands and jumped right into it. One of the issues was that batch emails were getting triggered twice and some of the service’s users were receiving duplicates.
After a quick look through the code, he was able to successfully remove the subsystem that was causing the second copy of the e-mail to be sent. The scope of our work increased as a result, because this first delivery convinced him that we could handle new tech on the go:
What I’ve learned since then is that overall attitude and intelligence is more important than familiarity with a specific language.
— Gavin Apter, CEO at LoyalSnap, USA
The hard part, for an existing project you’re picking up, is not figuring out what the code does. It’s why it does that, from a business standpoint.
We think like entrepreneurs
We speak the client’s language. We understand their needs. And we’ll call them out when we think they’re building the wrong thing. This is one of the ways we always attempt to keep their Total Cost of Ownership low.
For example, we were requested to build an app for an UK based business. We advised them to set up a YouTube channel instead, since it would’ve allowed them to test their idea more easily than an important upfront investment in development. Like they told us, that’s not profitable on our end, but our main drive is for your business to succeed.
We don’t believe in taking your money for something you don’t need.
Only after understanding both A (the project’s starting point) and B (the project’s goal), can we decide on the milestones leading up to B and the tools necessary for the journey. The resulting roadmap allows both us and the client know exactly where we stand, at any given time.
PopAds approached us to build a high-performance proxy. We suggested to build a load testing tool first, so we could understand its problems and traffic patterns better. As a result we got plenty of insight about what we had to do, which streamlined the project. All for a fraction of the cost of the proxy.
Your business is our business, which is why we want you to succeed.
We Cross Pollinate
On the client side, we minimize our learning cost through something Andrei calls Cross Pollination. The tech we learn on one project can be used on another and vice-versa.
One of the best examples is the Docker hosting ecosystem. We first picked it up working for an ops contract, where we used it to unify the three hosting services they were using.
Since then we’ve also used it to easily set up and manage Rancher as a Docker container for another app we’re developing with the Polytechnics University of Bucharest.
Now we’re implementing it for NRGI, where we hardened some production systems. We increased uptime and simplified the infrastructure, creating a continuous delivery pipeline based on Docker.
This is another reason for which our Total Cost of Ownership is lower: all clients financially contribute to our learning. They split the costs, but get the benefits of what we learn on all projects.
We don’t get to specialize in every technology or language we work with. But on the other hand, we get real results a lot faster. Because we’re focused on what our clients needs.
At the end of the day, clients don’t pay for what you know. They pay for what you deliver.
And that’s why we do our job. That’s how we get that job done.