Running a dev shop — part 4: Attracting customers

This is the fourth part of a series on running a dev shop. See the overview of the posts below.

🎮 Part 1: Myths and favorable facts
🥾 Part 2: Bootstrapping and specialization
🎤 Part 3: Talent pipeline and employee lifecycle
📣 Part 4: Attracting customers
📈 Part 5: Growth

“How do I attract customers?” is the first and most important question one should ask oneself before setting up a company. Marketing and sales are as important for a dev shop as for any other business. And today, we’ll dive into this topic.

I will first cover target audience and different lead sources. Then, drawing upon my own experience, I will go over the marketing strategy, together with examples on how to execute it. Additionally, I’ll share some tips and tricks around time management and lead conversion.

Finally, to summarize the four blog posts so far, we will do two more things. First, we will look at how value flows between a premium dev house and its stakeholders. Second, we will review the Framework for running a Boutique Dev House.

Target audience

One common mistake that small software houses make in their marketing efforts is to try and appeal to a broad group of potential customers. While it may seem logical, in reality, this approach can be inefficient and even detrimental to company’s growth. Instead, small software houses with limited resources should focus their efforts on a smaller, more influential group of potential customers.

I’d like to put forward an idea for the target: the developer community of a software house specialty. To understand the rationale, first take a look at the market structure illustration below.

Targeting dev communities might seem a little unintuitive at first, but in my opinion, it is by far the best target dev house can pick. How come? Let me go over a few insights:

• Your potential customers involved in the community run the most interesting projects and posses strongest technical brands.
• The core community and decision-makers are part of the same market — by definition, a market is a group of people buying the same services and talking to each other.
• Most of the time, the core dev community provides quality insights to decision-makers and not the other way around. They are the network you want to build so they can refer you further.
• Finally, your presence in core technological communities helps you build a long-lasting brand that might even continue to bring you leads for months and sometimes years after you cease your communication efforts.

Sources of leads

Sources of leads seem to be a tactical detail of a marketing strategy.

However, giving careful consideration to the limitations of each channel may give us clarity in evaluating strategy effectiveness.

Each communication channel may lead to fundamentally different perceptions of the brand, which translates to a different pricing structure, which in turn defines the margin and profitability of the business.

Let’s examine the channels, starting with the lowest quality and climbing up to the higher quality ones. The higher the quality of the channel — the lower the competition and potentially, the higher the hourly rate.

Outbound channels, like cold calling and cold mailing, are probably the worst type of channels, which tend to lead to attracting low-quality customers and lower rates. Why is that the case? As a CTO of a silicon valley start-up, I experienced it firsthand — receiving 5 to 10 outbound emails daily. And that is already after automatic spam detection and promotional content filtering. I habitually delete them before reading. And likely, so will your best potential customers.

Occasionally, when the recipient reads an e-mail, they will think of you as a needy, low-quality company, in the same bucket as many other companies using outbound strategies.

Ads can create a good, predictable stream of leads. The challenge of attracting customers with ads is that the competition tends to be fierce, which in turn will drive up the price of the lead over time.

Moreover, ad companies, like Google, continuously try to elevate ad prices by pushing competitors to compete for the first place, by raising the cost per click. This eventually results in low margins, which to some extent, can be mitigated by a strong brand and good content the ad is pointing to.

Paid ads can be very helpful when you have suddenly lost a client and the risk of engineers sitting idle on the bench is high. However, setting up effective ads takes time, so you want to make sure you’re ahead of it and ready.

One more interesting use of ads is retargeting, which helps to improve conversions.

But most importantly, a high-margin dev house should be aiming for a stream of leads that do not need boosting or rescuing with ads and avoid bidding situations with the competition.

Catalogs like Clutch are a good way to position your company. Especially premium profiles can bring quick effects. They tend to convert faster than ads and are quite cheap. However, they still suffer the same competition dilemma as ads but with lower predictability.

How so?

There are over 1000 companies in the popular Clutch catalog, only in Poland, only in the category Web.

