A first-person account of how Founder and Entrepreneur Adil Kurt-Eli found the right technical partner for his startup.
I want to start by saying that I’m not a tech person. I qualified as a lawyer on the other side of the millennium, so I’m also older than your stereotypical startup founder.
I started my career at Linklaters, one of the major law firms in London. I then moved to one of the big global banks, HSBC, and never looked back to law. My banking career started in 2005 and ended in 2019.
During that time, I learned a lot about pain points in the industry, many of which are hidden pain points.
Something else I also learned in that time was how to improve those pain points.
That was the catalyst for me leaving the industry and jumping into the startup world with my company, Synch.
Synch: Idea & MVP
My banking experience lies in what’s known as fixed income markets or bond markets.
To give you some context, the bond market is about four times bigger than the equity market globally. The key difference is that no one outside the industry pays much attention to the bond market.
That was my world. What we found was that because there was no limelight on the bond market ecosystem, it wasn’t particularly well serviced from a technical point of view.
Of course, you have your go-to solutions like a Bloomberg Terminal for data. You have some trading solutions, fixed income data sourcing and exchanges. The process, however, is very manual.
Our aspiration with Synch was to intervene in that market. We wanted to effectively strip out a huge amount of the inefficiency.
How do we go about that? To start, we looked at the data itself.
The data is very expensive to get a hold of from these pre-packaged sources. It’s embedded in systems where you’re not using 98% of the functionality but you have no choice but to buy the whole system.
Secondly, those systems are built on legacy architecture. What you have to do is manually intervene with the data sets to recalibrate them to make them usable.
Let me give you a simple example of this. We would create an automated data feed from a terminal into an excel spreadsheet to create a chart to pull that into a presentation that I transform into a PDF to email to my client.
Just to do that operation is hours of work for the analysts. We were finding that we were spending around 80% of our time on data and, more than that, a ridiculous amount of our budget on sourcing that data.
With Synch, we’ve built a platform that automatically executes all of those manual interventions that you would have to do with the legacy systems. All of this is embedded in what we call “one-click technology”.
The simple idea is: I care to look at something, I click a button and I can see it all rendered for me in every format I need to.
Our overall goal is to give users a new, three-dimensional, contextualized view of financial markets at all times.
We had the industry experience to pull this off, what we didn’t have in the beginning was the technical stakeholder to execute it.
Should you Hire a CTO, Build a Development Team or Software Development Company?
Thanks to my experience, I’m lucky to have some good connectivity within various parts of the marketplace.
We didn’t have what I would describe as a traditional CTO from day one.
At the outset, there were three of us which subsequently rose to four. Two of my co-founders are market and banking experts with a complementary background to mine.
The other is a giant of the technology industry who is too experienced to be day-to-day developing a platform like ours but is fully engaged in everything technical that we do. He’s a “CTO advisor”. He’s a technical savant in this space.
But, the reality of it is, you still need to do the work. You need to get into coding as well as the scripting and structuring of everything.
In our case, we’ve got hugely complicated data sets coming in and a huge amount of acrobatics that we do with said data in the cloud.
That is not a one-person job. More than that, to find the right person to do all of that is a complete lottery. If you don’t get the right individual into your business you’ve got a blockage to actually delivering a system.
As a non-technical person, it’s vital you don’t jump into bed with someone just because they say they’re a technical co-founder. Candidly, you’re not skilled enough to know whether or not that person can deliver.
For us, a technical partner in the form of a software development company was actually more valuable.
My founding team and I have close to 100 years of business experience between us. When we had the debate it was very much around recognizing the complexity of what we were about to build. I think it’s very important for people to be realistic about this.
It’s very easy to look up no-code solutions. Or to find somebody who’s come from an engineering background, built their fantastic “flappy bird” app and has seen success.
But the reality of it is that that person is either very highly skilled or the system they’ve built isn’t that complex.
When you start to get into a super complex product – large volumes of data, a data cluster infrastructure, the right UX/UI interfacing for operational efficiency, etc. – it doesn’t take a rocket scientist to figure out that you have two choices. You either:
- Hire a team of five to ten people, hope you’ve got it right and try to manage them;
- Or you go to a team of people who do this kind of work every day.
So we said to ourselves, let’s go and find the best of breed software development companies who do this all the time.
Let’s figure out if they can help us build what we do. Let’s have them join us as a partner in this journey.
We took a community approach to build this product. We wanted to find people who were enthusiastic, engaged and ready to embrace the technical challenge that we were throwing out there. And it was a massive technical challenge.
When you think of it like that it becomes an easy decision but a huge amount of thought went into it.
At the early stage of your startup process, you’re at a fork in the road in terms of how you actually develop the product.
I’ve seen it done both ways and, from personal experience, you’re more likely to get a successful team on day one by going with a software development company, with a team of people who do this work on a daily basis.
Yes, we’re pushing the envelope with what we’re building, it’s very much not a “plug-and-play” system. That being said, if you are building something objectively less complex, like a marketplace or social media app, the same logic applies in my opinion.
Experienced software development companies will have muscle memory from having built similar products. Meaning, they’ve experienced the common hurdles already. They can predict when they’re going to happen.
They can use some of the tools and experience to preempt and diffuse the bomb before it’s even planted. The result is that your efficiency goes up and your cost of development comes down.
Regardless of what you’re building, I would recommend finding such a team. Then, once that code has been developed properly, eventually, you can pull it in-house with your own team operating and maintaining the codebase.
Our next step after deciding to build our startup with a software development company was to define the process to find the right team for the job.
Expert Tip
“What you do is you build the first version of your product and build a community around your idea. This not only shows off your marketing skills, it proves you’re not just an idea person but you can actually sell and market the product.
To build the product itself, you’re going to want to go with an agency or a team of freelance developers.
This is the fastest way to actually get your idea into the market so that you can get traction and essentially de-risk the opportunity for a potential technical co-founder or CTO.
By showing them you’re more than just an idea person, you change the conversation from “I need you!” to “Here’s a great opportunity!”
Nelly Yusupova, CTO & Startup Advisor
The Process to Find the Right Fit
The first thing we did was trawl search engines looking for developers. We asked people who’d had experiences with software development companies their opinions – good, bad and indifferent.
It’s really important to understand people’s experiences and why. I compare it to Amazon reviews.
Don’t always look at the good reviews, look at the mediocre reviews. They’re by far the most important because it’s typically someone who’s said: “The product worked well in this way but in other aspects, it could’ve been improved by doing this.” Usually, one-star reviews have nothing to do with the product itself so there’s no point looking at them. As for the five-star reviews – well it’s easy to be happy when a process goes perfectly.
By looking at the mediocre reviews you see how the company you’re speaking with deals with problems. It’s something I refer to as “BlackBox theory”. Meaning, when something catastrophic happens you don’t waste time assigning blame, you look at the BlackBox recording to identify what went wrong and how you resolve it and prevent it from ever happening again.
It meant that if we see that something has arisen from a mediocre review, we can also see what they’ve done to resolve that and the trend patterns. If a company has a lot of mediocre reviews and it’s consistently the same feedback over a six month period it tells you that they’ve not addressed their mistakes. So you don’t go near that company.
Conversely, if you see a mediocre review and then someone else six months on has left a review saying: “Yes we encountered this problem as well, but it was handled in a brilliant way.” You now have full visibility and context.
It takes a lot of work and time from you, the founder, to work this out. There are platforms like Clutch that can help you gather this information, but you need to put in the effort to find it.
We spent a lot of time looking at that middle ground to understand where the balance was in terms of their experience. We identified around 100 potential partners globally using this initial process.
We quickly whittled that list down to around 20 that we thought fit the Venn diagram of what we were looking for which was:
- Domain expertise in what we do;
- Technical expertise in terms of building bigger, complex systems;
- And most importantly for us, user-friendliness – the capacity for us to engage with the software development company and communicate freely and openly.
There are lots of very talented agencies out there in terms of technical expertise – raw coding ability. But the relationship with a software development company is more than just the ability to code what you ask for. It’s about them joining you as a partner and challenging your vision to create a better technical outcome for your product.
This became abundantly clear to me and my team when we were looking at the final 20 candidates.
We had email communication with them and then selected the top five of those to go on a call and have a deep dive/interview with.
When you get into those conversations you can also refer back to the mediocre reviews. You can challenge them and ask them how they went about solving the problems that arose and get even more context.
From that, we shortlisted two agencies and had further discussions with them. From those discussions, we selected our winner.
And it was a clear win for us with the team we chose. They perfectly fit our Venn diagram but, more than that, we were given the opportunity to speak to their clients and play with some of the systems that they had already built.
This was a crucial part of the process and you shouldn’t be scared of asking your candidates if you can do exactly the same thing.
It was an extra layer in our due diligence process that confirmed Altar.io understood our vision and was capable of helping us execute it.
It’s important to highlight that this process takes time. In our case, it probably frustrated some of the companies we spoke with. But the time you take on this process means the difference between just making a choice and making the right choice.
The other key factor is to not just find a company that is technically capable. You should also look for a team that has expertise in product development.
The Importance of a Product-Centric Software Development Company
For us, the product-centricity of the agency we worked with was as important as coding ability.
Our product is an enterprise-grade product. It’s not a SaaS or free app. Our user groups are investment banks, asset managers, etc.
We couldn’t afford to build a deficient system. The importance of that user journey, which also dictates the level of habituation the person will have on the system, required us to not only stretch ourselves from a product standpoint.
We also needed someone to challenge us from that standpoint.
As a founding team, you will have strong views on what you would like to see – just like my founding team and I did.
Those views will not always be realistic in terms of where technology will take you. More than that, those views will not always align with the latest user experience psychology.
My team and I are not experts in either of those areas. Having a team that has that product knowledge is invaluable.
They will be able to say to you: “The idea you have is good, you could optimise it even further by doing this.” Or: “Actually you don’t want to go down that particular path because it constrains what you can do as the next level of the user experience.”
When you have a platform where your users will journey from one facet to the next in succession, often in multiple directions based on their decisions you need to plan ahead. You need to look at that flow and work out how to make it efficient for the user.
It will lead you to wireframing exercises and importantly, it will make you consider the infrastructure that backs it. It’s very easy for a non-technical person to ignore the backend. We look at the frontend and we think ok the computer will handle the backend.
It won’t, you need to tell the computer what to do. The way we accomplished this was to describe the user journey to the team. The team interpreted that and then we worked on an iterative process to reach our goals.
Through that, you’ll learn things about the design which will blow your mind, trust me. It will also allow you to recalibrate where your next module will go.
For us, it’s resulted in our users telling us that they’ve got a unique experience using our product. Which is the outcome we wanted when we first set out on our product journey.
Now let me share my experience onboarding the chosen software development company. Onboarding a Software Development Company
If you’ve done your due diligence well, there is no reason not to have a smooth onboarding process.
For example, when we onboarded Altar.io, we’d already been in dialogue with them for quite some time. We knew what we wanted and how we wanted to go about it.
The key for us was setting clear parameters around our expectations in a very upfront manner.
The risk you will have here is wanting to be too engaged with the company you’re working with when you start out. It’s certainly something we faced. There’s a lot to be said for letting them get on with it – as natural as it is to want to be as hands-on as possible.
You have to be aware that at this point your product becomes a collaborative process. You’ll reach a point of trust where your team and theirs will become fully integrated – provided you picked the right people.
This will allow you to be more effective when prioritizing decision making and problem resolution.
The challenge you’ll face is not getting carried away as you move into the build itself and getting under the feet of your tech agency.
This leads me to how you should manage the relationship with your partner.
Managing the Relationship with a Software Development Company
As a founder, I like to be involved in things – probably to the point that it oversteps. If this sounds familiar to you be aware that this may prevent your technical partner from getting on with the job at hand.
For you, the founder, this will be a learning experience. We entrepreneurs tend to be quite curious by nature. This led me to get into the weeds on things I probably didn’t need to focus on.
Things like learning about the technical systems we were using. Getting into the database and PostGre sequences, etc. All of these things have nothing to do with what I should be focusing on.
My advice? Don’t let your curiosity get the best of you in this process.
In terms of rituals and rhythms, it’s important to find a process that works for you and the agency you’re working with.
We started out with a twice-weekly “point of situation” with our team at Altar.io. This was enough for us to stay hands-on while giving the team enough time to actually do the work.
We created various chat channels in order to escalate quick issues. If they wanted to ask a time-sensitive question or vice-versa we could. Occasionally you can go old-school and just call them – it still works.
Importantly we’ve also been running several process-management tools in the background, like Confluence. Doing this will allow you to monitor the progress of the build as it goes on.
It also means that when you inevitably hit hurdles – which you always will when bringing a new product to life – you can use these tools to see what the knock-on effect of that hurdle will be.
For example, the team at Altar.io implemented a very good ticket writing process. Meaning we could clearly see the dependencies between certain events.
That means, if a problem occurs and needs more time to resolve, we’re able to see what happens to other elements of the product. This has allowed both parties to prioritize our resources to be as effective as possible.
In our case, we’ve had a product management team as well as a technical team. That product management team has served as a translation service between what’s going on in our heads as a founding team and what the developers need to do to make that happen.
The Pitfalls of Working with a Software Development Company
When you outsource you need to be realistic about a couple of things. Firstly, you’re not the only client of the agency. They give you access to a team, you know who you’re dealing with. You have your “front office” people with whom you interact and your “back office” team of developers.
Invariably there will be times when other projects the agency is working on will need more resources and this may affect your project. Just like your project may at points affect other projects the agency is working on.
The second, and much more tangible pitfall is expectation management.
When you outsource you’re working on a budget plan and to the costings of someone else’s company. It’s someone else’s business.
As a founder, you have to realise that while you’re the most important person in your world, in reality, every other person you deal with is running their own business.
They have the same pressures and stresses in their business as you do in yours.
You have to be cognizant of being efficient with the agencies time and being timely with payments.
You have to be aware of the fact that if you decide you want to repaint a wall, you might have to consider buying a can of paint.
By this, I mean an awareness that every time you nudge something in a slightly different direction one of two things will happen. One, the agency will be very charitable and do it for you (at which point you should be super grateful). Or two, you’re prepared to say to them: “guys you’ve gone above and beyond, we should have a conversation about what we can do to make up ground here”.
For all of these pitfalls I’ve mentioned, the reality is that you can offset all of them. If you’re working with the right team your dialogue is so open that these pitfalls don’t come to light after the event. They come to light during or often before it happens.
Meaning you can mitigate them together, rather than dealing with them after the fact. That’s really important when things are fragile at both ends – which they always are. As a startup, you only have so much budget. As a development company, you only have so much human capital.
And that’s what you’re buying at the end of the day, human capital, which is never unlimited. You need to be realistic in terms of your expectations surrounding that.
We’ve been really lucky in what I would describe as the deep relationships that we’ve formed with everyone we’ve spoken with at Altar.io along the journey. It feels like the team at Altar is part of our family to the point that when we get a phone call saying that someone has a new project and needs to be redeployed we respond with “No! They can’t! What can we do to retain them?” Which is crazy! They’re not even our staff and we might not even need their particular skill for the next module!
This goes back to what I mean when I say you’ve got to find the right agency. It’s more than just a transactional relationship, it’s a journey you take together.
The Added Benefits of Working with a Software Development Company
The main benefit of working with an agency, aside from what I’ve mentioned already, is you’re tapping into a diverse team with a wealth of experience across several departments and industries.
We’ve had conversations with the team at Altar from marketing through to where we can take our business in the future. None of this translates to contracting more coding work. It’s just about having that business conversation. Sharing views about trend patterns within the market. That allows us to test opportunities in a forum that is a safe environment.
What’s cool about that is that it allows us to test our theory as to whether or not it’s an opportunity for a tech intervention or not. It may be that the tech may not be ready to go where our heads are, we can discover that and prioritize our roadmap.
It’s a hidden bonus of a great outsourcing relationship. With the right team, it almost doesn’t feel like outsourcing. It’s like you both have a foot in each other’s camp. You have these water cooler, coffee break moments where you can talk about these broader topics, just like you would with your own colleagues.
How to Measure a Successful Relationship with a Software Development Company
Real success is about the joint ownership of the outcome of your product.
It’s about you coming away from the experience with a product that you’re proud of. It’s about the agency feeling proud that they’ve delivered an amazing product to you.
That is a successful relationship.
At each milestone, you should be able to look back knowing you’ve achieved something better than you expected.
That’s how we measured the relationship with Altar.io and you should do the same.
Things like adoption rates and revenue don’t come into play when measuring a successful startup-agency relationship. That comes because you have the right product.
The success you should measure here is coming away with a product that will allow you to do that.
Wrapping Up
The most valuable thing about finding the right development partner is finding a team of people who can genuinely add more value to your startup than simply executing what you ask them to. It takes your product to a whole new level.
As I mentioned before, we could’ve gone with any number of agencies to simply execute the code. There are hundreds of teams that will do that for you.
But, in doing that, we wouldn’t have got a product with a “wow factor” for our users.
It’s the challenging product and user experience conversations that will lead to a product that far exceeds your original vision and scope. It will simply be built in a better way.
To find a partner like that you need to do your groundwork.
Go to review sites, forums, talk to other founders – learn from other peoples experiences.
Don’t be afraid to go through two or three rounds of interviews with agencies. The ones who get frustrated with that process will tell you a lot about what will happen when you get into a difficult situation further down the line.
It’s a two-way process. They’re deciding whether or not you have a product they want to build. You’re deciding whether or not they’re up to the challenge you’re presenting them with.
I’ll leave you with the single best piece of advice someone could’ve given me at the start of my process – and it’s the best piece of advice I can give you.
A good software development company isn’t simply about coding, it’s about product outcome. Really think hard about the decision to ensure you find a team that can add real value to your product.
Also Published Here