How to cut costs and avoid issues as a non-technical SaaS founder, when hiring a software partner
The experiences of a CTO with young startups that have outsourced their entire software
Engaging a software partner can be a very tempting approach for a young startup.
Especially if you don’t have a tech co-founder (or a technical advisor), the step to hire such an agency is quickly made. After all, you don’t have the technical know-how, let alone a development team, but you do want to hit the market quickly.
These agencies are waiting for you with open arms, and you will feel very comfortable, knowing that they will ‘unburden’ you.
A match made in heaven.
Or not?
As Fractional CTO, I have helped many of these types of companies in the last seven years, such as startups that had first fully outsourced their software, but then wanted to insource (with some funding), but also very young startups with only ‘the idea’, but with the presence of mind to involve an expert first.
I regularly incorporate all these experiences into posts on LinkedIn, but I think it is good to list things structurally and save so much suffering for startups.
It’s always the startups that bear the brunt. Eventually.
Hidden issues
What’s wrong? Well, a lot, and the vast majority of SaaS startups find out far too late:
1. Where you think PRODUCT, they see a PROJECT
Think about that.
Every list of features you throw over the fence just leads to a project to get it done. Nothing less, but certainly nothing more.
2. Domain, product and market thinking is completely disconnected from software development
This requires some explanation: an ideal SaaS company has a continuous development cycle that is an extension of, and is closely integrated with the product vision.
Lean, agile development, especially with the philosophy of Design Thinking, is very hard to find if you engage an external software company. The lines become long, switching/iterating/adjusting in the development process is seen as undesirable.
3. Their main concern is optimizing profits
They are not interested in cleverly cutting corners for the first MVP, nor in creating reusable blocks, abstraction layers, security or data architecture.
4. Documentation is not their priority
Whether it’s steps taken (architectural decisions, for example), processes, or research, it’s just not their priority, unless of course you specifically ask for it. But then expect a hefty extra bill, because ‘documenting takes so much extra time if you want to develop quickly…’
5. As non-technical founders, you can only judge delivered functionality
You just have to take software builder’s word for it, because you simply cannot say anything about the software quality, robustness, scalability, underlying architecture, etc.
6. You build up less value/IP
As a startup, you do not build up transferable knowledge and IP about (the technical side of) your product. In other words, you get less value buildup in your startup, because you outsourced the entire technology.
This is a big risk and will often be judged negatively if you are trying to get financing, because an investor will of course look extensively at how the knowledge is invested within the organization.
If a technical due diligence is done, you are of course completely at the mercy of the gods, as non-technical founders.
7. The stack is forced on you — without you noticing
The software stack (the languages, the platform, the client and server-side frameworks) that the software partner uses, the tooling, the hosting provider they partner with: these are all things they prefer not to even talk about, because it is so nice and efficient if it is exactly the same for all their customers.
The chosen software stack is often very much intertwined with the history of the software partner: it mostly emerged through all kinds of coincidences, then got built out, with new developers hired, etc.
As a non-technical startup founder, you are, unsuspectingly, at the mercy of the partner’s setup, and it is only later that you are confronted with it. This aspect alone can lead to huge reinvestments.
8. Your software is crammed into a straitjacket — theirs
Since most development agencies are code factories, chances are they will use their own development templates, patterns, libraries, and best practices.
These are often carefully (internally) documented, and easily transferable (they often have high staff turnover). This means that many of these things do not change quickly, because that simply costs the organization too much in updating documentation, training new staff, and so on.
9. You don’t own your own stuff
The ‘unburdening’ often goes so far that the entire source code of your own software, and the entire so-called Application Lifecycle Management (ALM), the tooling and historical data about how the application is built, tested, rolled out and managed, is ‘managed’ away by the software partner.
Of course, the contractual terms state that it is all yours, but being able to dispose of it freely, hire an expert and have it monitored, transferred, these are all matters that are made complex and bureaucratic, should you ever raise it with the partner.
10. Letting go is accompanied by emotion
No matter how strange, when the original agreement is under reconsideration, emotions are triggered at the software company. The account manager who of course already knows the tricks of the trade (in the end every project is finite) might not show it, but the people involved in running the project, the ones who have involuntarily started to feel a bit ‘owner’ of the code, will have difficulties in letting go.
That difficulty in letting go can translate into a sudden decrease of the ‘cooperation mode’, a subtly different attitude that can be called unprofessional, but which I unfortunately encounter very often, and as a result of which, processes suddenly take much longer, things are not done ‘wholeheartedly’, emails are poorly responded to. And things can even get worse than that.
So just don’t work with software partners?
You can’t simply sum it up by saying you should never work with a software partner.
This article may already provide some guidance to start the conversation in a different way: let’s go work together, but we do want to set some preconditions…
Yes, it helps to indicate that future transfer to an insourced team is essential
But it shouldn’t stop there. Setting preconditions is just the beginning of a solution.
Hiring an expert to represent you is the consensus I see slowly emerging, at least in the discussion with my peers, who are often flown in by startups where “something is wrong”.
I’ve seen quite a few startups get into trouble myself, and got to clean up the mess in the kitchen — or build a new kitchen.
Most of these startups indicated that they had no idea about the problems they would face, for a very long time.
So how can an expert help?
Better safe than sorry. Of course, it depends on the phase in which the expert is brought in.
Prevent
- Select the right software partner — one that specializes in working with young SaaS companies, and understands that as they grow, they want to continue independently, and before getting to that point, have a technical intermediary.
- First of all, bring the ALM entirely into its own management, and let the partner work on it.
- Help to set up a suitable, future-proof architecture, with which the startup can continue without the partner at any time.
Heal
- Putting the business objectives of the startup front and center
- Translating business objectives into technical roadmaps
- Ensure adding testability and automated testing into the software
- Regular stakeholder contact on solid product thinking, ensuring less project-like ad-hoc approach.
- Coaching and challenging the partner’s developers with SaaS best practices
- Quality assurance
- Focus on continuous knowledge capture
Say goodbye
- Carefully advise the software partner that the collaboration will be phased out because the startup wants to become independent.
- Focus on the delivery of good high-level documentation of design/architecture/flows/infrastructure
- Mapping dependencies (e.g. to shared software libraries of the software partner)
- Set up an internal team, starting with an experienced Tech Lead.
- Facilitate careful handover to the internal team, minimizing the risks.
Costs
Bringing in an expert in addition to a software partner, initially seems to increase costs. However, the opposite is true, because an experienced intermediary will instead save costs in all kinds of ways:
- Better architectural decisions
- Smarter cloud setup, with lower operational costs and less management
- Better build-or-buy decisions
- More efficient component development
- More efficient process
- Better communication, and less lost-in-translation with the software partner
- Smoother transfer to an insourced team
- Less disinvestment
- More sustainable choices in technology
Conclusion
It does not have to be a problem to fully outsource your software initially, but be aware of the pitfalls and the temporary nature of the collaboration (even if you cannot yet oversee it), and preferably involve someone who, as a technical intermediary, has often supervised startups, knows how software agencies operate, and can represent you to them.
You will save a lot of costs and misery, and be grateful for it later.
