Shopmium Co-Founder & CTO on
scaling a startup the anarcho-agile way

Quentin de Chivré

Quentin de Chivré has a particular set of skills, skills that he honed over years of building successful products. And his ability as a “tech grower” extends beyond pure tech knowledge and towards steering organisations into building great products.

As the first lead developer joining PriceMinister in 2000, he helped expand the team from 4 developers to 30 team members over a 9 years span. He then moved on to creating Shopmium, a digital couponing company successfully acquired by Quotient Technology Inc. in 2015. After his startup had been bought by Quotient, he continued growing the engineering department, which has now doubled.

In this interview, Quentin de Chivré shares his experiences and tackles the specific complexities of building a product in a startup context. Focusing on resources and output, the two general dimensions he deems the most important to take into consideration as a CTO, he outlines the practical steps to address each of them. Any startup company looking to take a break from day-to-day struggles will benefit from his take-a-step-back guidance.

Think twice about what your people focus on, they’re your scarcest resource.

1) Reduce the number of languages your team deals with

How do you make do and create added value when resources are scarce? How do you achieve much with little at hand? This is the all-too-common challenge encountered by startups, and Shopmium was no exception.

“As a startup building a mobile app, we were faced dealing with multiple technologies – iOS, Android, and a somewhat rich backend – with very little financial and human resources. We started out just two smart, straight-out-of-school developers and I”, Quentin describes. “In Shopmium’s case, developing a mobile app meant dealing with two completely new technos, with an extremely compact team”. Developing a mobile product represents indeed an enormous cost for a startup, and very few can resort to appropriately specialised developers. So Quentin decided to minimize the strain on the application side by using Titanium, a cross-platform development framework in javascript.



Using Titanium was a growth hack which lasted some time for Shopmium, as it allowed them to focus on one language instead of two at a time. And it’s only half-way between the first and second funding rounds that the tech team became specialized and split in two pods, one for mobile apps and one for servers, allowing developers specialization. Now that their apps are native they are moving towards an API philosophy, with a server and API serving 3 clients, Android, iOS, and web.

2) Let your people focus on your core company know-how

During startup beginnings financing is scarce and an engineer salary is a huge cost. “Still today, my infrastructure costs are quite low compared to an engineer salary” adds Quentin. He goes on to explain that whereas prices for machines decrease over time, prices for skills are stable or even on the rise. So the trade-off between technology, machines and developers is really about productivity and maximising what your team can build.



“You have to take the time to really understand what is your core business and what is not, and then trim down all the tasks that bring less value to your product than the others”, says Quentin. “Once you’ve found competency, it’s all about maximising their productivity and efficiency. This is why I chose to work with Ruby on Rails, and not Java. I know there’s an ongoing debate about Java and Ruby, pointing out that Ruby is less effective. But Ruby is extremely interactive and iterative, and so we chose Ruby. Once again, adding machines is less costly than adding engineers.” The core of Shopmium’s added value was not in its infrastructure, nor was it in its logging or project management capabilities.

shopmium app



With this idea in mind Quentin chose to work with Heroku. With first-hand experience of how long it can take to add machines, going through the ordering, provisioning and setup phases, the last thing he wanted was to experience it again in the high-growth startup context. “I believe it’s a focus drain” Quentin explains. Searching for a way to avoid the issue, he found out about Heroku. “It’s honestly magic! When I want to add a server, I just push a cursor and get 10x more power, it’s unbelievable.” And Quentin goes on “My role is not to make any point manually installing servers on my own, but to make sure my guys are spending time on the right issues for the product and the company.”


The overall course of tech resources optimisation

1990's2000's2010'
Completely externalise tech knowledge by buying software licences.Drive your company developments using free knowledge bases.Focus developments on your core business & outsource everything else.
Software licencesOpen sourceSaaS products

Quentin de Chivré specifies that this philosophy followed him throughout the stages his product and startup went through. “Once funds have been raised, you’re still in a scarce resources situation, you’re still trying to prove you can create value with limited resources, and so you’re still focusing your energy on the very thing that adds value to your product,” Quentin points out.