Here again, defining a clear specialization and a distinct profile can work miracles. This is exactly why at some point Ethworks’ was the only 100% blockchain-centered profile on Clutch in Poland.

However, I would not consider catalogs to be a strategic marketing channel, as they are beyond the business owner’s control. It is up to the website owner how they position you. There is no control over how many competitors there are. Therefore, it can suddenly stop working or lose effectiveness with time, despite your best efforts to maintain it. That happened to us.

At that time, Dribbble was our main acquisition channel for design projects. At some point, we discovered a bug in Dribbble — our profile didn’t show an “Available for hire” button. Support wasn’t very helpful and however hard we tried, we were never able to restore it as a channel. Soon, the company was acquired and changed the rules completely, putting an end to any predictability, even with the premium membership. Without the brand and recurring customers, we would have been forced to downsize our design team.

This kind of channel degeneration is not an exception, but an inherent part of the platform’s natural life cycle.

Catalogs and ads are great for boosting marketing in certain phases of the company’s lifetime, but they should never be part of the long-term, core marketing strategy, as they depend on external factors, beyond users’ control.

Deal sharing is another popular way to attract customers, where a dev house that happens to be fully booked shares a deal with another one and vice versa.

With some exceptions, I would generally consider it a low-quality source, as it leads to:

• low quality of leads, as the forwarding party will want to convert the best leads themselves,
• lower margins, as the receiver pays a referral fee,
• low predictability, as the forwarding party will prioritize its own predictability over the receivings’ party.

There is a whole tier of low price, low margin dev houses — living off shared deals from the higher-tier dev houses. This is a type of business I would avoid running as much as possible — it’s not very profitable and predictable. It also usually lacks a clear path for change.

Content and SEO, which usually go together these days, are perhaps the best channels considered so far. Building content and position in search engines takes time but sets up a predictable stream of customers.

The effectiveness of content strategy depends on the content quality and high-quality content might do wonders, while the low quality might not attract any leads at all.

There’s one snag to it — the effectiveness of the channel takes years to build and even so, over time, it might be diminished by competition that contends for similar keywords and topics.

And the most important question is — where to take content from? This is exactly the question that marketing strategy should answer.

Events (virtual or brick-and-mortar) are a set of potential interesting channels. Depending on the type of involvement, it can be a channel of different quality:

• Low — when just attending one
• Mid or high — when presenting at one, depending on event quality
• Mid or high — when organizing one, again depending on the event profile

So, to get quality leads, one should aim to either organize key events for a given community or present at ideally high-profile, prestigious events.

A good strategy helps to get into high-profile events or attract quality speakers and attendees to one’s own events.

Networking. People who know you, trust your skills and might need your services, tend to be a source of high-quality projects and referrals. Therefore, growing a network of such people is one of the best ways to attract customers.

There is a caveat: due to low predictability of any single relationship, the network needs to be quite big to produce predictable results.

Here again, as with content, you will need a good strategy to build a quality network.

Referrals are by far the best source of leads, especially if multiple people refer a single customer to you. Referral instantly sets up a high-trust and low-competition situation. For referrals, you can leverage your network, existing customers and general brand recognition.

Strategy

This brings us to the highlight of our considerations — the marketing strategy. From the previous considerations, we can conclude that we would like to have something that addresses the core technological community and can grow our preferred channels — networking and referrals.

And one strategy that fits this description is…

contributing to the technological community of your specialty.

How to contribute to the community? Usually in one of the few ways:

• Creating and promoting important open-source projects for the community
• Contributing to existing open-source projects
• Organizing key community events (meetups, conferences)
• Developing solutions for common problems (architecture and design patterns)
• Cataloging common challenges and solutions (i.e. tutorials, how-to’s)

Such activities can be later promoted further via high-value communication:

• High-quality content (blog posts, social media posts, announcements, and tutorials)
• Announcements on your social media channels, which in turn grow your channels and gain influential followers,
• Talks on high-profile events,
• Publishing books and articles.

Predictability

A cautious reader could argue that community contributions can hardly ever build a predictable revenue stream. However, the goal here is to build a pipeline that significantly exceeds your capacity and only convert the best projects, which in turn builds your brand further, by:

• association with a known brand,
• further community contributions,
• building know-how that can be leveraged to evolve your specialization.

I believe quality dev house’s marketing strategy should focus on contributing to the community, which is then leveraged to build brand recognition and grow the network, referrals, and own communication channels.

This can be marginally boosted by ads and catalogs, but not by means of cold mailing, which lowers the perception of the brand.

If you start building your strategy based on low-quality marketing channels, it will be hard to climb up to higher-quality ones.

Compound effect

A single marketing effort, however spectacular, isn’t very effective, so one shouldn’t expect too much from one blog post or a conference talk. It is multiple, small efforts over an extensive amount of time that add up and generate powerful compound effects, which in turn convert into a well-recognized brand and a lead stream.

It starts with a single lead dripping every now and then. With time and consistency, it will become a strong stream of leads that are likely converted into projects.

Combine it with quality services, and you can establish a solid and recognizable brand, with a long-term competitive advantage, which will attract top customers and top talent to your company. A strong brand can carry your business for years, even through setbacks and crises.

Snowball

The goal of marketing is to build a snowball, where working with customers leads to insights that are leveraged to contribute to the community, which promotes you and brings in more quality customers, work with whom brings more insights, and so on and on.

Marketing departments and agencies

I am personally somewhat skeptical about working with external marketing agencies, as they can provide limited support for your core strategy. You know your specialization, understand your target and speak its language. You understand community specifics, and challenges and can propose potential solutions. This is the core competency that an agency lacks and is not able to learn.

Agencies can provide some support for organizing events or setting up the ads, but you still have to provide key insights like event agenda or keywords to optimize for.

Surprisingly, similar reasoning can be applied to the internal marketing department. Therefore, marketing of quality dev shops should be led by… engineering.

Examples

Over time, Ethworks has made many contributions to the Ethereum ecosystem, including many events and writings. I am by far proudest of our two open-source projects: Waffle and useDApp.

Waffle

When we were writing tests for smart contracts in our very first project, we found out that available testing frameworks were pretty cumbersome and missed basic matchers to work with smart contracts.

As we were writing the project, we kept adding new custom matchers and other helper functions. Eventually, we extracted the matchers to an external library called Waffle. A few blog posts, shares, and a small grant from the Ethereum foundation were enough to promote it and make it gain traction in the community. Eventually, the project was picked up by the soon-to-be industry-leading project-building framework — HardHat, and became part of the standard technological stack for developing smart contracts.

At the time of writing, it is used by over 80K open-source projects. It is successfully competing with heavily-funded startups. Needless to say, Waffle did a tremendous job to grow both Ethworks and my personal brand.

useDApp

Another example pertains to a different part of a stack, but it’s quite a similar story. Writing the front end for DApps used to be a struggle. There were plenty of annoying problems: refreshing data after a new block was mined, tracking the transaction state, a high number of requests a simple DApp would generate to a node. The list goes on and on.

And we tried it all — React, Redux, Rx, DDD, always trying hard to keep the code clean but always ending up overloaded with complexity or crappy UX.

One day an engineer in our team came to me frustrated by yet another attempt to write a clean front end. He ranted about how all front-end is poorly written and went on to describe how it should be written: a new paradigm of creating front-end combining a new, at the time, React feature — hooks, and a pattern developed by MakerDAO — multicall.

Later on, upon the client’s permission, his team rewrote the front end to utilize the new paradigm. He later extracted a small boilerplate that we used in one other project. I later turned it into a library called useDApp. The lib is still in its early days but is already used by more than 3.5K open-source projects and many more closed-sourced projects. There is now a dedicated team that will start working on version 2.0 soon.

Making the noise

Both useDApp and Waffle generated countless blog and social media posts growing our Twitter accounts with high-quality followers.

We published tutorials on popular web publications sites and the Ethereum community website. Waffle became so popular that many more tutorials and posts were written by the community than by ourselves. So they did our work for us.

