The Hidden Realities of Building SaaS Features

So, you’ve got a fantastic idea for a feature that will improve your business and make your life easier. You’re convinced it’s a game-changer, and you’re ready to start development. 

But hold on!

Before you start drafting code and assembling a team of developers, there are some crucial insights you need to consider.

In this interview, I sit down with Finqle’s software development experts.  

• Mike van Egmond; our co-founder and CTO
• Farzad Ghanei; our Technical Lead, and 
• Jelle van Wijhe; our Technical Product Owner

They have walked this path and provided profound insights into their experiences, challenges, and key learnings from the journey of creating and evolving our SaaS products. 

By the end of this article, you’ll understand why outsourcing your software feature development may not be the best money-saving strategy for your company.

While building Finqle’s invoicing service in 2015, Mike van Egmond, our co-founder and CTO, realized that businesses like Temper needed a way to ensure faster payments for freelancers.

Many companies were building the exact parts that are necessary for securely processing payments between two – or more – parties

The need for our product came from risk management

Mike:

“Initially, we offered American Factoring services to companies. We wanted to improve our service by allowing real-time payouts to merchants while not overwhelming their clients with invoices. As we ventured into the temp industry, we observed that the nature of the invoicing business inherently carries a substantial amount of risk.

What happens if a client suddenly goes bankrupt? What if an invoice contains mistakes? Our clients kept coming to us, asking for additional features like KYC checks and credit note handling.

We realized that managing these risks was essential in our line of business. We needed a closed-loop system that covered everything – from invoicing to payments to risk management.”

Mike explains:

“You first figure out: what are the essentials that you have to build yourself and what do I need to outsource? And then, once you have these essentials, you start writing high-level user stories.

To prioritize, we looked at client needs, and risk factors, and then built our minimum viable product (MVP) within a month. This led to the development of one of our key products: Pay for Platforms, which incorporated diverse client needs. 

Every business should focus on its core function. If a platform or business brings together supply and demand, it shouldn’t concern itself with invoicing structures and the associated risks. That’s not a platform’s main business, right? The rule is: You generally don’t build something from scratch unless you have a really, really good reason to do that. 

For us, it was the same. Our core focus was – and is: Building invoicing flows buying these invoices and then doing the administrative tasks associated with them. 

So based on these decisions, you define what to outsource or what to develop yourself. “

Farzad adds:

“For the same reasons that partner companies can use our services, we also use a lot of services from vendors, service providers, for example. So we don’t need to manage our own hardware, because of that – We are abstracted away by all the challenges of that, and that, that somebody else is doing that job of keeping them updated. So we are using pretty much new technologies, which is a good thing. It helps us to go fast forward. 

Basically, for every software project that you want to do, whether it’s a Saas, or if it’s an end-user product, you have to follow the same process, it’s a generic process. And the decisions that we’ve come up with so far, are tailored towards having our tools and yeah, they made sense. The core service makes sense, the database makes sense because they provide data consistency and data integrity.”

Our CTO Mike knows firsthand that software development isn’t just about writing lines of code. It’s about comprehending the intricate web of technologies, frameworks, and dependencies that underpin your software: 

“While building a new system architecture you will always discover l more complexity than first meets the eye.”

Don’t beat Excel

Think before you build. This is what Jelle, our Technical Product owner knows like no other:

“Early on in my career, I worked with a developer who was a brilliant guy. He had two master’s and a Ph.D. in physics – you know, this kind of guy. And he had his own businesses too. 

I was talking to him about starting a new project. And he told me: whenever you think about a new project to start, first keep in mind: Don’t ever try to build anything an Excel sheet can do. 

By which he meant that if there’s already a tool there for doing the thing – and if you’re not offering anything more than an Excel sheet can do – there’s no real point in building it. And I feel like when it comes to building software it’s a little bit the same.

The Balancing Act: Speed vs. Stability

Entrepreneurs are eager to deliver features quickly to generate revenue. However, neglecting scalability, testing, and maintenance can lead to technical debt down the road.

Mike:

“Initially, we focused on delivering features and making money, which led to limited test coverage. As Finqle grew, we realized the importance of scalability and began refactoring and introducing tests. 

It’s a balancing act between speed and stability.

Developing software isn’t just a one-and-done task; it’s a continuous process. Neglecting scalability, testing, and maintenance can lead to technical debt down the road.”

And as Farzad jokes:

“A software project ends when the developer dies.”

So, what if maintenance is not prioritized? 

Mike:

“Modern software often relies on numerous dependencies, and when you build something new, there’s always a chance of unintended consequences.

Jelle:

“Let’s consider updating documentation as an example. When I first started, I needed to update some documentation, which seemed like a straightforward task. However, the third-party software we used for generating documentation had gone through several updates, and one of the software components it relied on was deprecated. So, a seemingly simple task turned into a day-long endeavor just to get things working again.

Farzad:

