5 learnings when building and scaling a service-based tech company

Building and scaling a service-based company is totally different than a product-based one, here are the main learnings!

---

Senior Engineer to Lead: Grow and thrive in the role (2 days left to enroll)

It’s getting close to the start of the January’s cohort-based course. It’s going to start in 2 days.

In the course, we particularly focus on the development of much needed people / communication and leadership skills in order to grow from engineer to leader.

If you are not enrolled yet, you have 2 days left!

Looking forward to seeing some of you there.

Let’s get back to this week’s thought!

---

Intro

I’ve done a lot of freelance projects for clients over the years, from building web, mobile and all the way to desktop apps.

That has enabled me to gain a lot of experience in a short amount of time.

I thought about scaling the operations and actually go from me, working on such projects to expanding and creating a service-based company.

But haven’t made that jump and rather focused on progressing in my full-time roles.

For everyone thinking about potentially doing that or you already have a (service-based) tech company, this article is going to be a great read for you!

I recently met with Aleš Čadež for a coffee and we talked about many different things, especially regarding the challenges a company and also engineering teams face when scaling.

I’m happy to have him on as a guest author today. I’ve asked him to share his 5 main learnings on scaling a tech company with us.

Aleš is a fellow Slovene and the Co-founder & CEO of Kaldi → a service-based tech company that builds digital products from discovery to scale.

Let me say a few words about the company before we dive into Aleš’s learnings.

Kaldi went from 5 to 35 people in 5 years

As mentioned above, Kaldi is a service-based tech company from Slovenia and they particularly focus on building products for clients (mostly startups & scaleups).

The company was founded by two engineers, who dealt with the pain points of scaling and in recent years went from 5 to 35 people altogether in the company.

People in the company are in the fields of engineering, product design and project management. This enables them to have all the necessary experts to build products based on the client’s needs.

And building + scaling a service-based company is quite different than a product-based one. It’s a lot less predictable and you can’t just quickly expand the operations.

Now that we know a bit more about the company, let’s get into particular learnings.

Aleš, over to you!

Learning #1: Focus on vision and align strategy to it

Imagine a scene where two engineers who like working on interesting and challenging projects start a business. The only “vision” is to “work on such projects”.

Soon, they have too much work and they hire a couple of colleagues/friends.

Everyone is working hard, coding and building fancy features on projects that “come around”. Recipe for the happy life of a bunch of engineers right?

Not so much.

Soon these questions start comming up:

• Why are we doing what we’re doing?

• Why work on this project and not on the other?

• Should we hire new people or say no to new projects? Ditch existing projects?

With no vision and strategy, there is no direction and no purpose.

Through the mixture of pure luck and reading a lot of books, we stumbled upon a book “Traction: Get A Grip On Your Business” by Gino Wickman and it’s Vision Traction Organizer (aka VTO) → A canvas for setting the company vision, strategy and short term goals.

It has helped us to make a step forward and finally start thinking about what we’re actually building.

We (two co-founders) spent evenings and weekends thinking and talking about what kind of company we actually want to build.

Once we aligned and wrote it down, it became so much easier to make decisions (still a lot of wrong ones).

Learning #2: Understand & align business goals with clients

No matter how much you want the product you’re building for a client to succeed, being a service-based company, you’ll always be seen as an outsider with different business goals.

That’s why it’s important to find the alignment between you and the client. You can do that in 3 steps:

• Understand business goals and limitations of the client

Use the initial alignment meetings to really understand the client and ask the right questions. Try to thoroughly understand their pain points and motivation behind their needs.

That will position you as a business partner that understands the business at the high level.

• Communicate your engagement and goals clearly

Make sure that the client understands why you’re going into this relationship and what particular things are you offering. Make sure that the expectations are clear.

• Find common goals

When architecting the business relationship, try to find common goals when preparing the proposal. What outcomes are a success for both parties?

Book recommendation for negotiations and finding common goals: “Getting to Yes” by Roger Fisher and William Ury.

Learning #3: Understand what you’re selling

There are a lot of service-based companies out there. But are they all selling the same thing?

In general I believe there are four types offerings:

• Outstaffing

This model works well if the client is only looking for additional people, doesn't need any outsourcing particular expertise and has people management under control.