3) Favor working the way your team does best

Shopmium Team

Quentin has a propensity for finding hidden costs. In addition to resorting to SaaS tools to avoid the hidden costs of human resources, he chose to handle the migration from Titanium to native development for Shopmium’s mobile apps in a very specific way.

“Frustration was building up, so it was time to move on to native development. We could have paid an agency to deal with the project for 6 months. But choosing an agency means losing knowledge about your product, which usually later translates in maintainability and evolution difficulties. You don’t want your product to be petrified in time. Costs may be more controlled, but agility is lost. Or we could have dealt with the 6 months project internally, but we did not have the knowledge for it,” Quentin says.



Shopmium’s tech team thus started looking into Titanium insides and built a hybrid techno of a native app embedding the existing Titanium code, with scaffoldings joining migrated parts to the ones that were not yet migrated. The first release was about the subscription tunnel, then it was about a tab, and so on… They were able to release every month or so and did not face an enormous validation phase at the end of the project, when nobody ever remembers what they did 6 months ago. With their shorter sprints Shopmium’s team members remembered clearly what they had developed a short while ago, they could easily maintain and patch the live version.



Put extra attention in maximising your output

1) Process with baby steps, what’s valuable is unpredictable

Building up a startup means testing a lot of things. “There’s a lot of things you try, knowing full well that you might have to trash it later on if users or the market do not pick it up” explains Quentin. “We tried Shopmium Mission for example, which was addressing the need of a new set of professional customers for in-store data. We tried, but it turned out to be complicated to operate and with little value for us, so we let it go.”



Quentin de Chivré believes Simoncelli once said something about startups being like fold blinded rats in a labyrinth, bumping into walls. “You go straight ahead and you bump into a wall. You turn right and you bump into another wall. Little by little, through bumping into walls, you find your way. You code, and you code, and your product develops in this way too.” Quentin clarifies that this is also the reason why they did not chose to proceed with a 6 months long project when migrating from Titanium to native code. “With a long term project, something would end being delivered after 6 months, whether it really works for your product and business or not.”



Which also means that Shopmium’s roadmap was voluntary hazy, and as Quentin puts it “it is still now, but it was especially so in the very beginning. You don’t want to spend time specifying each and every feature you’re going to build over one year. After only 3 months, once you’ve realised some features add value while other don’t, priorities will have changed. So working with a 3 months plan seems as far away in time as you can manage to not dig your grave with unrealistic product visions.” In the case of Shopmium, the tech team had a global vision and a course to follow, and with every small release they were learning what made sense. Their platform was zigzagging, but towards one direction.

shopmium app

2) Finish up your roadmap with business

It’s crucial to make sure you have a global direction for your product that gets activated by your company’s clients needs. “It’s not about having an archi. absolutist vision. My co-founders and I would agree on possible features for the upcoming year, and they would enter the commercial deck. Once this roadmap was globally defined, we told sales they could sell whatever feature they wished from it. And as sales were approaching closing deals with specific features included, we would develop them in priority.” Quarter after quarter, Shopmium’s tech team was thus developing features that were both part of their product vision and perceived as especially interesting by the market.



Working in this way allowed Shopmium to avoid spending time on developing features prior to really knowing if they had any actual appeal to anyone, thus potentially losing energy on lost causes. Of course it meant being extremely agile as once end users are getting interested, features need to be developed quickly and beautifully. Shopmium thus developed with coherence because of the initial impulse being driven by product vision, while being activated according to business needs and real-time client feedbacks.



Quentin goes on “Minding the business and making sure the product is a good fit for your company business is a necessity. And it might mean accumulating some technical debt. But in the end, your product fits market needs, it is sold and it scales. Then your can look into technical debt.”



More CTO stories to come. Get them straight to your inbox & sign up to the blog!

Love this? Share it!

Related Posts

Get notified when new content is published