Building a SaaS with no CTO: key learnings from a rocky journey

Victoire Dumont
Jun 14 · 6 min read

Key takeaways:

  • 💪 Get yourself a tech coach : Find a tech coach to help you choose programmers and pump up your tech credibility
  • 👨‍💻 Stop estimating, just do it: Don’t let the task driven business model slow you down when working with an external team.
  • 💸 Cheap is expensive: Choose senior programmers that will work faster and will keep your product stable
  • 🕺 Choose programmers with a true agile mindset

Three years ago, I’ve funded Artset, a SaaS for art galleries to manage their artworks, CRM and billing.

I didn’t know anyone to go on the entrepreneurship adventure with me so I’ve started alone, naively thinking that I’ll find a CTO along the way. I wanted to test and launch the product ASAP, not waiting for a partner, which can take a really long time and is uncertain and though better be alone than with the wrong person.

I had no clue about the tech market, more precisely, the cost of programming.


Junior programmers: a risky bet

I had a really lucky start with my first programmer, which I’ve learnt after all was not representative at all of the market. I’ve worked with a student that has done things just right.

My other experiences with junior programmers turned out differently to quite a lot of bugs and not enough delivery. I don’t blame them as that was my choice to work with junior programmers for obvious financial reasons, but it happened to cost me more, in money, and most importantly in time and customer satisfaction which are the two assets to pursue as a startup.

Conclusion: Seeking for the cheapest rate can actually cost you more

That’s why I then choose to work with senior programmers.


Working with no estimate: freaky but actually more effective (under certain conditions)

I’ve tried working with agencies but they were not a good experience for me. What did go wrong ? I think there was two reasons for it.

First, what I needed was an actual CTO, someone to technically own the product and think of everything I couldn’t think of because of being non technical and proficiently advise me on how to improve the release process, implementing continuous integration… And maybe I was just unlucky but that wasn’t the case. Instead of relieving me from the tech part, I was actually spending more time testing and them bug fixing. I think the key reason is the lack of involvement. Maybe it would have turned differently if they had developed the product from the beginning.

The second reason was the business model. In order to have more visibility in my cash burn I asked them to pay for specific tasks. I would send them the specs and they would send me back a quote for the tasks.

I’ve noticed that giving estimates is hard for programmers, especially when they don’t know the product. To do it confidently, they almost need to actually do the task, for which they are not paid. What happens is that they usually under estimate (especially if you’re working with junior programmers). They end up adding quick and dirty code to fit with the estimate. You’ll need to pay for a refactoring soon and the code might not be stable. They implemented the features the best way to fit the estimate, not the best way for the product. And I don’t blame them, it’s the just the consequency of the fact that the business model of feature estimations didn’t fit my needs.

Another reason why this business model didn’t work is that the top priority as a founder is to build a great product that users love and go to market quickly. To build a great product you need to iterate so you need to have enough freedom to make changes and asking for a quote for each iteration makes you loose a lot of time and is not flexible enough.

That’s why I choose to work differently with a freelancer. That was my second lucky meeting. We’ve worked with no estimate, I was paying a daily rate and he tried to do the maximum amount of tasks within the given time. It was actually the most effective for me but you need to meet certains conditions in order for it to go on well :

  • Working with a senior programmer that will do in one day more than a junior
  • Building trust: you need to be able to trust him that he is doing his best to deliver a maximum number of features within the given time
  • Being agile

Where to find good programmers ?

So… How to fin them? Here are some suggestions that I’ve tested:

  • Junior entreprise : some schools have students associations that provide companies with students for a specific task. They get to learn and it’s cheaper for you. That how I started the project. I think it’s a good way to attract good junior programmers as if they choose to do this in addition to their courses it most probably means that they are curious and they want to learn, which I believe is the key soft skill to master anything.
  • Linkedin: programmers receive A LOT of sollicitation on linkedin so target wisely. Two tricks for this: search for programmers that have an interest in the pain you’re solving or in the market you’re addressing. For instance, I looked for «[software programmer] + [art]». You can also check the group list of meetups related to your stack. For instance, I was using python for the back end so I’ve check for Python groups in Meetup and checked the Linkedin profile of each participants. The argument for you when approching à programmer is that your product uses a technology he most probably like to use. Finding someone who identifies to the pain you’re solving is a stronger motivational driver than the tech one though.
  • Meetups: it was the less effective way for me but it was good to get some advise.

How to choose them?

  • Value motivation: I believe the motivation is important, so choose programmers who have strong motivational driver. Also, as it take quite some time to find one, prioritize the ones that will stay with you for long.
  • Look for agile mindset: the earlier stage you are in the more critical it is to work with agile programmers. !!! BEING agile is not DOING agile!!! Work with people you have an agile mindset and actually understand what it is to be agile. Don’t try to apply the agile methodology by the book, most of the ceremonies might won’t be relevant for you and you might loose a lot of time for nothing. The best methodology is the methodology that is working for you. For me it was Kanban, but it depends on your team, your customers expectations and your objectives.
  • Require sufficient tech skills : you want to get a tech coach for this one. It will show programmers that even though you don’t know how to code you are surrounded by people who do which is important if you don’t want to be scammed (I’ve seen agencies of freelancers taking advantage of the lack of tech knowledge of their clients). I was coached by Wajdi Fathallah from Valuraise, who I strongly recommend. You can also ask programmers you trust to take a look at the candidate git hub and challenge him to see if he could be a good fit for you. I was surprised how much help I could get from the programmers community.

To conclude on a more personal note, I’m happy I’ve been through this project and built the product I wanted to build, I would have regret not doing it otherwise, but I don’t recommend to build a tech product, like a SaaS, with no technical cofounder. I don’t think it’s impossible if you have enough resources but I won’t build another product by myself anymore. Why not?

  • You need to have the freedom to iterate as much as you need to build a great product, an iterating with an external tech team is hard and really expensive $$$
  • It’s harder to raise fund if you don’t have an associate CTO when building a tech product. Why is that? Attracting talented programmers is hard as they are just not enough. If you don’t have an internal team that you keep interested with stakes (+ a fix rem), you’ll spend most of the time chasing programmers instead of spending time with your customers and on the product

Victoire Dumont

Written by

Product Manager @WeMaintain