• IT development

 There's a full-stack team and there's a project that needs to be delivered from start to finish. It has a fixed budget, fixed timeline and what needs to be delivered is clear (or at least management & team are under the illusion that it's clear).

This fixed-price model works best for software projects that repeat the existing, predictable functionality (e.g. rewrite of the in-house accounting system).

• Software development

Usually consists of a team of engineers and project manager(s), but other roles (design, product management, budget management, etc.) are either outsourced from other companies or internal.

Roadmap prioritization, process analysis and improvements and everything else is managed by the vendor.

• Product development

There's a full stack engineering and product design team available, but the key difference to the software development team is that the product management & project management are part of the offering.

More specifically, the company provides two core team members that dictate the direction and tempo of product development.

As a service-based company, your client portfolio will probably consist of all these four types of engagements.

But at some point you need to focus and decide which direction to take. You can’t focus on all of them and expect to achieve the best outcomes.

For us, it was the love for being at the heart of designing & building new products, so we’re all in Product Development.

It’s rewarding but also probably the hardest type of engagement to build as it requires in-depth relationship and trust with the client.

Learning #4: Product before Engineering

Here’s a hard truth for all hard-core engineers → I spent years thinking that everything starts and stops at scalable, reliable and secure code.

It doesn’t.

There are more useless products with great code than useful products with crapy code out there.

We spent the last five years building a strong product design team and combined it with the well defined development process.

The added value it gives to the products we help build for our clients is amazing and it has helped us to actually become a business partner (and not just an outsourcing agency with great development capabilities).

There really are countless book recommendations regarding product design, but one that stuck with me is “Inspired: How to Create Tech Products Customers Love” by Marty Cagan.

Learning #5: Trust your gut feeling

Here’s a controversial opinion based on so many decisions I made that were “right” on paper.

Consultants, books & managers will also often tell you that you should base your decision making on analysis, excel spreadsheets, interviews, data, etc.

But when you do that and the decision on paper looks dead set, but you just don’t “feel it”, trust your gut instinct.

Here’s the good part, even if it turns out that you were wrong, you’ll have less remorse than if you didn’t follow your gut.

So, in what cases you should apply that gut feeling?

I don’t know for sure, but I do it for hiring, deciding which client to work with and especially for all decisions that are urgent but not mission critical (check the Eisenhower Matrix to understand the importance and urgency of tasks/decisions).

I have no book recommendation for this one. If any of the readers has any good ones, please share it in the comments below. I would love to read more about that.

My takeaways from Aleš’s learnings

Gregor here again.

Thanks to Aleš for sharing his learnings with us! Here are my 3 takeaways from Aleš’s insights:

• Building good relationships with clients is very important

Spending time to really understand the wants and needs of clients and making sure to map them to your solutions will provide great outcomes. You’re not just providing a service, you’re building a partnership.

• Building the right things comes first, building the things right comes second

This is what I always advocate for and it’s great that Aleš has also mentioned it. Great and scalable codebase alone will not provide success.

• You need to pick your focus

You can’t just “be the best in everything”, picking your focus ensures that you create the best outcomes and develop expertise.

Last words

Thanks again to Aleš. Make sure to check him out on LinkedIn and also check out Kaldi. If you’re looking for a partner in developing your next/current product, definitely reach out to them!

---

We are not over yet!

What’s next after Senior Engineer?

Together with

Caleb Mellas

, we wrote an article for his newsletter

Level Up Software Engineering 🚀

It’s about what’s available out there after you hit Senior Engineer level (Hint: your career has just started!)

---

Liked this article? Make sure to 💙 click the like button.

Feedback or addition? Make sure to 💬 comment.

Know someone that would find this helpful? Make sure to 🔁 share this post.

Whenever you are ready, here is how I can help you further

• Join the Cohort course Senior Engineer to Lead: Grow and thrive in the role here.

• Interested in sponsoring this newsletter? Check the sponsorship options here.

• Take a look at the cool swag in the Engineering Leadership Store here.

• Want to work with me? You can see all the options here.

Get in touch

You can find me on LinkedIn or X or Bluesky.

If you wish to make a request on particular topic you would like to read, you can send me an email to info@gregorojstersek.com.

---

This newsletter is funded by paid subscriptions from readers like yourself.

If you aren’t already, consider becoming a paid subscriber to receive the full experience!

You are more than welcome to find whatever interests you here and try it out in your particular case. Let me know how it went! Topics are normally about all things engineering related, leadership, management, developing scalable products, building teams etc.