They opened doors for us to speak at the most prestigious community events — only in ’22, we presented at top events, including Devcon in Bogota, DevConnect in Amsterdam, EthDenver, EthCC in France, EthWarsaw and more.

Ultimate value proposal

I believe both of those projects reflect the ultimate value that dev house can bring to the community.

The ultimate value proposal of a dev house for the community comes from solving the same problem over and over again. It is a great opportunity to build a fundamentally better solution than what is used by the community. This can take on many forms: a new framework, a library, a new architecture or design pattern, a bug fix or just sharing a clever solution for others to look up.

Here is a cherry on top. Funds that the dev house earns for the community by doing projects are invested back into the community instead of going to marketing companies. It is a highly noble cause that I personally feel very good about.

Time management

A small company with limited resources has to find ways to meaningfully contribute to the community. First of all, it doesn’t need to make all the efforts all at once, but it should always be doing something: use scraps, reuse content, and publish updates.

Many marketing efforts and employer branding activities can be combined into one or act as complementary ones.

Moreover, there are several creative tactics to contribute to the community in a dev house in its early days:

Working after hours

This was how I got the first version of Waffle released. At the time, there was no way I packed that work into my busy schedule. This method is not very sustainable and it does not scale, but it is a great way to kick things off. The reality is that it might be hard to kick-start a premium brand without extra effort.

Gradual extraction

Libraries and frameworks often start with minor helper code or a layer of abstraction in a client’s code. Over time, code can be copied as snippets or extracted to a boiler plate. Next step should be testing in more than one project, and later extracting into a small lib, which can be developed into full shape over time.

To fully push a library project forward, you can backport it to customers’ projects. This will enable you to do small iterative changes that can be billed to a customer. I found this practice to be fair as long as the customer agrees to it. It can bring them clear value too, as customers get updates developed in other projects for free.

Note: It is advisable to make it clear in your contract with customers that you can extract code. Make sure that customer competitiveness is not threatened and it is always best to just ask in every specific case.

Internal hackathon

A one-day event for the whole company — organized now and then, with the goal to extract libraries, write tutorials and blog posts; patch open-source projects, and contribute to the community in other ways. Not only does it bring instant value, but also helps people grow and learn how to contribute. A good hackathon should be wrapped up with a demo and a small party.

Before Ethworks, I took part in internal hackathons, but there was no pressure to contribute to the community, so the vast majority of work went to trash. It was still a nice team-building exercise and allowed people to try new things, which is great.

However, when your work is not used by anyone and goes to waste, it is not very motivating. I would much rather write a small tutorial that helps people than write a poor app nobody uses.

In practice, 40% — 60% of the team’s work would get published. Anything above 50% is a very good result, as one day is a very limited amount of time and people need to have room for trial and error.

Reward system

Another great technique is allowing engineers to take time off projects to contribute, publish and present. When coupled with a reward system, like a points system, it can be quite effective. Rewards for such points are usually something like going to a high-profile conference. It usually activates some employees to be more proactive in contributing, but the expectation to have the majority involved is probably unreasonable.

Internal OSS team

Eventually, when the company grows a bit, it might be wise to get a dedicated person or an internal OSS team. It’s a strategy for a bit bigger companies that is a bit more expensive, but enables sustainable growth. Still, often comparable to running a solid ads-driven strategy, but generating much higher-quality leads.

Each method comes with significant effort and without a role model the company will hardly pick up. Again and again, a technical co-founder is needed to take a lead role.

Converting

There are a lot of quality materials, books, and consulting services aimed at converting lead into projects. Therefore, I will be very selective about the subject and point out what I find to be two poorly covered, yet very important elements — the involvement of a technical person and estimations.

Technical person vs lead quality

If you target the dev community you can expect the best leads to be quite technical and demanding so a sales person is unlikely to convince a customer that you are the right company to pick.

On the other hand, if an important technical person (such as the CTO or the CEO of a company) spends too much time on the calls, they will likely neglect other duties. This is where leads qualification comes in handy.

One common way to qualify leads is to put them into buckets, like high, mid and low quality. Without going into different algorithms or uncertainty of such, I will just note the following:

