Building a Successful Startup With Go

You know the drill. Fast iteration cycles. Non-stop A/B testing. Inevitable pivots. Building a technology product in a startup environment requires a working setup that differs significantly from more prominent or more established companies. In no small part, the choice of a tech stack can play a crucial role in whether the startup can find its product-market-fit quickly enough.

We all know that Go is a first-class choice for many kinds of problems - ranging from tooling through service and infrastructure development. But can it also be a good choice for starting a tech product from end to end? If rapid development and fast iteration cycles matter more than nanosecond performance, is Go a solid contender for the more dynamic tech stacks from the Ruby, Python, and JavaScript domain?

In a recent episode of the popular Go Time podcast, host Jon Calhoun spoke to four startup founders who bet the future of their companies on the language and its stack.

Go Time 177: Building startups with Go – Listen on

I can summarise my takeaways from this discussion as follows: even if Go might feel more verbose and stricter than some of its contenders, it pays off multiple times over (in the long run) in terms of clarity and stability.

For us it was an easy way to get started, not worry about performance for a very long time, and just be able to focus on that MVP and making sure we just offer the functionality we wanted to build, without having to worry about “Will it run everywhere? Will it scale?” and all those things.

Ramiro Berrelleza - Founder and CEO - Okteto Inc

All of the participants in the podcast agreed about the following:

  • Go applications compile extremely fast.
  • They can be painlessly deployed to any major operating system and cloud platform
  • Last but not least, they keep the same level of small resource consumption and fast performance, even as products grow.
[...] the binary coming out of Golang - I can run it now and I will be probably able to run it with no modification five years from now, which is from my perspective great. And you know, building a technology for a startup knowing - just like Ramiro said - that performance issues won’t exist for a very long time… And the scalability of the technology made Go a natural choice.

Wojciech Adam Koszek - Cofounder/CTO - Segmed, Inc

One of the aspects of Go that strikes many newcomers to the language is the lack of a single "winner takes it all" kind of solution for most problems. The same applies to project structure - one will not find a single place in the documentation providing explicit guidance on how a project should be structured. The only piece of advice is the usual "keep it simple." While this may sound obvious and even off-putting to some, it carries a certain level of reassurance. Almost like permission to focus on the problems that software should solve and leave structure to grow naturally.

Joining the Go club after almost a decade of writing enterprise-grade Java apps, I was initially confused by what I thought back then looked like utter chaos. Every Go project I looked at had a different structure, and I was desperate to get back to the patterns I had used to fall into over and over again. Only when I started building my first real production apps did I fully grasp the meaning of "keep it simple." It looks like others have had a similar experience:

What I like about Go is that it actually suits perfectly the startup world. The functionality you need, you always need it yesterday. You can put it in, and making it nice comes later… And I really appreciate it, because I really don’t like the frameworks where I need to study hundreds of pages of the framework documentation just to put something in, because I have to follow a certain structure.

Wojciech Adam Koszek - Cofounder/CTO - Segmed, Inc

If you want to read more about project structure in Go, host Jon Calhoun recently wrote a great article on this topic:

Thoughts on how to structure Go code
Programmers are taught very early on about the importance of organizing their code. Whether it is naming variables and functions, or naming and organizing files, this is a topic covered early in nearly every programming course. All of this begs the question: why is it so damn hard to figure out how …

If you don't care reading the entire article, keep this brilliant quote in your mind:

[...] using a structure that is far more complex than needed can actually hurt a project more than help it.

Do you have a startup story with Go worth being told? Don't hesitate to get in touch with me. I'd love to hear it and share it with our audience.

Pssst ... wanna see a cool new app built entirely with Go? Yes, entirely with Go (a topic for an upcoming post)! Check out Murmel, and feel free to try the free beta. We would love to hear your feedback.

Murmel: Start making sense of your Twitter stream
Get the hottest news stories shared by your Twitter friends without stress or missing out on anything.