Reading Time: 9 minutes

Kandua: Why we’re taking a full stack approach to jobtech

Oct 26, 2021 | Lessons Learned (the Hard Way)

Author: Sayo Folawiyo is South Africa’s #1 online marketplace for home services, connecting independent professionals and small service businesses to anyone who needs their expertise.

In this article, Kandua’s CEO shares their thinking on why a full stack approach allows for a more user-centred and ultimately effective job search experience.

This is a recent job post for a software engineer at Kandua:

In a software engineering team, depending on your product, lifecycle and philosophy, there are different ways to build a team. One way is to leverage specialised capabilities: those who have different experts for the front- and back-end of your product. Another way is to look for generalists: full stack engineers who can work across all layers and tie them together.

I’ve always liked the term full stack as it pertains to our business. The idea of a front end, a back end and an infrastructure. In the context of home services, the front end is customer facing (a homeowner needing to install a sink or an insurer wanting to use a service provider to fix a geyser); the back end is aimed towards the service provider (training to improve quality, efficiency tools to save time, etc.); and the infrastructure is how both of those things separately are done as well as how they interact with each other to be larger than the sum of their parts.

Solving actual problems

In this job post, we say that ‘your objective would always be to solve an actual problem’. It seems trite and perhaps obvious but it’s also a guiding principle. We have set out to shorten the distance between having a skill and making a living from it. We define that as making marketing and operating easy for small service businesses. That is a broad problem — and it requires a broad solution.

As an example, one of the first back-end products we built was a quoting and invoicing system. We found that despite putting service providers (or pros, as we call them) in front of many new customers, they struggled to convert because handwritten quotes could lead to them being viewed as not professional. So, we leveraged our own capabilities to build a quoting and invoicing engine. We realised that this was not only useful for pros to quote and invoice the customers they had acquired through Kandua, but also other customers of their own. So, we opened up the system so they could do exactly that. To date, over 100,000 quotes and invoices have been generated through our system.

If we had defined our problem narrowly — if we had constrained our engagement to the implementation level, instead of solving an actual problem (i.e., if we had stopped at just introducing customers to pros) — there would be no need to do this. The broad nature of the problem meant that we had to think more expansively about our product set.

This stance has far-reaching implications:

  1. It means going multi product early
  2. It means taking a collaborative mindset
  3. It means having a strategy and infrastructure that supports the above

Multi product puts the user – and not the product – at the centre

The home services market is both large and deep. Large, because millions of jobs happen every year. Deep, because in just one job, there are many stakeholders in the workflow. There is the customer, the pro, the materials provider and sometimes the business who is responsible for the job, as in an insurance fulfillment claim. They interact through a series of communication and buying processes, all with their own nuances depending on the type of job. To make sure that goes right, there are multiple products that need to exist, especially when thinking about smaller providers in emerging markets who have no tools dedicated specifically to their contexts.

This kind of problem is best suited to platform thinking. Putting the user at the centre of product development and building accordingly. A lot of products are platforms and a lot of platforms go on this journey – generally this happens at later stages in the businesses as you look for growth opportunities beyond your first and then beyond your second products. A deliberate stance we took very early, for reasons described above, was that we would go multi-product early.

Collaboration means defining core capabilities

Now, obviously, there are serious constraints to this approach. Some depth in products are sacrificed and frankly, there is just not enough of us to do everything. This is where collaboration comes in handy. We might work with a retail partner to open an account that allows pros to buy materials on credit (paid back through job proceeds) or with a training partner to run programs beefing up pros’ soft skills (financed by a development partner) or with a financing partner to offer pros vehicle finance.

To find the right collaborators, we need to know what our core capabilities are, so that we can recognise when they have complementary expertise. Our core capability is intimately understanding the barriers that pros face, and being great at the engineering, UX and data that is needed to build solutions into their workflows. We’re essentially an API into a market that many would love to serve but don’t know how.

It’s a lot of moving parts and actually why we are excited about the JTA. It’s quite a unique problem so finding people to cry to can be quite rare but also it is a call to collaboration. To more openly go deeper into core capabilities and work with others who are nailing different parts of the ecosystem. All in the service of solving actual problems.

The strategy and infrastructure behind our full stack approach

In the interest of collaborating to solve actual problems, I think it’s worth going a bit deeper on what it takes strategically and infrastructurally to make that happen. And it’s worth noting that we are early in a very long journey and I’m sure this will change as we continue to learn.  

On economics

  • Make sure the economics make unit sense – We often found ourselves building useful products and features and forgot to think about monetising it. We’re getting better at asking that question before we build and prioritising accordingly.
  • Blend your financing – Different facets of a platform product in our environment lend themselves to different funding models. We shied away from impact funding for a while, because of the intimidating nature of the reporting, but a lot of what we do is impact-focused and just doesn’t have the unit economics to be sustained in isolation. Rather than try to change that reality, it’s better to just get better at reporting.

On internal structure

  • Hire owners…let them run their own business – There is too much to go around for a strong(wo)man approach. Getting people who have the founder mindset (i.e., they are willing to roll their sleeves up and do the ugly work as well as the sexy stuff – and take responsibility for outcomes with rigour) has been transformational for us. And it flows through all the way to the frontline.
  • Always, consistently, provide context – We repeat and repeat our mission and our objectives all the time — too much if you ask anyone else but me. Repetition is a good coordination tool.
  • Design your internal organisation with the same rigour you design your product – because it is a product. Beyond repetition, there are a lot of other decisions you must make to ensure information flows in the right directions, actions get taken swiftly and feedback finds itself to the right places. Designing that loop is work in a loop of many loops.
  • Be ruthlessly mission driven. This means putting the user (the pro) in the centre of everything. Talk to them a lot and bring their voice into the team in as many ways as possible.
  • If you are the customer touchpoint – be good at building stuff. For want of a less loaded term, be agile and impress your stakeholders.

On choices/strategy

  • Limit something – We still have some work to do here but we try, despite a lot of external pressure. There are only so many fronts a war can be won on – that may be vertical, horizontal or geographical. We’ve limited ourselves to home services in South Africa for the time being, but that also means over 100 categories of jobs (so maybe we could do better).
  • Be a fintech (lol jk, kind of…) – If you can’t beat em, join em. We have found ourselves, quite unknowingly, doing a lot of fintech things, we just didn’t have a name for it. The truth is that the products that are becoming increasingly available are a massive boon to industries and leveraging them helps solve the actual problem. Plus, it’ll 20x your valuation.

On partners

  • Co-create with collaborators and look for long term partners – It’s a long game and we are very early in it. Good partners want to create with you, understand the long-term nature of the journey, and are more forgiving.
  • Be useful to the ecosystem – As much as is possible. Join JTA to share your own insights, help co-create ecosystem solutions, and find ways to bolster the work of others.

And, that full stack engineer role is still open. So, if you’re interested in solving actual problems, apply at

The author is the Founder and CEO of Kandua


Pin It on Pinterest

Share This