“Change management typically accounts for about 20% to 30% of the effort of a developer and is a well-recognized cost in the industry. However, this cost isn’t fixed; it fluctuates depending on various factors. Some months you may spend more time on it, while other times it’s less.”

Hidden costs

While it might seem cost-effective to handle development internally, hidden costs can quickly accumulate. This diversion of resources can impact your bottom line and hinder your business growth.

Mike:

“Consider this: the time your team spends on software development is time they’re not spending on your core business functions.”

Testing is an essential – but often underestimated – aspect of software development. It’s not just about writing code; it’s about ensuring that code works correctly, efficiently, and securely. 

Mike:

“Should we have incluced more tests? I think there are different phases that a company goes through.

1. The first phase is feature frenzy. At Finqle we were really bootstrapped. So we we did a lot with less, which means that, you know, when you’re small, you have two people working on something – you build, you build, you build. It’s, not just about the complexity, but it rather means that you don’t have a lot of test coverage. Eventually what you build can become a monster – because you’re just focusing on features and making money.
2. And then you go through the second phase where you need to make things more scalable, which means you need to start either refactoring, building something new, or conducting tests. The important thing to keep in mind is that when you change something, it’s almost certain that something else will break.

Unseen complexities can surface in unexpected ways and lead to time and resource costs – if maintenance is overlooked. In Jelle’s words: “So the unfortunate reality, I think, is that testing is just very labor intensive and time-consuming, both writing tests on the software level, the unit and integration tests, but also doing the actual testing. All of that takes a lot of time.” 

And like Mike was saying – that when you’re still small as a company, and you’re just three, four people sitting around one desk, everyone’s kind of got this cognitive idea of the software in their head. And once that starts to expand, and your team gets bigger and more people work on it, then that cognitive model in each person’s head isn’t enough anymore to anticipate the right kind of problems that you might be introducing with new features.

And suddenly these kinds of things start to become more important. And in that sense, yeah, in a perfect world, you would start with solid testing, both on the software level and the human level, from the beginning. But the reality is that in most cases, it’s very difficult to achieve because you have business and burndown charts staring you in the face.”

Mike:

“I’ve seen companies do solid and continuous testing, but then go bankrupt, because they didn’t make any money. Testing is essential, but it’s labor-intensive and time-consuming. It’s crucial to find the right balance for your specific situation.”

One of the most challenging aspects of SaaS development is balancing business goals with software quality. As a business owner, you want to move fast and make sales, but your developers need time to ensure the software is stable, secure, and scalable. The tension between speed and stability can be daunting.

Mike:

“Businesses want to move fast and make sales, while engineering needs time to ensure quality. Both sides, business and engineering, can become frustrated. 

Refactoring becomes necessary when the burden of maintaining the current system hinders progress. Outsourcing non-core functions and buying software can help alleviate this burden.

Jelle:

“It’s sometimes a challenge to build something in parallel with trying to meet your client’s needs. The more general you’re trying to be, the more dangerous it is to rely too heavily on what a single client says they want. 

Sometimes it’s a compromise in terms of trying to offer a decent alternative and sometimes you do just have to say no – because there’s just either no or: No, maybe later because it doesn’t make sense for the business at this time to spend the resources on that particular want.”

Mike:

“And quite often what we see is that there’s a reason to say no, because it shouldn’t be part of the software. And quite often, if you can explain that to your client, then eventually they come to the insight that it makes sense.”

Jelle:

“In my role as a product owner – clients request something – I often begin by asking why they need it. This helps uncover the underlying problem and ensures we’re addressing their true needs.”

Farzad:

“Every solution is a choice, and we want to help clients make informed choices. By focusing on problem statements rather than immediate solutions, we can explore multiple options, evaluate their pros and cons, and make the best decision.”

Farzad continues:

“As a more tangible example, consider a visit to the doctor. When you see a doctor, you should share your symptoms, and the doctor will diagnose your issue and prescribe appropriate medication. It’s analogous to the client-patient relationship in software development. As a developer, I don’t expect you to tell me which specific pill to provide; instead, you should describe your symptoms, and I will determine the best solution to help you.

Prioritizing features can be challenging, especially when clients have specific ideas in mind. However, it’s essential to communicate why a certain approach is not ideal for their long-term goals or our core business. Sometimes, they come to realize that their initial request might not be the best course of action.

As a developer, you want to find solutions quickly. However, to plan for the long term, we need to prioritize long-term goals over short-term solutions, which can be a learning process.”

Jelle:

“The saying ‘come to me with solutions, not with problems’ doesn’t apply to software development. Often, it’s better to start with problem statements to find the right solutions. Problems represent actual needs, while solutions can be idealized or based on incomplete information.

Mike:

“Effective communication is key to guiding clients toward the most suitable solutions and ensuring that our decisions align with our core business goals. It’s also about finding the right balance between meeting client needs and achieving our business objectives.”

It’s about saving money and time

You might still wonder, why outsource when you can build it yourself? Well, outsourcing isn’t just about saving money; it’s about saving time, avoiding pitfalls, and ensuring your feature’s success.

