Blog
/
Education

The most important lesson I've had to learn as a technical founder

cover
Jens Neuse

Jens Neuse

min read

We're hiring!

We're looking for Golang (Go) Developers, DevOps Engineers and Solution Architects who want to help us shape the future of Microservices, distributed systems, and APIs.

By working at WunderGraph, you'll have the opportunity to build the next generation of API and Microservices infrastructure. Our customer base ranges from small startups to well-known enterprises, allowing you to not just have an impact at scale, but also to build a network of industry professionals.

For a very long time I really sucked as a technical founder because I was missing one very important trait. I was obsessed with technology. I was obsessed with performance. I was always trying to improve things that didn't need improving. I was adding more and more features because I wanted to support more and more use cases. But while doing all of that, I was forgetting the most important thing: Building a business!

I still believe that being obsessed with technology, at least to some degree, is a good thing. You need to be innovative, you need to think forward, you need to be able to see the future. But you can't just keep building. If it's a hobby project, that's fine. But if you want to build a business, there are other things you need to focus on.

Stop being obsessed about tech, be obsessed about the customer and their problems

I've talked to many other technical founders, and they all have the same problem. You can smell them from a mile away against the wind. The conversations always start the same way. You meet them, and they tell you about their "amazing solution". It's not yet 100% done, they are still working on it, but they are so excited about it. At the same time, they cannot yet launch it, it's not ready yet. You could fast-forward 6 months, and they would still be building, or maybe they gave up.

The hard truth is that they actually don't want to launch their product. They just want to build stuff. As long as you're building, you're not failing. But as soon as you launch, you might fail. So you better keep building.

And that was exactly me. Building WunderGraph. I've built the fastest GraphQL compiler in the world. Nobody cares. I wasn't able to market it. Actually, how would a compiler even be marketed?

So I've built a whole GraphQL Gateway around it, with code generation, live queries, subscriptions, all of it. Still nobody cared. Was my compiler a bad solution? Should I quit? I actually wanted to quit multiple times. I kept building, more and more features, like caching, tracing, monitoring, etc. But still nobody cared.

So I realized that just building stuff is not enough. I needed to do some marketing. Spread the word about WunderGraph. This is how I've got into writing blog posts about GraphQL, APIs, and all of that. I've had some good success with that, some of my posts have been read by hundreds of thousands of people.

And eventually, I've got super lucky and someone was willing to pay me for supporting them. They wanted to use WunderGraph for their product, so they paid me to add features that they needed. And that's when it all clicked. This one customer allowed me to build a business. I was able to quit my job and focus on WunderGraph full-time. But there was a lot more to it. Btw. thanks Ryan, if you're reading this.

Ask questions and listen, then ask more questions and listen more

Up until Ryan, I was building WunderGraph for myself. But Ryan was building a product for his customers, he was building a business, he had to deliver, so I had to deliver as well. Most importantly, I had to listen to his needs, ask questions about his business and how I could help him.

Prior to this, I always wanted to build the best solution for a problem. But best wasn't good enough. It also had to be well tested, benchmarked and superfast. But why make it fast if it doesn't even solve the problem?

I think that a lot of technical founders are like me. Obsessed with their technical solution, in search of a problem to solve. I know that you will not listen to me, but I can still try.

A framework for technical founders

Fast-forward to today, I've developed a framework how to build a business as a technical founder which I'd like to share with you. You will probably ignore me, because you love building, but at least you can say that you've heard me out.

Find a problem that you're able to market

This is the most important step. Don't just focus on a problem you can solve. Focus on a problem that you're able to market.

Do you have a twitter following? A YouTube channel? A blog? Do you have any kind of network you can leverage? Do you have access to a community that you can reach out to? Do you have a network of potential customers for a solution?

If you don't have any of that, stop building. Do not write a single line of code.

Build a team, a network, a community, a following. If you're not the kind of person to network, find someone to help you with that. I've matched with Stefan on YC's co-founder matching program. He's a great person to build relationships with. Find yourself a co-founder if you're not able to build a network on your own.

Build a go-to-market strategy before the first line of code

This is something most coders hate to do. You think you can just build and, create a landing page, and people will come. Nobody will come.

Stop writing code and start building a go-to-market strategy. Imagine that your product is already implemented. How would you market it? How would you get people to use it? Are they actually willing to pay for it? Do they understand the value you're providing?

Build barely enough to get the first customer

Don't make it fast. Don't make it shiny. Make it work. Make it solve the problem. Make it work for the first customer.

Are you actually able to get the first customer? If not, STOP BUILDING. Talk to more potential customers. Find out if they actually need your solution. Or maybe they have a different problem that you can solve.

Be obsessed about understanding them and their problems. Search for patterns in their problems. Ideally, you can find a problem that multiple customers have.

When someone asks about your startup, and you're talking about your technical solution, you know that you're not yet there. You need to be talking about your go-to-market strategy, your customers, and their problems and how you're growing a business.

Nobody cares about your GraphQL compiler. People, and especially VCs care about your ability to build a business. You don't get funded for a compiler, you get funded if people believe that you can 1000x return their investment.

If they don't pay, you're not providing value

Don't fall into the trap of believing that you need to write more code to provide more value. If you've built a solution, but people are not willing to pay for it, maybe it's because you're not bringing enough value.

You might also realize that you find users, but they don't want to pay. This can happen when you've built a solution to people without buying power. It's important that you think about your target audience and if they're actually able to pay for your solution.

What if you want to sell for $100/month, but your customers are only willing to pay $5/month?

Let your customers vote with their wallets

Build barely enough to get the first customer. Listen to them and make them happy. Create a customer success story to attract similar customers. Rinse and repeat. Find the patterns in your customers' problems. Don't just say yes to every feature request.

Ask questions and find the root cause of the problem. Then let your customers vote with their wallets. Are they willing to pay for an extra feature?

Conclusion

The GraphQL compiler I've built is now the foundation of WunderGraph and it's used across the industry by many companies in API Gateways and GraphQL servers.

But what really helped me build a business was not the architecture of this piece of software. It's these principles that I've learned from Ryan and Stefan.

  • Find a problem that you're able to market
  • Build a go-to-market strategy before the first line of code
  • Build barely enough to get the first customer
  • If they don't pay, you're not providing value
  • Let your customers vote with their wallets
  • Don't just say yes to every feature request
  • Ask questions and find the root cause of the problem

If this helped just one person not burn out and be disappointed because they didn't get users, then I'm happy. If I can help you through mentorship or anything else, please reach out to me .

Don't give up. You might have an amazing idea, but you really need to focus on the business side of things, even if you're doing it together with a co-founder, which I highly recommend. I have 3 co-founders, and I'm super grateful for them.