• High quality leads, whom you are confident you want to convert. Those should go straight to the CEO or CTO and be converted with sales support.
• Mid-quality leads, some of whom you want to convert. Those should go to the sales team and only have some support from the C-level.
• Low quality leads — whom you probably don’t want to convert, unless you have people on the bench. Those should go to sales, and if not reclassified during the sales process, should be shared via deal sharing deals with other dev houses.

Estimations

Estimating is one of the unsolved problems in the computer science industry and yet, almost every single customer will ask to estimate something before starting a collaboration.

The industry developed many techniques for estimation: story points, t-shirts, Monte Carlo to name a few, all with their own limitations and rarely giving a quality prediction for a new project. Hence, most dev shops would only agree to estimate a small chunk of work, like an MVP.

Some dev houses will propose to organise a workshop with the potential team involved. It helps the customers realize what they need, as they often have only a vague idea. Additionally, it helps achieve some level of psychological commitment from the team. It is a good strategy and it scales fairly well.

However, this reminds me of good old advice from the Y combinator’s founder — Paul Graham — “Do the things that don’t scale”.

With the privilege of quality leads, usually being more precise in defining what they want to build, we decided to do something different. We look at similar projects we have done in the past and how much time they took and assume it will be similar. Then prepare a nice looking offer with the team composition and estimated hours.

When optimised, such a process would take less than an hour of work of the C-level guy and perhaps another one from a sales person. Thanks to that, we could come up with estimation as soon as the next day after the first call, long before competition would be able to schedule a workshop or even set a date for one.

When you are small, you can move faster, do things that don’t scale and outcompete competition. Keep it in mind before introducing another enterprise process sold to you by yet another silicon valley company.

Value flow

So far, in the blog series, we have covered all stakeholders of a boutique dev shop: community, employees, and customers. We can now finally bury the myth of dev shop struggling to produce a clear value proposition. Below is a flow of value between a dev house and its stakeholders.

Framework for running a Boutique Dev House

With all the insights we gathered over the last four blog posts, we come to a point where a framework to run a premium dev house (by some referred to as a boutique) reveals itself:

1. Find a specialization in a non-trivial technology early in its cycle, with a fast-growing community.
2. Start with a small freelance job or after-hour work hobby project.
3. Start contributing to the community based on work from 2.
4. Convert your first serious project.
5. Establish access to talent.
6. As you get projects, hire and grow talent, and keep contributing to the community.
7. Repeat 5 while scaling up efforts and building structure.

I have covered steps 1–6 steps thoroughly in this blog post series so far. I will focus on step 7 in the next blog post.

Things to keep in mind:

• Pivot your specialistion if needed.
• Build key competencies internally: employer branding, hiring, marketing and sales.

Summary

My original inspiration to try the strategy described in this blogpost comes from Brazilian Plataformatec and Jose Valim, who was a major contributor to rails and later created his own language — Elixir.

Over the years, I have seen different variants of this strategy used by many successful boutique dev houses. Most of them have already been acquired, leaving space for successors.

We have also successfully implemented it in Ethworks. At the peak — just before acquisition — we had a waiting list of customers and we were rejecting a few deals a week. We were sharing those excessive deals with three different software houses, some of which converted them into multi-year projects. On top of that, I could call any of my customers and ask: “Do you want to increase the team size?” and I knew for the fact that the answer would be most of the time: “Yes”. Our customers were among some of the most interesting and most renowned brands in the Ethereum space.

Over a year after the acquisition and after closing our marketing channels — in the middle of crypto winter — we still have leads dripping now and then, perhaps enough to run a small company still.

Coming up next

With such a great lead stream, one could wonder why we didn’t grow the company further.

To understand why it was an optimal moment to exit, one needs to understand the dev house growth model. And this will be the exact topic in the upcoming post — the last part of the dev houses blog series — Growth and structure.

Stay tuned! 🎵

Thank you for reading!

If you like this post — hit 👏 button below.

To get notification about the next parts click follow below.

If you want to continue the conversation and see more stuff like this, you can find me on Twitter: @ethmarek.