Mike:

“Hiring additional teams can work, but it comes with its own set of challenges. Maintaining knowledge in-house is critical. And that’s why it’s important to keep the focus on your core business. Instead of growing too horizontally.

We prefer to focus on what we do best: building invoicing flows and managing risk. It allows us to offer a robust and reliable service to our clients. That’s why, for some of our features we outsource as well, because we want to keep focussing on what is important for us: being the best invoicing architects.”

Farzad:

“If it’s not your core business you don’t want to build it. Because it’s basically a cost companies are paying to maintain a piece of software that isn’t necessarily their core business. It’s a peripheral, a utility, a supportive system they need for the core business.”

To draw a metaphor, Farzad likens this situation to choosing between using a car or taking a train for transportation. 

“A car offers convenience and control, but it comes with various costs like taxes, fuel, and parking. On the other hand, a train, like Software as a Service is shared among many users, spreading the cost. The main expense isn’t just the upfront development but the ongoing maintenance and operational costs, such as server maintenance and hardware.”

Jelle:

“Farzad was saying that the underlying unseen complexity can manifest in the smallest things and end up costing time and resources if you don’t keep up with the maintenance.”

Mike:

“Of course, you can hire an additional team in-house, but think of this: you might be able to easily communicate with their API servers or whatever. But you have no control over the standard set in that application, the documentation, etcetera. So maybe, then when you get it handed over, though, you will find out that its code is really unreadable or bad. Trust me, then you have some dishes to do. 

People see that software is built, and it’s done. It’s running somewhere. But the thing is, this part of the software that we’re writing, like let’s say one page – that page might have 30 dependencies because the front end is built on react. React incorporates all these open-source libraries. And in the building process, we’re actually getting packages from maybe 20/30 different locations for building that single page.”

• Hourly rate for a software developer: $50/hour
• Hourly rate for maintenance: $30/hour
• Initial development time: 200 hours
• Annual maintenance time: 60 hours
• SaaS add-on cost: $500/year

*This is an example calculation

Outsourcing allows you to tap into the expertise of professionals who specialize in SaaS development. They understand the intricacies of software architecture, testing, scalability, and maintenance. They can navigate the complex technology landscape, freeing you to focus on your core business.

Jelle talks about his team:

“I think curiosity and inquisitiveness are vital qualities for our technical teams. It’s crucial that team members are genuinely interested in understanding parts of the software that may not be directly related to their daily tasks. For instance, my team focuses on our tool Pay for Platforms, but we rely on core services provided by Farzad’s team. If my team members weren’t curious about how those systems work, it would lead to problems. While not everyone can know everything – having a broader understanding helps anticipate issues and potential implications of changes, both internally and externally.”

In the world of SaaS feature development, the path to success is paved with challenges, complexities, and hidden costs. While the idea of building your feature in-house may be tempting, the smart choice is outsourcing. It’s a strategic move that not only saves you time and money but also ensures the success of your SaaS feature.

Mike:

“Planning for the long term requires balancing immediate needs with future objectives. We often engage in discussions to think beyond our current products and envision where we want to go. This involves understanding our end goal in abstract terms and then figuring out the steps to get there.

As technology evolves, so does the landscape of SaaS development. Outsourcing providers stay up-to-date with emerging technologies, such as AI and machine learning, which can enhance your SaaS feature without compromising trust and security.”

Jelle:

“I think in general, we’re getting more used to using smaller parties for things that are traditionally thought of as being you know, you know, for banking, for example, you have your Bunqs and your Revoluts. And whatever is really starting to become much bigger now. But in general. Just speaking from personal experience, I think people are much more comfortable manipulating their money with things that aren’t necessarily just their bank. You know, you’ve got your Apple wallet, you’ve got your banking application. And you’ve I don’t know, if you trade stocks here on eToro and whatnot, you know, it’s a whole different world in terms of people’s relationship to their money in this case, you know, I think the faithful to like, you do work for someone, and you want to get paid out and trusting us to handle that for you.”

Finqle covers more than meets the eye

Farzad summarizes it perfectly:

“Many core aspects like data security, compliance with industry standards, and scalability are inherent in our business.

For example, we provide APIs for clients to integrate into their systems, and we also offer user interfaces for connecting to Finqle. These APIs, whether they’re for the front-end or user-facing applications, rely on their end to the internal APIs that we don’t expose directly to customers. Instead, clients can interact with them through products like Pay for Platforms. In essence, all these products share common challenges like scalability, security, and maintenance costs, and clients using our APIs benefit from the abstraction of these concerns.”

Gathered new insights?

So, before you dive headfirst into the world of software development, consider the benefits of outsourcing. 

It’s not just a cost-effective solution; it’s the key to unlocking your feature’s full potential and achieving lasting success in the competitive SaaS landscape. 

Don’t let the hidden realities of development hold you back—embrace the future with outsourcing – and with Finqle!

***

This Interview was held by Daphne Datema on the 14th of October in Amsterdam